Тестировщики всего-навсего проверяют критерии приемки

… и ещё семь триггерных фраз для тестировщиков

Здесь вы найдёте те самые триггерные вопросы или фразы, из-за которых тестировщики могут вас невзлюбить. Люди обесценивают их, могут игнорировать их проблемы или даже возложить вину там, где её нет. Всё это я слышал в ИТ-залах (или в Zoom-конференциях) для придания значения спикеру и огорчения тестировщика.

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

Примечание: В этой статье термин “тестировщик” используется для описания всего, что подпадает под выполнение тестирования: QA-, QE-, SDET-, SET- специалисты и так далее. Обычно я стараюсь не использовать термин «тестировщик», поскольку он подразумевает, что тестированием занимают только тестировщики, но всё-таки он охватывает куда больше специалистов.

“Тестировщики всего-навсего проверяют критерии приемки”

Что, простите? Думаете, что работа тестировщика состоит только в том, чтобы… утверждать критерии приемки? Критерии приемки, которые вы явно прописали в своём пользовательском сценарии? Вы про эти критерии приемки?

Какими уникальными навыками или невероятной компетентностью должен обладать проверяющий список критериев приемки? Я не представляю. «Вот, что должно делать ПО. Вот само ПО. Оно это делает? Сейчас протестируем, ведь с этим справится даже ребёнок!». Вот как вкратце выглядит искажённое представление о тестировании, поощряющее фразы «…да просто проверь критерии приемки».

Тестирование – не просто проверка критериев приемки. Это сложный процесс постоянного обнаружения и уведомления о всевозможных расхождениях между потребительской стоимостью ПО и состоянием ПО в данный момент.

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

Да, слишком углубились в метафору. Дело в том, что КП – отнюдь неполное описание поведения системы. Пусть, вы напишите их тысячи (что не рекомендуется) или объедините их с миллионом страниц документации по нефункциональным (или межфункциональным) требованиям, они всё равно будут словно разбросанные пристанища в долгом путешествии. Настоящее тестирование должно базироваться на здравом смысле, суждении, пониманием пользователей и критическом/аналитическом мышлении, чтобы постоянно оценивать состояние ПО в отношении его ценностного предложения. Независимо от того, проводит ли его QA-специалист, QE или инженер-универсал. Это не просто список, который нужно вычеркнуть.

“Просто утвердите критерии приемки” – оскорбление для тех, кто в этом разбирается.

“Будьте добры, работайте сверхурочно, чтобы завершить все пользовательские сценарии этого спринта”

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

Это называется “сбросить тестировщиков с края обрыва”.

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

Проблема в том, что это бремя возлагают только на тестировщиков.

Одна из самых распространённых патологий agile на основе scrum-методологии с любым разделением работы между тестировщиками и разработчиками – обрыв разгара работы (когда большинство сценариев переходят к фазе завершения в конце спринта). Тестировщики (последний вагон в этом виде Agile), всегда будут в цейтноте под конец спринта. Они будут стараться завершить ПС до истечения времени, несмотря на то, что они меньше всех несут ответственность за сложившуюся ситуацию. Они не по своей вине застревают у компьютера в 11 ночи в четверг.

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

Однажды, мне довелось поработать с Agile-коучем, который следовал следующему подходу: «Если кого-то из команды просят поработать допоздна в последний день спринта, то остаётся вся команда, а все очки, которые команда может заработать в следующие дни спринта – уменьшаются вдвое. Так продолжается до тех, пор, пока команда не продемонстрирует, что может успешно выполнить всю необходимую работу, не отрабатывая дополнительные часы».

Классный парень.

Конечно, можно задать вопрос, поему вы делаете мини-спринты водопадного типа, но это совсем другая тема.

“Если есть время, сделайте только автоматизацию”

Ладно, я напишу автоматизированные тесты, если у меня будет на это время. Как часто agile-команды сталкиваются с избытком времени? Нехватка времени в спринте == экономия на автоматизации тестирования == смертельная спираль регрессии.

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

Эту поразительно-недальновидную, но, к сожалению, распространённую стратегию подсластить пилюлю я подробно описал в статье Смертельная спираль регрессии.

Когда вы планируете создать ПО в любой из agile-методологий (итеративной/ инкрементной), помните, что вы не просто создаёте ПО. Вы, к тому же, строите инфраструктуру вокруг, чтобы продолжать столь же эффективно создавать и увеличивать ПО. Это не вещь на раз. Создание ПО – это вода, поэтому придётся вложиться в сантехнику. Сюда входят: вложения в автоматизацию тестирования, пайплайны CI/CD, инструменты ведения журналов и мониторинга, такая инфраструктура, как код, проверка оформления кода и много чего другого.

В agile-развёртывании, если у вас нет времени на автоматизацию – лучше вообще не начинайте создание ПО.

