Scrum и тестирование. Как на практике происходит тестирование в рамках scrum?

Question

[Максим]

В Scrum успешность спринта - это все задачи, которые были добавлены в scrum, оказались в статусе Done.
Но как быть, если разработчики делают таски до самого последнего дня спринта? Когда тестирование будет происходить?
Если задач окажется в спринте меньше, чтобы дать некий запас на тестирование, то чем занять разработчиков?

Answer 1

[kn0ckn0ck]

Этой теме посвящена целая книга: "Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд" от авторов: Лиза Криспин, Джанет Грегори.

Там очень хорошо описана роль тестировщиков и разработчиков (в части тестирования), как лучше выстроить процесс, на что обращать внимание и т.п.

Если вкратце отвечать на исходный вопрос: необходимо распределить работу в команде таким образом, чтобы все были активно вовлечены в процесс разработка/тестирование в течение спринта. За результат отвечает вся команда, поэтому оставлять для тестирования сырого кода пол дня - это просто забивать болт на качество.

Answer 2

[rustler2000]

AFAIK (как бывший certified scrum master) нету "успешного" или "провального" спринта. Спринт это таймбокс для работ. Если в планирование ошиблись, то на ретроспективе нужно понять и зафиксировать как избежать техже грабель при следующем планирование.

Статус Done vs тестирование это зависит что у вас записано в Definition of Done. Бывает, что тестер часть комманды и тестирование это просто его обычные задачи.
Если тестирование идет с лагом, то проще фикс бага отдельной задачей в одном из следующих спринтов сделать, чем дева переключать. То что полное закрытие "user story" при этом занимает несколько спринтов - это вполне нормально.

Comments

[Максим]

Спасибо за комментарий.
QA - часть команды и в DoD указано, что user story закрывается только после успешного тестирования и закрытия найденных багов.
Т.е. получается, что как только все таски по user story закрыты, то QA начинает регресс.

[rustler2000]

Когда US на задачи разбивается, то там сразу должны быть "test round 1" и "bugfix round 1" "test round 2" хоть с какими оценками по времени. Иначе burndownы будут не реалистично оптимистические. И соответственно тестирование начинается когда таски девелопера по разработке закончились.
Наглядно это хорошо видно на канбан доске.

Answer 3

[Артём]

то чем занять разработчиков?

Естественно, задачами следующего спринта и задачами, которые перенесены из этого спринта в следующий.
Ну и исправлением багов, естественно.

Comments

[Максим]

Так следующий спринт стартует каждый понедельник, а билд в тестирование уходит, допустим, в среду.
Т.е. следующий спринт еще даже не спланирован.

[Артём]

разработчики делают таски до самого последнего дня спринта?

Т.е. разработчики отдают билд в тестирование в среду, но трудятся над ним до пятницы? Это как? И чем занимаются тестировщики с понедельника по среду?
Возможно, у Вас другая релизная политика и я её просто не понимаю, но мне она кажется черезчур странной=)
Мы тоже поддерживаем scrum, но тестировщики получают один день на полный регресс. Разработчики в это время устраняют баги при тестировании. И всегда к концу спринта есть массивные задачи, которые сформулированы слишком поздно, чтобы войти в этот спринт. Поэтому мы постоянно имеем запас постановок на следующий спринт.

[Максим]

У нас сейчас выстроено так:
Спринт - 2 недели.
Первый понедельник - планирование.
Разработчики делают фичи.
QA тестирует то, что сделано разработчиком. Т.е. разработчик задачу отправил в QA, они ее проверили. Если ок - то ок. Если нет, то заводится баг.
К концу спринта, во вторую среду делается билд, который улетает на регресс.
К второй среде разработчиками должны быть закрыты все таски, которые ставились на спринт. Баги, которые находятся во время регресса попадают в текущий спринт.

[Артём]

Теперь намного понятнее=) Тогда ответ на вопрос таков: Устранение багов регрессионного тестирования(в момент регресса могут выявится глобальные и массивные баги, которые можно начать кодить и поставить в следующий спринт)+ во время планирования текущего спринта делать запас на несколько массивных задач, чтобы занять разработчиков, если всё пойдёт хорошо.
Так же разработчиков можно занять доработкой исключений какого-нибудь api.
Вообще, правильного ответа на вопрос быть не может, каждый проект и команда разработки специфична.

[Максим]

Вот и хочется узнать об опыте других команд.
Спасибо за ответ, будем пробовать.