Scrum и XP: заметки с передовой

Команда тестировщиков найдёт баги, Scrum-команде придётся подготовить версию с исправленными багами, и рано или поздно (будем надеяться что рано) вы сможете выпустить для своих пользователей версию 1.0.1 с необходимыми исправлениями. Она будет куда более стабильной, чем глючная 1.0.0.

Когда я говорю «фаза приёмочного тестирования», я имею в виду весь период тестирования, отладки и перевыпуска, пока версия не будет достаточно хороша для выхода в свет готового продукта.

Минимизируйте фазу приёмочного тестирования

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

• Максимально улучшить качество исходного кода, создаваемого Scrum-командой.

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

Так как же мы можем поднять качество кода команды? Ну, вообще-то способов существует очень много. Я остановлюсь на тех, которые, как нам показалось, действуют лучше всего:

• Включите тестировщиков в Scrum-команду.

• Делайте меньше за спринт.

Повышайте качество, включив тестировщиков в Scrum-команду

О, я уже слышу эти возражения:

«Но это же очевидно! Scrum-команды должны быть кросс-функциональными!»

«В Scrum-команде не должно быть выделенных ролей! У нас не может быть человека, занимающегося только тестированием!»

Я бы хотел кое-что разъяснить. В данном случае, под «тестировщиком» я подразумеваю человека, главная специализация которого тестирование, а не человека, чья роль — это исключительно тестирование.

Разработчики достаточно часто бывают отвратительными тестировщиками. Особенно, когда они тестируют свой собственный код.

Тестировщик — это «последняя инстанция»

Кроме того, что тестировщик — обычный член команды, он ещё и выполняет очень важную функцию. Он — человек, за которым всегда «последнее слово». Ничто не может считаться готовым в спринте, пока он не подтвердит, что это действительно так. Я обнаружил, что разработчики часто говорят, что что-то готово, хотя в действительности это не так. Даже, если у вас имеется очень чёткое определение критерия готовности (которое у вас должно быть, см. стр. 29 «Критерий готовности»), в большинстве случаев, разработчики будут часто его забывать. Мы, программисты, люди очень нетерпеливые и стремимся перейти к следующему пункту списка как можно быстрее.

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

Приятный дополнительный эффект этого подхода состоит в том, что у команды появляется человек, который отлично подходит на роль организатора демонстрации результатов спринта.

Чем занимается тестировщик, когда нечего тестировать?

Этот вопрос никогда не теряет своей актуальности. Мистер Т: «Scrum-мастер, сейчас нечего тестировать. Чем я могу заняться?». Может пройти неделя, пока команда закончит первую историю, так чем же будет заниматься тестировщик всё это время?

Для начала, ему следует заняться подготовкой к тестированию. А именно: написанием спецификаций тестов, подготовкой тестового окружения и так далее. Таким образом, когда у разработчика появится что-нибудь готовое к тестированию, мистер Т должен быть готов начать тестирование.

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

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

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

• Установить и настроить тестовое окружение.

• Уточнить требования.

• Детально обсудить процесс установки.

• Написать документы по установке (заметки к релизу, readme.txt или что там требуется в вашей компании).

• Пообщаться с подрядчиками (например, с дизайнерами пользовательского интерфейса).

• Улучшить скрипты автоматизированной сборки.

• Последующее разбиение историй на задачи.

• Собрать ключевые вопросы от разработчиков и проследить, чтобы они не остались без ответов.

С другой стороны, что мы делаем в случае, когда мистер Т оказывается «узким местом»? Скажем, сейчас последний день спринта и большая часть функционала уже реализована, а мистер Т не имеет возможности протестировать всё необходимое. Что мы делаем в этом случае? Ну, мы можем сделать всех членов команды помощниками мистера Т. Он решает, что он может сделать самостоятельно, а простые задачи поручает остальным членам команды. Вот, что такое кросс-функциональная команда!