“Я разработчик, тестирование – не моя работа”

Более очевидного перекладывания ответственности я ещё не слышал.

Вот возможный вариант того, как переводится эта фраза-убеждение: «Тестировать легко (это же просто проверка критериев приемки, ПРАВИЛЬНО?). А мне нужно заняться более сложными вещами, например, написанием кода, поэтому я не хочу тратить время на тестирование. Я напишу кода, но проверить его на работоспособность пусть проверит кто-то другой. Я слишком важен и дорого стою, чтобы тратить время на какое-то там тестирование». 

Разве люди не это имеют в виду? Посмотрите, что написал Джоэль Спольски (умный и успешный парень) про наём тестировщиков ещё в 2000. Вот выдержка:

Как бы не было сложно найти тестировщиков, они всё равно дешевле программистов. Намного дешевле. Если вы не наймёте тестировщиков, то тестированием займутся программисты. Если вы думаете, что поток тестировщиков это плохо, то подождите, пока не поймёте, насколько дорого обходится замена звёздного программиста за 100 000 долларов в год, который устал от «просто потрать пару недель на тестирование до выпуска продукта» и умотал в более профессиональную компанию. Вы можете нанять трёх тестировщиков за год только за ту же сумму, что покрывает гонорары рекрутера за замену программиста.

Этот абзац – сильный удар под дых любого профессионального тестировщика.

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

Я не имею в виду, что нельзя создавать команды по разной работе между разработчиками и тестировщиками. Даже если вы это сделаете, разработчики должны активно быть вовлечены в тестирование, а тестировщики должны понимать и участвовать в разработке. Качество зависит от всех.

“Вас будут оценивать по тому, сколько дефектов вы найдёте”

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

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

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

Касательно измерения качества, вот отличная цитата Джеймса Баха из его статьи в блоге Оценивайте качество, а не измеряйте.

…сотрудники не сидят сложа руки, пока руководство создаёт системы наблюдения за ними. Они исследуют, как использовать эти системы, чтобы создать положительное впечатление и избежать негативной реакции. Это особенно легко выполнить, когда руководство хочет получить измерения альтернативными сложным и многоструктурным доказательствам. Когда руководство не хочет участвовать в дискуссиях того, что не имеет значения. Когда все важные параметры сводятся к нескольким «KPI», умные используют это для своих манёвров.

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

“Какой процент тестирования вы завершили?”

Без понятия, а насколько процентов человечество изучило термоядерную энергию?

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

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

В таком случае, спрашивать про процент или прогноз завершённости – всё равно, что смотреть на индикатор выполнения в старом Windows 98. Индикатор может дойти до финальной точки и висеть там бесконечно.

Тот, кто задает этот вопрос, на самом деле ищут оценку состояния качества, но вместо полноценной беседы, всё сводится к одной цифре. Такое чрезмерное упрощение не отразит то, что должно сообщаться в беседе. Для более глубоко погружения в эту тему, я снова ссылаюсь на статью Баха «Оценивайте качество, а не измеряйте».

“Почему вы хотите быть тестировщиком? Искусственный интеллект их заменит”

Несмотря на мой скептицизм касаемо инструментов тестирования на основе AI/ML, я правда с удовольствием наблюдаю, как алгоритмы AI/ML совершенствуют разработку ПО, включая тестирование. Но я наоборот предполагаю, что это повлечёт за собой увеличение спроса на человеческую деятельность, а не заменит её. Тот, кто считает, что ИИ будет «тестировать приложения» во всех его аспектах – не разбираются ни в AI/ML, ни в тестировании.

Рассмотрим такой вариант. Между разработкой и тестированием ПО, второе является более субъективной, качественной и абстрактной деятельностью, для которой требуется человеческий интеллект, интуиция и понимание пользователей. Если ИИ продвинется до такой степени, то он будет писать ПО в целом. Если это случится, то мы в одном шаге от Скайнета.

Так что, если вы считаете, что «тестирование – просто проверка критериев приемки», то понятно, почему вы можете считать и то, что ИИ будет заниматься тестированием. К сожалению, реальное тестирование – это гораздо большее.

“Почему вы не нашли этот баг?”

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

PS: если дефект ускользнул в производство, не нужно спускать всех собак на тестировщиков. Тестирование обеспечивает обратную связь с командой о состоянии качество. Это не идеальная сеть по предотвращению попадания всевозможных ошибок в производство. Если дефект попал в производство, необходимо оценить все аспекты разработки, от написания сценариев до выпуска, чтобы видеть, где могут потребоваться изменения. Не нужно из QA-специалиста делать козла отпущения фразами «почему ВЫ не нашли этот баг?».

Оригинал статьи: https://medium.com/@blakenorrish/testers-just-validate-acceptance-criteria-4c25566b591e