Home

Оригинальная публикация

Перевод: Анна Радионова

Сбор грибов - неотъемлемая часть каждой осени в моей жизни. По крайней мере, здесь, в Эстонии, наши корни охотников-собирателей все еще очень прочны. Брести по лесу с корзиной и ножом в руках, наслаждаясь умиротворенностью и спокойствием сосен, один из самых приятных моментов  в преддверии мрачной зимы.

Я считаю сбор грибов медиативным процессом, когда часть моего сознания концентрируется на грибах, в то время как другая часть занята размышлением обо всем, что приходит в голову. На этот раз я поймала себя на том, что размышляю о сходстве процессов сбора грибов и тестирования.

И да, такие сходства я нашла. Причина, по которой я захотела написать об этом статью, заключается в том, что эвристики и оракулы - понятия, которые сложно усвоить как начинающим тестировщикам, так и людям, просто интересующимся тестированием. Я провела несколько семинаров и тренингов на эту тему. Поэтому, по меньшей мере, те, кто знаком с процессом сбора грибов или другими пищедобывательными процессами, сравнивая собирательство грибов и охоту за багами, найдут в  этих процессах много общего.

Ну что ж, начнем…

Оригинальная публикация: http://qablog.practitest.com/leading-by-example/

Перевод: Анна Радионова

Тестировщики, даже будучи членами команды, все равно являются аутсайдерами. Их ценность обусловлена этим статусом, поддерживается, благодаря ему, и все время находится под угрозой из-за него.

На заре времен разработки тестирование считалось незыблемым/неприкосновенным.

Тестировщики были закреплены за отдельными командами, они были изолированными единицами в организационной иерархии для того, чтобы они не попадали под влияние разработчиков. Взгляд  тестировщиков на продукт был беспристрастным. Тестируемые системы являлись “черными ящиками”, в которые тестировщики подавали данные на вход и делали выводы о состоянии продукта на основании полученных в результате данных.

И хотя цели таких действий сводились к тому, чтобы оставаться беспристрастными сторонниками качества, с течением времени такая тактика приобрела конфронтационный и бюрократический характер.

С появлением и распространением agile методологий убежденные “отщепенцы” стали понемногу замещаться фидбеком и тестированием пользователей.

Тестирование в рамках традиционных больших команд было заменено на закрепление специалиста по тестированию за небольшой командой разработки.

Автор: Майк Токс (Mike Talks)

Оригинал статьи: http://www.testingcircus.com/four-simple-steps-to-becoming-the-best-tester-you-can-be/

Перевод: Ольга Алифанова

Кажется (благодаря рекламной политике Youtube), что каждый раз, когда мне хочется посмотреть клип, я должен насладиться какой-нибудь жуткой рекламой вроде «Привет… сейчас я открою вам секрет, как изменить свою жизнь за пять простых шагов». Я терпеть не могу грубую рекламу «Я выучил магический секрет, как стать миллионером, и поделюсь им с сотней людей на своем семинаре… по 10 000 долларов с человека». Надо признать, в душе я слегка корыстен, и в какой-то момент я подумал «хм, а ведь я могу сделать что-то похожее для тестирования». Проблема в том, что бассейн тестирования и так полон акул, и прибавление в семействе никак не помогает сообществу.

Почти ежедневно я беседовал с молодой тестировщицей Гуной, которая хотела стать самым лучшим тестером, которым только возможно быть. Она была потрясающим зарядом энергии и уже проявляла активность в сообществе, будучи в трудном положении – единственным тестировщиком на проекте. Я очень радуюсь, когда многие подобные тестировщики присоединяются к Твиттеру и ищут тест-сообщество там. Разговаривая с Гуной, я подумал, а как стать самым лучшим тестировщиком? Я набрасывал идеи примерно неделю, и список оказался удивительно простым – иногда мне казалось, что стоит добавить что-нибудь еще, но оказывалось, что это уже покрыто каким-то имеющимся пунктом списка.

Вот мои четыре шага к тому, чтобы стать самым лучшим тестировщиком. Они довольно просты – однако сложны в том плане, что не сводятся к «вычеркни это как сделанное и переведи мозг в режим ожидания». Это ценности, которыми нужно дышать ежедневно – они не гарантируют, что вы станете потрясающим тестировщиком прямо сейчас, но обещают, что вы будете тестировать лучше, чем вчера.

