На одном из тренингов мне задали вопрос: "Как выжить тестировщикам при Agile?". Тренинг, кстати, был на совершенно другую тему, но, видимо, вопрос больной. Думаю, ответы на него можно найти в "The Testing Manifesto", составленном по аналогии со знаменитым Agile-манифестом коучами Карен Гривз и Самантой Лэинг.





Звучит классно, но нуждается в более подробном объяснении. Детально эти принципы изложены в книге Гривз и Лэинг "Growing Agile".
Agile-тестирование - это не просто такое же тестирование, как обычно, только в спринтах. Agile-подход должен изменить весь ход мыслей команды.

We value testing troughout over testing at the end.
Мы больше ценим тестирование во время, чем тестирование в конце.
Традиционно тестирование понималось как фаза, которая следует за разработкой.
Однако в Agile-разработке тестирование - это не фаза, а деятельность, которая должна произойти, наряду с программированием, написанием документации и всем прочим.

Если на вашей доске задач появилась отдельная колонка "Тестирование", это может свидетельствовать о том, что вы по-прежнему рассматриваете тестирование как фазу, и деятельность тестировщиков все еще отделена от остальной работы команды.



Agile-коучи Карен Гривз и Саманта Лэинг рекомендуют другой подход: задачи по тестированию должны проходить через те же этапы, что и все остальные: "В планах", "В процессе", "Готово".

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



We value preventing bugs over finding bugs.
Мы больше ценим предотвращение багов, чем нахождение багов.
"Лучший бой - тот, который не состоялся" - эта древняя мудрость восходит к древнекитайскому стратегу Сунь-цзы. Так же и с багом - лучше предотвратить, чем найти и исправить.

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


Такой пример приводится в книге "Growing Agile".
Команде нужно было реализовать создание отчета, содержащего средние показатели продаж за последние 6 месяцев. Все считали, что они прекрасно понимают требования и особых обсуждений здесь не нужно.
Тогда Гривз и Лэинг решили задать несколько вопросов:

• Если я запущу отчет 1 февраля, данные за февраль будут включены или нет? А если 29-го февраля?
• Как именно должны подсчитываться средние показатели - средний показатель каждого месяца или одно среднее арифметическое за все 6 месяцев?
• Этот средний показатель должен сохраняться где-то или подсчитываться "на лету"?
• Отчет должен храниться где-либо или создаваться по запросу?
• Из каких полей в базе данных высчитывается средний показатель?
• Кто будет использовать этот отчет и для чего?
  

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


We value testing understanding over checking functionality.
Мы больше ценим тестирование понятности, чем проверку функциональности.

Тестировщикам, которые считают, что их работа состоит в проверке соответствия продукта и спецификации (ТЗ), трудно свыкнуться с Agile. Но ведь это всего лишь формальная проверка того, насколько точно разработчики выполнили техническое задание. Это практически ничего не говорит о качестве продукта и его пригодности к использованию.

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

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


Продолжение следует.

Хочешь освоить профессию тестировщика? Начни с курсов из этого раздела.