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

Scrum'е. Сейчас я попытаюсь рассказать о том, что мы делали и чему мы успели научиться за это время.

Скорее всего, вам не избежать фазы приёмочного тестирования

В идеальном мире Scrum’а результатом каждого спринта должна быть система, потенциально готовая к использованию. Бери и устанавливай, да?

А вот и нет!

По нашему опыту, такой подход обычно не работает. Там будет куча противных багов. Если «качество» для вас хоть что-нибудь значит, тогда придётся позаботиться о ручном приёмочном тестировании. Это когда специально выделенные тестировщики, которые не являются частью команды, бомбят систему теми видами тестов, о которых Scrum-команда не могла даже и подумать, или на которые у неё не было времени, или соответствующего оборудования. Тестировщики работают с системой точно так же, как и пользователи, а значит, что это нужно делать вручную (если, конечно же, ваша система разработана для людей).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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