Соотношение спринтов и фаз приёмочного тестирования

Соотношение спринтов и фаз приёмочного тестирования

В идеальном Scrum-мире фаза приёмочного тестирования не нужна, так как каждая Scrum-команда после каждого спринта выдаёт новую, готовую к реальному использованию версию системы

Ну, а на самом деле, всё выглядит чуть-чуть по-другому:

После первого спринта выпускается глючная версия 1.0.0. Во время второго спринта начинают поступать сообщения об ошибках, и команда большую часть времени занимается отладкой, а потом выпускает версию с исправлениями 1.0.1 в середине спринта. Потом, в конце второго спринта выходит версия 1.1.0 с новым функционалом, которая, естественно, оказывается ещё более глючной, так как у команды просто не хватило времени довести её до ума из-за того, что приходилось подчищать хвосты, оставшиеся с прошлого спринта. И так по кругу.

Наклонная красная штриховка второго спринта символизирует хаос.

Неприглядная картина, да? А самое грустное в том, что эта проблема остаётся даже при наличии команды приёмочного тестирования. Единственная разница состоит в том, что основная масса сообщений об ошибках поступает от команды тестирования, а не от негодующих пользователей. Но эта разница просто огромна с точки зрения бизнеса, хотя для разработчиков ничего и не меняется. Ну, кроме только того, что тестировщики обычно менее агрессивны, чем конечные пользователи. Обычно.

Простого решения этой проблемы мы так и не нашли. Но наэкспериментировались с разными подходами вдоволь.

Перво-наперво, опять же, необходимо обеспечить наивысшее качество кода, который создаёт Scrum-команда. Стоимость раннего обнаружения и исправления ошибки (в пределах спринта) несравнимо ниже стоимости обнаружения и исправления ошибки после окончания спринта.

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

Подход №1: «Не начинать новые истории, пока старые не будут готовы к реальному использованию»

Звучит классно, не так ли? Вас тоже греет эта мысль? :)

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

Наличие неограниченной во времени итерации между спринтами нам не нравилось в основном из-за того, что она бы нарушила регулярность спринтов. Мы не смогли бы больше заявлять: «Каждые три недели мы начинаем новый спринт». А кроме того она не решает проблему. Даже если мы введём такую итерацию, всё равно время от времени будут появляться ошибки, срочно требующие внимания, и нам надо быть к этому готовыми.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Результаты тестирования

Из книги автора

Результаты тестирования Для сжатия был получен следующий график. Хорошо заметно, что для небольших файлов основные издержки вносятся работой с файловой системой, а не архивированием. Здесь и далее все времена указаны в миллисекундах. Проводились серии тестов по 10000


8 Стратегии тестирования

Из книги автора

8 Стратегии тестирования Профессиональные разработчики тестируют свой код. Однако тестирование не сводится к написанию нескольких модульных или приемочных тестов. Написание этих тестов – дело полезное, но отнюдь не достаточное. Любой группе профессиональных


Основы тестирования

Из книги автора

Основы тестирования С чего лучше начать? Как измерить эффективность после внесения нескольких изменений в настройки или оформление? Для оптимизации коэффициента конверсии недостаточно будет просто что-то где-то изменить. Необходимо:– внести правильные


Планирование тестирования

Из книги автора

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


4.1 Необходимые условия для тестирования

Из книги автора

4.1 Необходимые условия для тестирования 4.1.1 Наличие компонентов продукта Для тестирования пакета программ должны иметься в наличии все его поставляемые компоненты (см. 3.1.2 h), а также нормативные документы, указанные в описании продукта (см. 3.1.2


4.3 Протоколы тестирования

Из книги автора

4.3 Протоколы тестирования Протоколы по каждому тесту должны содержать информацию, достаточную для повторения теста (Руководство ИСО/МЭК 25 [6]). Данная информация должна включать:- план тестирования или технические требования (спецификацию) к тестированию, содержащие


Соотношение спецификации и проектирования

Из книги автора

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


Соотношение классов и записей

Из книги автора

Соотношение классов и записей Другим замечательным свойством объектной технологии является то, что при ней можно сохранять неявные описания гораздо дольше, чем при других подходах. В последующих лекциях будет введена система обозначений, позволяющая определять класс в


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

Из книги автора

Скорее всего, вам не избежать фазы приёмочного тестирования В идеальном мире Scrum’а результатом каждого спринта должна быть система, потенциально готовая к использованию. Бери и устанавливай, да? А вот и нет!По нашему опыту, такой подход обычно не работает. Там будет куча


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

Из книги автора

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