Комментарии 3
Зашел за золотой пулей, а её не оказалось.
Подскажите. Вот у вас продукт, который разрабатывается несколько лет. Какова вероятность, что регрессионное тестирование вообще помещается в разумные рамки в пределах спринта? И что делают разработчики, пока идет регресс, ведь по скраму добрасывать новые задачи нельзя.
чтобы расширить спринт и перенести дату релиза
Вот это ведь уже опять же не скрам.
Добрый день, спасибо за ваш комментарий!
Вероятность 100%. Даже несмотря на длительную разработку продукта, необходимый объем регрессионного тестирования можно выполнить в пределах спринта, так как под регрессию выбираются модули/функциональности, затронутые изменениями в коде.
При этом уложиться в срок поможет автоматизация, а также чёткое планирование и распределение задач между всеми членами команды.
А пока идет регрессионное тестирование, разработчики могут заняться задачами из следующей версии, которые также добавляются в спринт.
Здесь может возникнуть конфликт приоритетов: либо строго следовать правилам и процессам (но есть риск терять в качестве и часто беспокоиться о простое разработчиков), либо поставить качество на первое место и заранее планировать, насколько это возможно.
Подскажите. Вот у вас продукт, который разрабатывается несколько лет. Какова вероятность, что регрессионное тестирование вообще помещается в разумные рамки в пределах спринта? И что делают разработчики, пока идет регресс, ведь по скраму добрасывать новые задачи нельзя.
Вероятность 100%. Даже несмотря на длительную разработку продукта, необходимый объем регрессионного тестирования можно выполнить в пределах спринта, так как под регрессию выбираются модули/функциональности, затронутые изменениями в коде.
При этом уложиться в срок поможет автоматизация, а также чёткое планирование и распределение задач между всеми членами команды.
А пока идет регрессионное тестирование, разработчики могут заняться задачами из следующей версии, которые также добавляются в спринт.
Вот это ведь уже опять же не скрам.
Здесь может возникнуть конфликт приоритетов: либо строго следовать правилам и процессам (но есть риск терять в качестве и часто беспокоиться о простое разработчиков), либо поставить качество на первое место и заранее планировать, насколько это возможно.
изменение требований "в конце спринта", надо же...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Регрессионное тестирование на Scrum-проектах: руководство по проведению