Рекомендую проводить ручное тестирование раз в несколько дней и сделать еще один-два финальных, приемочных теста ближе к концу спринта. Как часто тестировать – решите экспериментально. Начните с раза в два-четыре дня. Ошибки исправляйте сразу после тестов, пока воспоминания о коде еще свежи.
Вы помните, мы добавили к задачам критерии приемки. Этакий чек-лист. Пусть его один раз прочекает разработчик при переносе задачи на проверку. Для самоконтроля. А затем еще раз проверит тестировщик.
Если команда зрелая, а бюджеты позволяют (для сайтов это почти всегда не так – всем дорого), покрывайте рутинные проверки автотестами. Или, как минимум, формализуйте тест-план для критических маршрутов проведением смоук-тестов на продуктиве. Например, в интернет-магазинах покрываем тестами маршрут Каталог → Карточка товара → Добавление в корзину → Корзина → Чекаут. Критических тестов не должно быть много, и они не должны занимать много времени. Но должны вселять уверенность, что ключевые функции в порядке.
В заказной разработке редко, но встречается клиент, который не видит ценности в тестировании. Речь идет не о манипулятивном приеме, попытках отжать скидки или загнать разработчика под плинтус («Я что, должен за ваши косяки платить?!»). А об искреннем непонимании, как возможно, что после тестирования, тест-кейсов и всех этих довольно дорогих процедур – я, как заказчик, нахожу ошибки. Причем такие, которые кажутся мне очевидными. Они меня бесят! Я не понимаю, на что тратятся время и деньги.
Совет
Немного помогает, если у заказчика есть доступ на чтение баг-листов, и он видит, что команда нашла и исправила несколько сотен ошибок. Но утешение слабое, осадочек остается. Отправлять баг-листы нужно до того, как претензия созреет, а не после. Действовать от силы, а не от слабости. При этом должна быть определенная культура ведения баг-листов: смотрите главу «Правила письменной контрацепции». Однако лучше всего попадать в ожидаемое качество и давать гарантию на свою работу.
3.7. Демонстрация продукта. Завершение спринта
Говорят, в Царской России при испытании нового железнодорожного моста под него ставили всех строителей. А сверху пускали паровоз. Мосты век стояли. А разработчик – либо герой, либо – труп.
Нужно демонстрировать результат работы лично, ставить шкуру на кон! Это бодрит. Подстегивает ответственность и рост качества продукта. Боли, правда, будет больше. Но это полезная боль.
Согласуйте демонстрацию заранее. Если проект долгоиграющий – запланируйте стандартное время, в которое будете показывать спринты. Например, каждый вторник, 16:00. Времени резервируйте около часа. Нужна будет либо личная встреча, либо видеосвязь с демонстрацией экрана.
Со стороны бизнеса присутствует как минимум Product Owner. Пользователи и другие сочувствующие – допускаются. Со стороны разработки – вся команда. Понятно, что бывают исключения, но стремимся к этому.
Для начала я вкратце рассказываю, что успела команда за спринт. Вспоминаем цели спринта. Дальше, с экрана, показываю инкремент. Команда помогает, рассказывая, что, как и почему было сделано. В идеале каждый рассказывает про свой вклад. Разработчики помогают с ответами на технические вопросы и обоснованием решений.
Ради чего все это затевается: обратная связь в режиме реального времени. Пусть жесткая, но честная. По сути, обсуждается только первое впечатление, но оно не врет. WYSIWYG – What You See Is What You Get, или «если тебе кажется, что что-то не так, – скорее всего, тебе не кажется».
По опыту большая часть обратной связи будет конструктивной и позитивной. Особенно с англоговорящими заказчиками. Бояться демонстраций не надо. Надо готовиться. Продумайте чуть заранее: