Как не захлебнуться от тестирования в конце спринта?

Меня сегодня спросила подруга, а как быть в ситуации, когда тестировщики в начале спринта ковыряют в носу, а к концу захлебываются от работы и что-то не успевают выпустить, хотя функционал уже разработан.

А кто не был из нас в этой ситуации?! 😀 Давайте попробуем поштурмить, что может помочь достичь баланса, чтобы тестировщики занимались текущими задачами в течение всего спринта.

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

1. Разработчиков намного больше тестировщиков и функционала создается в разы больше, чем мы можем успевать проверять. Балансировать, искать людей в команду. Пока новые тестировщики не найдены, пусть помогают тестировать разработчики. Придется повозиться, но договориться обычно удается. Если ситуация продлиться довольно долго, то скоро это начнет надоедать разработчикам и они перейдут сразу к п.2 😀
2. Слишком много ручного тестирования. Систему можно и нужно учиться проверять автоматически. Это просто быстрее по времени и тот же самый регресс можно с 4 дней сократить до 1, покрыв самые важные кейсы автотестами. Если у вас нет специалистов, готовых писать автотесты завтра же, ищите, обучайте.
3. Разработчики берут на спринт “слонов”. Это я так образно назвала огромные истории на много-много стори-поинтов, которые еле умещаются в спринт и переходят в колонку 2QA ближе к его завершению. Конечно, за оставшееся время спринта их будет очень сложно проверить, не говоря уже о регрессе продукта. Поэтому у нас начинаются водопадные спринты и мы разрабатываем в 1 спринте, а тестируем и выпускаем во 2. Может какому-то бизнесу такая динамика ок, если вам не ок, начинайте декомпозировать. Есть множество способов разделения большой истории на части, зовите на такие встречи представителей бизнеса, спрашивайте, что из перечисленного несет самую большую пользу для них.
4. Предположим, и баланс тестеров соблюден, и автотесты вроде есть либо пишутся, и даже декомпозировать мы умеем. Но счастья все-равно нет.. Тут уже ваш выход, как коуча. Помогите команде понять, что она может делать, до того как разработка закончилась? Это могут быть: поддержка и написание автотестов, создание тест-кейсов, улучшение тестовых стендов и тестовых данных, документация, обучение, тестирование требований и прочее. На что вашей фантазии хватит и то, на что обычно не остается времени.

Знаете еще? Напишите мне и я их добавлю!