До второй Международной конференции по тестированию и QA TestCon Moscow 2018, которая пройдет в Москве 18-19 апреля, осталось чуть больше месяца.

С программой предстоящей конференции можно ознакомиться здесь.

А пока мы публикуем видеозапись доклада Анастасии  Асеевой (Альфа-Лаборатория) “Резиновый кластер для динамического selenium grid” с прошедшей конференции.

Обсудить в форуме

Оригинальная публикация: http://www.developsense.com/blog/2017/11/the-end-of-manual-testing

Перевод: Анна Радионова

Тестировщики! Когда мы обсуждаем ручное тестирование, мы помогаем “тонуть кораблю”.

Это сильное заявление, но оно сформировано на основании долгих лет наблюдения за людьми, которые говорят на тему тестирования неосторожно. Опасность заключается в том, что людей, не специализирующихся на тестировании (и даже некоторых из тех, кто специализируется) вводит в заблуждение формулировка, что какой-то вид тестирования называется “ручным”, а какой-то - “автоматизированным”. Они не понимают, что разработка ПО и тестирование в рамках разработки можно сравнить с тонкой дизайнерской работой, а не фабричным выпуском продукции. Эти люди ослеплены скоростью и надежностью автоматизации, внедренной на производстве. Очень скоро они зацикливаются на идее, что тестирование может быть автоматизировано. Ручное тестирование - плохо, автоматизация - хорошо.

Впоследствии тестировщики, обладающие хорошими способностями к критическому мышлению, и навыками выявления проблем, испытывают сложности в поиске работы. Вместо них нанимают тестировщиков с весьма скромными навыками программирования и не внушающими доверия аналитическими способностями, которые месяцами пишут программы, суть которых сводится к нажатию кнопок компьютером. Целью становится отладка автоматизированных проверок, а не выявление проблем функционала, который важен для пользователя. Сложности, связанные с тем, чтобы “заставить” компьютер взаимодействовать с продуктом, отнимают время, которое могло быть потрачено на изучение продукта и наблюдение за тем, как ведет себя система. В результате имеем продукт, который мог быть тщательно или не очень протестирован, но в котором присутствуют дефекты, снижающие или даже напрочь уничтожающие его ценность.

Оригинальная публикация: http://www.networkworld.com/article/2944686/software/are-you-over-testing-your-software.html

Перевод: Анна Радионова

Возможно ли уменьшить или даже исключить человеческий фактор при тестировании релизов программного обеспечения? Коротко говоря, да. В этой статье говорится как.

Тестирование релиз-кандидатов отнимает слишком много времени.

Для большинства agile команд - это одна из самых сложных задач. С этим снова и снова сталкиваются мои клиенты и коллеги, которые работают над крупными интегрированными веб-сайтами и приложениями.

Но что, если вам не нужно было бы прибегать к помощи сотрудника для проверки определенной версии билда, чтобы минимизировать риски перед деплоем? Вместо него бот сообщал бы команде о готовности билда и кому-то оставалось бы только нажать кнопку деплоя?

Внедрение такой практики потребует расширения инфраструктуры и улучшения дисциплины. Возможно, это нереализуемо в вашей команде, но существуют компании, применяющие такой подход на регулярной основе.

Оригинальная публикация

Перевод: Анна Радионова

Компании, которые ведут бизнес онлайн, теряют миллиарды долларов годового дохода из-за бага - несовместимости их систем с доменными именами, состоящими из символов, отличных от латиницы. Исправление этого общеизвестного бага увеличило бы количество пользователей онлайн-сегмента приблизительно на 17 миллионов человек за счет числа тех, кто говорит на русском, китайском, арабском, вьетнамском, индийском языках.

Такое заключение сделала компания-лидер отрасли на основании своего нового исследования, спонсором которого является организация, ответственная за поддержание и актуализацию списка действительных доменных имен, International Corporation for Assigned Names and Numbers (ICANN) (Международная организация по распределению номеров и имен). Задача так называемой Координационной группы по вопросам всеобщего признания новых доменов (Universal Acceptance Steering Group), членами которой являются представители огромного числа интернет-компаний (например, Microsoft и GoDaddy), - мотивировать разработчиков ПО и владельцев сервисов производить обновления своих систем в отношении валидации набора символов справа от точки в имени домена или e-mail адреса, т.е. в домене верхнего уровня.

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=14

