Сказ о ненатуральном эджайле

Спорная точка зрения о тестировании в Agile: признаки ненастоящего эджайла

“Эджайл — никто точно не знает, что это такое. Ушлым консультантам нравится такая ситуация, она позволяет продавать свою версию эджайла за большие деньги. 

Дальше я распишу 8 признаков признаков того, что у вас не настоящий эджайл.

Тестируют только тестировщики

Кто такой тестировщик? Как написал в древние времена некий Джоэль Спольски, «дешевая рабочая сила, которую нанимаешь чтобы программисты не отвлекались на ерунду». Такое мнение потянет на анафему в Agile — когда ты нанимаешь «дешевый ресурс», они будут с позволения сказать «тестировать», но это конечно не Agile.

Тестирование это не не столько роль, сколько деятельность. В которой так или иначе должна участвовать вся команда. Те, у кого в названии должности присутствует «QA», не должны быть единственными, кто занимается QA. 

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

Скажу даже, что концепция «Deep Testing«, о которой говорят такие известные личности в тусовке как Джеймс Бах и Майкл Болтон, это скилл который должны практиковать все роли в команде. 

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

Ты заводишь баги по любому поводу

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

В waterfall-модели QA команда получает новый билд со всеми функциями. И начинает тестовый цикл: на день, на неделю, или месяц. Зная огромное количество дефектов которые неизбежно таятся в коде, и затраты времени на устранение, было критически важно документировать каждый дефект.

Такое тщательное документирование вовсе не обязательно в эджайле.

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

Есть только две серьезные причины писать подробную документацию по багу:

1. Дефект найден уже после релиза. Как вариант: в части, не связанной с user-story. Такой дефект должен быть запротоколирован, и ему должен быть быть присвоен приоритет. 

2. Дефект обнаружен в истории. Владелец продукта считает, что исправление дефекта имеет значительно меньший приоритет чем завершение истории; поэтому история принимается “as is”, без исправления дефекта. В этом случае дефект записывается чтобы позже его исправить, но текущей истории присваивается состояние «выполнена».

Создание дефектов по каждому поводу во время напряженной работы команды — является пережитком старых недобрых времен моды на тестирование по методу водопада.

Уточнение: это относится и к ситуации, когда баги прячут в сабтаски в Jira.

Ты сам расставляешь багам приоритеты

Итак, есть дефект, серьезный (об этом было выше). Тестировщик в модели водопада немедленно присвоит ему (приоритет). «Опа, нашел блокер, мажор, минор!» — раздавалось в нашем воркспейсе в те годы.

А какой приоритет надо присвоить в Agile? Будет дефект иметь высокий или низкий приоритет, или что-то посредине, зависит от владельца продукта, и присваивается исходя из позиции дефекта относительно других историй и дефектов в бэклоге. Присваивание каждому дефекту отдельного приоритета — избыточно, как и его записывание в специальном поле, это несовместимо с самой идеей приоритетов в бэклоге.

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

При тестировании каждой user-story обнаруживается много багов

В модели водопада существовало правило «разработчики написали, тестировщики протестировали». Поэтому ожидалось, что большинство дефектов будут найдены когда новый билд будет передан в QA.

Во многих командах эта практика «просочилась» в Agile. История завершена, передана в QA, найдено много багов. Тестировщики возвращают историю разработчикам, чтобы те пофиксили. Затем процесс повторяется.

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

Ты избыточно документируешь тест-кейсы

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

Agile-истории обязаны быть небольшими, в соответствии с концепцией INVEST, о чем нам символизирует буква “S” — Small (детальнее здесь). Тестирование одной истории не требует отдельного тест-плана, и нумерации всех тест-кейсов.

Значит ли это, что документировать тесты не нужно? Нет, нужно. И в Agile нужно документировать (в истории), что тестировалось и проблемы, которые возникали. Если реально видишь что это нужно, можно воспользоваться внешними инструментами (Zephyr, TestRail) для документирования. Но чаще это признак, что ты снова свалился в модель водопада, по крайней мере в вопросах документирования тест-кейсов.

Планирование тестов, документирование проблем и подходов — все еще востребовано в Agile. А избыточное документирование каждого тест-кейса — нет, не нужно.

Ты автоматизируешь тест-кейсы

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

