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

Предыстория

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

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

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

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

Кто же и как распределял задачи? Я в роли QA lead с доски аналитики брала задачи в статусе «Готово к грумингу», а также, где это было уместно, в статусе «Архитектурное ревью». Соответственно, у каждого тестировщика команды в день груминга был список задач для тестирования требований с учётом того, что он уже смотрел в прошлый раз, а также исходя из удобства рассмотрения нескольких задач на одну тематику за раз. Дисциплина и распределение ответственности сделали своё дело, мы действительно повысили качество тестирования требований.

Но этого нам было мало, и мы собрали чек-лист по тестированию требований, куда выносили общие принципы, на которые можно ориентироваться в этом процессе и стремиться минимально что-либо упустить. Делюсь им!

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

1.      Проверяем формат полей – например, если в названии поля для наших сервисов присутствует id, формат, вероятно, будет uuid (может не касаться, например, обращения к интеграционным сервисам, у них регламент может быть другой). Если указан тип string, может быть уместно ограничение по длине;

2.      Оставляем вопросы/обращаем внимание на наличие ссылки на swagger сервиса, с которым требуется интеграция в рамках задачи. Либо просим ссылку на задачу, в рамках которой метод, который мы будем использовать, будет реализован другой командой;

3.      Обращаем внимание на описание ошибок – при каких сценариях возникают (помимо наших типичных проверок на формат, длину и прочее), какие коды ответа, текст ошибки – особенно важно для вывода на фронт. Либо в аналитике должны сослаться на наши общие правила проектирования (здесь должна быть ссылка, но я вам её не отдам ?);

4.      Для макетов – проверяем опечатки, орфографию, пунктуацию. Также единообразие форматов (например, не руб, а RUB). Просим добавить макет с выводом ошибок (например, некорректный формат почты – ожидаем под полем красный текст ошибки или иную подсказку);

5.      Когда фронт прикрепляется к существующему бэку – просим ссылку на swagger с методом, дёргаем его и убеждаемся, что в теле ответа присутствуют все необходимые для вывода на фронт поля. Если какого-либо поля нет – создаём сразу связанную задачу на бэк;

6.      Если в ближайшем будущем будет фронт, должны быть параметры пагинации и сортировки. Если не реализовано – создаём сразу связанную задачу на бэк;

7.      Проверяем, отрабатывает ли бэк по всем параметрам для сортировки на фронте (уже выходит за рамки тестирования требований, но мы стремимся учесть и такие вещи);

8.      Расхождение аналитики и макетов (например, где требуется 2 знака после запятой для чисел, даже если 1.00, а также – через точку или запятую должно быть разделение);

9.      В целом хорошо бы, чтобы были в аналитике ссылки на задачи на разработку;

10.   Оставляем комментарии для аналитиков с любыми вопросами по реализации, процессу тестирования, бизнесовым нюансам. Указываем любые поля и доступы, которые, на ваш взгляд, лишние/не хватает;

11.   Если предстоит сложная интеграция на несколько модулей, не стесняемся запрашивать UML-диаграммы, описание полей и их форматов на каждом этапе. Представьте, что вы прямо сейчас по этой аналитике пишете тест-кейсы;

12.   Уточняем, если нет значения параметра -– ставится дефолтное значение/прочерк или не отображается весь блок на фронте?

13.   Классика: полнота, непротиворечивость, последовательность и прочее.

Давайте обсудим в комментариях, как выстроено тестирование требований у вас и на что вы обращаете внимание. До встречи!