Перевод: Ольга Алифанова

Ветки

Из семян взращиваются тестовые идеи – как сорняки. Следуйте за ними. Нам нужно как можно больше идей и мыслей, как можно больше покрытия, чтобы принимать наилучшие решения про общее тестовое покрытие. Поначалу это будет выглядеть уродливо и неорганизованно. Но дайте модели вырасти. Начните переставлять ветки, подрежьте некоторые из них. По мере роста веток создание карты побудит вас задавать более четкие вопросы участникам проекта. Карта становится инструментом по улучшению самой себя. Этим и прекрасны органические системы – бросьте в них семечко, и оно вырастет само по себе, с нами в роли безумного садовника.

Вот как выглядит модель тестового покрытия после чтения спецификации и разговора с разработчиком:

На этом этапе план тестового покрытия и план покрытия продукта практически идентичны по своей природе, за тем исключением, что план тестового покрытия описывает и включает в себя тип тестирования и вопросы для исследования.

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=14

Перевод: Ольга Алифанова

Представьте, что вы – владелец зоопарка, которому хочется узнать, что поделывают коллеги по профессии. Вы открываете руководство по большим кошкам. Оно выглядит примерно так:

«Вот пример большой кошки: она отличается тем, что у нее есть усы, она пушиста, и имеет пару глаз. По моему опыту, очень полезно заводить такую большую кошку в зоопарке. Всем заинтересованным лицам очень нравится  моя большая кошка».

Посчитав прочитанное информативным и вдохновляющим, вы открываете другое руководство, где видите другую большую кошку:

«Недавно я читал про больших кошек, и с тех пор старался заполучить их в свой зоопарк. У моей большой кошки тоже есть усы, она пушиста и двуглаза, но мне нравится, что она более пушиста и менее полосата».

«Круто!» - думаете вы.

Вы уже видели два примера больших кошек, у которых, конечно, много общего, но которые сильно отличаются друг от друга. Как-то раз вы, вне себя от радости, общаетесь с коллегой – владельцем зоопарка, который рассказывает вам про своих новых больших кошек и помещение для них. Он очень рад, потому что постоянно слышал, что современные зоопарки используют больших кошек в своих выставочных залах, и что большая кошка – это пик современных зоопарковых практик.

Автор: Энди Тинкам (Andy Tinkham)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=33

Перевод: Ольга Алифанова

Начиная с девяностых годов, Кем Кейнер, Джеймс Бах и Брет Петтикорд начали формулировать свою концепцию «школ тестировочной мысли». Они самоидентифицировались как принадлежащие к школе «тестирования, управляемого контекстом», и описывали другие способы мышления, с которыми они сталкивались в течение своей карьеры, как фабричную школу, аналитическую школу, и школу качества. Позднее они добавили пятую школу – школу Agile. Такая организация научной мысли давала новый способ разобраться в различиях мнений о «хорошем» тестировании [1].

С тех пор определения школ развились от изначально задуманной перспективы (определенной работой Томаса Куна про способы развития сводов знаний) в нечто куда более расплывчатое. Противоречия множились, так как концепция школ использовалась для того, чтобы категоризировать и даже демонизировать людей, а не идеи (Джошуа Рейн писал об этих аспектах школ в декабрьском выпуске Testing Trapeze). В какой-то момент дискурс вокруг школ даже описывал их как нечто религиозное. Разговор вокруг школ начал включать элементы, схожие с теми, которые встречаются в дискуссиях о политике (как минимум тут, в США – язвительность, личные атаки, укоренившиеся взгляды). Однако никто не бывает прав в 100% случаев, и ни одна группа не может всегда владеть единственно верной перспективой по отношению к определенной проблеме. Сейчас меня беспокоит, что люди говорят, не слушая друг друга, вместо того, чтобы совместно развивать отрасль. Наши дискуссии приносят больше вреда, чем пользы.