Создание регрессионного тестирования спринта в гибкой?

Question

Я нахожусь в команде, которую мы поставляем прямо сейчас. Мы готовимся к regression sprint, это будет следующий спринт. В этом спринте testers придется протестировать все приложение, чтобы убедиться, что приложение находится в стабильном состоянии.

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

Я могу думать о двух вариантов, чтобы решить эту проблему

1. Doing регрессии с некоторыми из команды тестирования и пусть другая команда тестирования присоединиться к команде разработчиков работать в следующем выпуске
2. Посвятите Спринт to регресс & ошибка исправление.

Подсказка: мы ограниченные ресурсы в тестировании, поэтому мы не можем предложить команду для тестирования регрессии

Answer 1

Там нет такого понятия, как «регрессионного тестирования спринта». Это противоречие в терминах, так как спринт включает в себя все, что необходимо для доставки потенциально прибыльного прироста программного обеспечения.

В Scrum мы разрабатываем, тестируем (включая регрессионное тестирование) в течение времени, которое мы называем спринтом. Мы делаем это потому, что:

• Мы хотим, чтобы доставить рабочее ПО каждый спринт
• Мы хотим дать истинное отражение прогресса

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

Интересно, что вы говорите, что у вас ограниченные ресурсы тестирования. Я подозреваю, что вы имеете в виду, что у вас ограниченные люди, у которых есть метка «тестер». Разработчик может выполнять регрессионное тестирование. Они могут даже писать автоматические регрессионные тесты, особенно мощный подход при быстром развитии.

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

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

Answer 2

вы можете пересмотреть свой процесс Dev так в будущем

• через автоматизации различных испытаний (сделано разработчиками)
• и/или путем добавления некоторого времени в спринте х + 1, чтобы зафиксировать ошибки, найденные в спринте x
• и/или путем создания небольших историй, которые могут быть реализованы и проверены в одном спринте (см. размер спринта)
• и/или изменение культуры, если dev и qa рассматриваются как различные команды

вы постепенно приходите, чтобы избежать такого сценария, как ваш текущий.
Успение: вы не поддерживаете огромную унаследованную систему (cobol), где может возникнуть смысл сдерживающий спринт или более.

на данный момент вариант 2 выглядит как лучший компромисс, предполагая, что ваши разработчики помогут тестировщикам и тестировщикам не найти столько ошибок, что вам понадобится новый спринт для исправления ошибок в новой регрессии и т. Д. :).