В этой статье хочу поделиться, как мы с коллегами на проекте выстроили процесс по тестированию требований.
Предыстория
У нас двухнедельные спринты, в рамках которых с определённой периодичностью проходят груминги, на которых мы не только приоритизируем задачи, но и разбираем аналитику. Происходит это так: на регулярных встречах собирается вся команда, аналитики презентуют нам новую фичу/задачу, а мы задаём вопросы. Если все вопросы решены, либо что-то можно быстро уточнить/устранить, то команда двигает эту задачу в статус «Готово к разработке». И мы командой тестировщиков определили, что во время грумингов презентация аналитики происходит быстро, мы не успеваем параллельно читать и слушать пояснения, а также придумывать на ходу вопросы. Нужен был процесс по тестированию требований.
За несколько итераций проведённых 1-to-1 я выяснила, что нам было бы удобно построить это следующим образом: разделиться на подкоманды согласно функционалу, который мы реализуем, и до груминга читать аналитику, разбираться, оставлять комментарии с вопросами в спокойной обстановке без строго ограничения по времени.
Финальная идея была такова: для первой команды по понедельникам и средам в 11:00 висит напоминание в календаре, в котором указано «Постарайтесь посмотреть требования до 15:00. Тестировщик1 смотрит задачи: 123, 124; тестировщик2 смотрит задачи 125, 126».
В 15:00 мы созванивались и обсуждали задачи, в чём состоит реализация и какие вопросы/замечания удалось откопать. Иногда на этих встречах коллективным разумом мы находили что‑то ещё. В 16:00 мы во всеоружии приходили на груминг — мы уже читали и обсуждали реализацию, уже сформулировали и оставили в yonote вопросы, возможно, даже получили на них ответ там же. Для второй команды было то же самое, но по вторникам и четвергам.
Кто же и как распределял задачи? Я в роли QA lead с доски аналитики брала задачи в статусе «Готово к грумингу», а также, где это было уместно, в статусе «Архитектурное ревью». Соответственно, у каждого тестировщика команды в день груминга был список задач для тестирования требований с учётом того, что он уже смотрел в прошлый раз, а также исходя из удобства рассмотрения нескольких задач на одну тематику за раз. Дисциплина и распределение ответственности сделали своё дело, мы действительно повысили качество тестирования требований.
Но этого нам было мало, и мы собрали чек‑лист по тестированию требований, куда выносили общие принципы, на которые можно ориентироваться в этом процессе и стремиться минимально что‑либо упустить. Делюсь им!
Чек-лист для тестирования требований
Проверяем формат полей — например, если в названии поля для наших сервисов присутствует id, формат, вероятно, будет uuid (может не касаться, например, обращения к интеграционным сервисам, у них регламент может быть другой). Если указан тип string, может быть уместно ограничение по длине;
Оставляем вопросы/обращаем внимание на наличие ссылки на swagger сервиса, с которым требуется интеграция в рамках задачи. Либо просим ссылку на задачу, в рамках которой метод, который мы будем использовать, будет реализован другой командой;
Обращаем внимание на описание ошибок — при каких сценариях возникают (помимо наших типичных проверок на формат, длину и прочее), какие коды ответа, текст ошибки — особенно важно для вывода на фронт. Либо в аналитике должны сослаться на наши общие правила проектирования (здесь должна быть ссылка, но я вам её не отдам 😊);
Для макетов — проверяем опечатки, орфографию, пунктуацию. Также единообразие форматов (например, не руб, а RUB). Просим добавить макет с выводом ошибок (например, некорректный формат почты — ожидаем под полем красный текст ошибки или иную подсказку);
Когда фронт прикрепляется к существующему бэку — просим ссылку на swagger с методом, дёргаем его и убеждаемся, что в теле ответа присутствуют все необходимые для вывода на фронт поля. Если какого‑либо поля нет — создаём сразу связанную задачу на бэк;
Если в ближайшем будущем будет фронт, должны быть параметры пагинации и сортировки. Если не реализовано — создаём сразу связанную задачу на бэк;
Проверяем, отрабатывает ли бэк по всем параметрам для сортировки на фронте (уже выходит за рамки тестирования требований, но мы стремимся учесть и такие вещи);
Расхождение аналитики и макетов (например, где требуется 2 знака после запятой для чисел, даже если 1.00, а также — через точку или запятую должно быть разделение);
В целом хорошо бы, чтобы были в аналитике ссылки на задачи на разработку;
Оставляем комментарии для аналитиков с любыми вопросами по реализации, процессу тестирования, бизнесовым нюансам. Указываем любые поля и доступы, которые, на ваш взгляд, лишние/не хватает;
Если предстоит сложная интеграция на несколько модулей, не стесняемся запрашивать UML‑диаграммы, описание полей и их форматов на каждом этапе. Представьте, что вы прямо сейчас по этой аналитике пишете тест‑кейсы;
Уточняем, если нет значения параметра ‑– ставится дефолтное значение/прочерк или не отображается весь блок на фронте?
Классика: полнота, непротиворечивость, последовательность и прочее.
Давайте обсудим в комментариях, как выстроено тестирование требований у вас и на что вы обращаете внимание. До встречи!
