Чек-лист для тестирования требований

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

Предыстория

У нас двухнедельные спринты, в рамках которых с определённой периодичностью проходят груминги, на которых мы не только приоритизируем задачи, но и разбираем аналитику. Происходит это так: на регулярных встречах собирается вся команда, аналитики презентуют нам новую фичу/задачу, а мы задаём вопросы. Если все вопросы решены, либо что-то можно быстро уточнить/устранить, то команда двигает эту задачу в статус «Готово к разработке». И мы командой тестировщиков определили, что во время грумингов презентация аналитики происходит быстро, мы не успеваем параллельно читать и слушать пояснения, а также придумывать на ходу вопросы. Нужен был процесс по тестированию требований. 

За несколько итераций проведённых 1-to-1 я выяснила, что нам было бы удобно построить это следующим образом: разделиться на подкоманды согласно функционалу, который мы реализуем, и до груминга читать аналитику, разбираться, оставлять комментарии с вопросами в спокойной обстановке без строго ограничения по времени.

Финальная идея была такова: для первой команды по понедельникам и средам в 11:00 висит напоминание в календаре, в котором указано «Постарайтесь посмотреть требования до 15:00. Тестировщик1 смотрит задачи: 123, 124; тестировщик2 смотрит задачи 125, 126».

В 15:00 мы созванивались и обсуждали задачи, в чём состоит реализация и какие вопросы/замечания удалось откопать. Иногда на этих встречах коллективным разумом мы находили что-то ещё. В 16:00 мы во всеоружии приходили на груминг – мы уже читали и обсуждали реализацию, уже сформулировали и оставили в yonote вопросы, возможно, даже получили на них ответ там же. Для второй команды было то же самое, но по вторникам и четвергам.

Читать далее
7