Home

Оригинал статьи: https://beaglesays.wordpress.com/2017/07/16/the-illusion-of-quality-assurance/

Автор: Пол Симан (Paul Seaman)

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

Когда я только начинал тестировать, моя должность обозначалась как "Тестировщик". С тех пор прошло много лет, и я побывал как тестировщиком, так и QA-специалистом. Моя предыдущая должность называлась "Старший QA-аналитик", а нынешняя – "Старший инженер по тестированию". В официальных коммуникациях я всегда использую точное название своей должности, но вне их я представляюсь как тестировщик. Я горжусь этим званием и тем, что оно для меня значит. Уже долгое время я протестую против "QA-специалиста", потому что это название кажется мне глуповатым. К сожалению, его популярность растет. К еще большему сожалению, мне кажется, что люди, представляющиеся как QA, ставят QA выше и главнее тестирования. Проблема в том, что когда они описывают, что же такое "обеспечение качества", они на самом деле говорят о добросовестном, компетентном тестировании.

Не пошла ли мода называть тестировщиков "специалистами по обеспечению качества" из Agile? Я, если честно, понятия не имею. Не думаю, что Agile стоит у истоков переименования тестировщиков в QA-специалистов, но судя по разговорам тестировщиков на конференции LAST, Agile-методология внесла в эту проблему свой вклад. Не будем называть имен, вот краткое содержание диалогов тестировщиков:

• Если вы ждете, когда же начинать тестировать, сдвигаться влево уже поздно.
• Тестировщики – привратники на пути качества благодаря образу своего мышления.
• Мы обеспечиваем качество, тестировщики этого не делают. Мы убеждаемся, что все сделано правильно.

Идея специального вахтера качества полностью противоречит мысли, что за качество отвечает вся команда. На одном докладе на доске был написан вопрос "Как бы вы это тестировали?" Спустя десять минут слово "тестировали" было вычеркнуто и заменено на "обеспечивали качество" с лозунгом "мы больше, чем тестировщики – мы обеспечиваем качество". Я спрашивал у докладчиков, каким конкретно образом они обеспечивают качество, но ни один не смог объяснить мне, как он это делает. Те же тенденции касательно QA заметны и в обсуждениях на LinkedIn.

Я работаю в Scrum-команде, моя первичная роль – это тестировщик. Вот пример того, как все работает у нас.

Я посещаю встречи, посвященные грумингу юзер-стори. Я критикую допущения, спрашиваю, как нам улучшить тестируемость, помогаю сфокусироваться на рисках и том, чего мы не знаем. Совместно с коллегами я работаю над выявлением потенциальных проблем как можно раньше. Мы записываем то, что нам, возможно, понадобится обсудить или изучить, относящееся к юзер-стори. Никакого обеспечения качества – но мы на нем фокусируемся.

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

Разработчик начинает программировать, а я проверяю связанную с юзер-стори функциональность. Во время стартового совещания мы узнали, что нам угрожает потенциальная проблема, и вместе мы разбираемся, что на что может повлиять. Потом мы собираемся снова и обсуждаем свои находки. Да, проблема есть! Мы исследуем природу проблемы и вероятность ее возникновения, и приходим к выводу, что усилия и риски по ее устранению перевешивают шанс, что проблема проявит себя. Если она и возникнет, мы легко с ней справимся, а на клиента она почти не повлияет. В результате мы выявили ограничение, мы принимаем его как данность и сообщаем о нем заказчикам. Это хороший сценарий развития событий. Масса концентрации на качества, но где тут его обеспечение? Я пока что ничего не обеспечил.

Разработчик хочет добавить несколько юнит-тестов к проверкам билда. Мы обсуждаем, что из них будет полезным, а что не будет. Я предлагаю сценарий, который он не рассматривал, и мы добавляем его в набор тестов. Этот сценарий влечет за собой следующий, и я делюсь этой идеей. Мы снова беседуем. Вроде бы мы уже покрыли этот сценарий другими кейсами. Мы приходим к выводу, что риск, о котором мы беспокоились, уже снижен. Насколько я могу судить, я уже прилично протестировал в ходе работы над этой юзер-стори, но кода еще и в помине нет. Как это возможно? Ведь если вы тестировщик, а не QA, то когда вы начинаете тестировать, сдвигаться влево уже поздно? Неужели евангелисты QA нам врут?

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

На картинке выше – наши обсуждения, то, что я узнал, используя ПО, возможности, основанные на наблюдениях. Чуть позже момента съемки этого фото я отказался от ряда идей, так как узнал, что специфические настройки параметров приведут к тому, что проблема, над которой мы работали, никогда не возникнет. Конечно, в этой связи у меня появились новые мысли и новые идеи. Я поделился этой фотографией с командой и менеджером поддержки, который был особенно заинтересован в этой юзер-стори. Я искал кого-то, кто найдет пробел-другой или даст обратную связь, которая обогатит мой подход. Конечно, люди могут среагировать и в духе "выглядит ОК" – я все равно предпочитаю пару свежих глаз и разные точки зрения. По-моему, я тестирую. Я отвратительный QA – что именно я тут обеспечиваю?

Код готов, разработчик показывает, что изменилось. Продакт-оунеру все нравится, и я вижу, что критериям приемки фича соответствует. Более того, я вижу, что она соответствует им в одном-единственном сценарии. Я снова беседую с разработчиком, мы обсуждаем изменения и пытаемся понять, не упустили ли мы ничего важного. Вроде бы мы покрыли все критичные моменты, и разработчику нравятся мои идеи тестов – он считает, что они помогут выявить все серьезные проблемы.

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

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

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