«Что? Автоматизация в эджайле это основа основ!» — возразят. Абсолютно, но не надо автоматизировать тест-кейсы.

Снова это повторю, поскольку это все еще не доходит до многих эджайл-команд: не надо автоматизировать тест-кейсы.

Автоматизация тест-кейсов, которая в жизни выглядит как превращение 100500 тест-кейсов из тест-плана в 100500 автоматизированных тест-кейсов, и, как следствие — неимоверное разбухание набора тестов (test suite) — это вернейший путь к пирамиде тестов как бы «вывернутой наизнанку», узким концом вниз. Очень плохая практика.

Проблема с тест-кейсами в том, что они обычно описывают ожидаемое поведение приложения на высоком уровне (то есть приложение в целом), а у нас стоит задача автоматизировать на как можно более низком уровне.

Что должно случиться, когда у тебя перед глазами несколько историй полученных в текущем спринте, написаны несколько сотен (а то и тысяч) низкоуровневых юнит-тестов, сотни автотестов для тестирования API и может быть несколько новых или имеющихся автоматизированных сквозных (E2E) тестов высокого уровня. Тебе нужно чуть меньше сквозных автоматизированных тестов, чем у тебя есть тест-кейсов.

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

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

Еще один крупный индикатор чрезмерной автоматизации тест-кейсов: почти все свободное время тестировщик занят выполнением тестов, чтобы каждый день получать фидбэк о состоянии приложения. 12-часовые автоматизированные наборы были хороши, когда программы деплоились скажем дважды в год. А сейчас приходится деплоить дважды в час.

Понадобилось большое регрессионное тестирование перед деплоем

Спринт завершен. Все истории успешно завершены. Владелец продукта хочет деплоить продукт.

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

По причинам из сферы совместимости, безопасности, или по корпоративно-бюрократическим, не всегда возможен «деплой по требованию» (как в Постоянном Развертывании или даже Постоянной Доставке), не то что каждый спринт. Однако цель тестирования в Agile всегда должна быть в том, чтобы иметь всю завершенную работу в виде готовом к продакшену. Чем больше промежуток между завершенными историями и готовностью к продакшену, тем меньше можно называть такой процесс эджайлом.

Альтернативный путь: переопределить, что значит «завершен» в обозначении истории. Очень просто выбросить какие-то вещи в историях, когда “давит” график. «Да, мы не обязаны делать тестирование производительности в каждой истории, давайте релизить» и вот это все. Чем меньше идешь на компромиссы с этим «завершен», тем ближе настоящий эджайл.

Ты отделяешь QA-спринты от девелоперских

Разработчики пишут несколько историй (и им помогают тестировщики, конечно), но всегда в конце спринта остаются невыполненными тестовые или автоматизационные задачи. Вместо того чтобы решить главную проблему (которая может заключаться в раздутом размере истории, ожиданиях, неправильном сотрудничестве между разработчиками и тестировщиками) — команда переходит к стратегии «последовательных QA-спринтов». Истории разрабатываются в одном спринте, далее тестирование и автоматизация этих историй происходит в следующем спринте.

Последовательные спринты — ключ к провалу. Они разворачивают рабочий процесс в точности наоборот к тому каким он должен быть: к более громоздкому, как бы серийному разделению обязанностей между разработкой и тестированием.
Если ты поклонник «последовательных» спринтов, не смогу переубедить. Мне искренне жаль разработчиков, которым возвращают их истории, завершенные месяц назад. А ведь разработчики могут уже не помнить, что делали вчера.”

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

3 КОММЕНТАРИИ

Подписаться
Уведомить о
guest

3 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
murrr
murrr
2 лет назад

Тестирование это не не столько роль, сколько деятельность. В которой так или иначе должна участвовать вся команда.
—-
Золотые слова, всем менеджерам на заметку! Качество — ответственность не только QA, а всей команды!!! Многие этого не понимают.

Eugene T.
Eugene T.
2 лет назад

Настоящего эджайла не существует ни в одной команде — чтобы следовать методологии на 100 процентов, надо полностью исключить человеческий фактор.

mary_jane
mary_jane
2 лет назад

Спасибо, хотелось бы больше статей по процессам.

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

🔥 Популярное

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас