66 / 94
Scrum и XP: заметки с передовой
66
Scrum
команда
релиз
1.0.0
релиз
релиз
1.0.1
1.0.1
Пользователи
Команда
тестировщиков
Команда тестировщиков найдёт баги, Scrum-команде придётся подготовить версию с исправленными
багами, и рано или поздно (будем надеяться что рано) вы сможете выпустить для своих пользователей
версию 1.0.1 с необходимыми исправлениями. Она будет куда более стабильной, чем глючная 1.0.0.
Когда я говорю "фаза приёмочного тестирования", я имею в виду весь период тестирования, отладки и
перевыпуска, пока версия не будет достаточно хороша для выхода в свет готового продукта.
Минимизируйте фазу приёмочного тестирования
Приёмочное т стирован е, мягк г воря, п инос т некоторые неудобства. Оно определённо не имеет
ничего общего с гибкими методологиями. И, несмотря на то, что мы не можем избавиться от этой фазы, мы
можем попробовать свести её к минимуму. А если точнее, уменьшить
количество времени
, которое для него
необходимо. Этого можно достигнуть следующими способами:
•
Максимально улучшить качество исходного кода, создаваемого Scrum-командой.
•
Максимально увеличить эффективность ручного тестирования (т.е. найти лучших тестировщиков,
обеспечить их лучшими инструментарием и убедиться, что они сообщают о тех задачах, которые
отнимают много времени и могут быть автоматизированы).
Так как же мы можем поднять качество кода команды? Ну, вообще-то способов существует очень много. Я
остановлюсь на тех, которые, как нам показалось, действуют лучше всего:
•
Включите тестировщиков в Scrum-команду.
•
Делайте меньше за спринт.
Повышайте качество, включив тестировщиков в Scrum-команду
О, я уже слышу эти возражения:
•
"Но это же очевидно! Scrum-команды должны быть
кросс-
функциональными
!"
•
"В Scrum-команде не должно быть выделенных ролей! У нас не может
быть человека, занимающегося
только
тестированием!"
Я бы хотел кое-что разъяснить. В данном случае, под "тестировщиком" я
подразумеваю человека, главная специализация которого тестирование, а не человека, чья роль – это
исключительно тестирование.
Разработчики достаточно часто бывают отвратительными тестировщиками.
Особенно
, когда они
тестируют свой собственный код.
Тестировщик – это "последняя инстанция".
Кроме того, что тестировщик – обычный член команды, он ещё и выполняет очень важную функцию. Он –
человек, за которым всегда "последнее слово". Ничто не может считаться готовым в спринте, пока
он
не
подтвердит, что это действительно так. Я обнаружил, что разработчики часто говорят, что что-то готово, хотя в
действительности это не так. Даже, если у вас имеется очень чёткое определение критерия готовности
(которое у вас должно быть, см. стр. 29 "Критерий готовности"), в большинстве случаев, разработчики будут