Звучит логично: - Сначала разработаем. - Потом протестируем. - Ну а если что-то найдём - быстро исправим. 😄

Проблема в том, что к этому моменту «потом» обычно превращается в «вчера».

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

А ошибки, конечно, находились.

Разработке нужно время на исправления.

Тестировщику - время на проверку.

А спринт почему-то всё ещё заканчивается через два дня.

В итоге приходилось договариваться: что-то задерживали, что-то переносили, что-то выпускали с известными ошибками и фиксировали их уже в ближайшие дни. Поэтому хорошее тестирование начинается не тогда, когда разработчик говорит: «Всё готово».

QA лучше подключать заранее: понимать, что планируется в спринте, какие задачи приоритетны, что можно проверить уже сейчас, а где нужно дождаться разработки. Потому что стратегия «разорвись, но сделай» плохо работает, если на проверку оставили два часа из двухнедельного спринта. 😄