И снова привет, Хабр!
Любите ли вы чек-листы так, как люблю их я?
Как‑то на старте проекта мы с командой тестировщиков задались вопросом, чего бы такого внедрить, чтобы меньше находить друг за другом багов. Придумали, что нужно ревьюить тест‑кейсы — так больше шансов, что правильно поняли аналитику (как минимум, две головы лучше, чем одна), а также будет больше разнообразия по сценариям.
В этом процессе осознали, что каждый обращает внимание на что‑то своё, и пора бы это стандартизировать и расшарить на команду (обмен опытом, наш любимый). Так был создан чек‑лист проверок для ревьюера тест‑кейсов.
Хорошая практика, когда сначала по нему проходишь сам, а потом уже отдаёшь коллеге в более чистом виде. С ним, кстати, удалось и подтянуть менее опытных коллег — например, они использовали его как шпаргалку, где ожидаемый результат должен быть 400, а где — 404, какие проверки валидны, какие — уже и нет, а какие — следует добавить. Поехали!
Чек‑лист для ревьюера тест‑кейсов
Название тест‑кейса соответствует содержанию (база, но при клонировании можно упустить);
В названии тест‑кейса присутствует ожидаемый код ответа (нам так удобно делать тест‑планы/запуски);
Указаны корректные теги — сервис, позитивный/негативный, smoke;
Указан приблизительно корректный приоритет;
На основе тегов и приоритета — статусы или другие теги для автоматизаторов, например: позитивный+высокий приоритет → AT_Ready (готово к автоматизации), AT_Done — автоматизирован;
На каждый шаг есть ожидаемый результат (код ответа, тело ответа, есть/нет запись в БД, проверка полей записи в БД, логирование и др.). Например, в тестОпс можно создавать шаг + ожидаемый результат одной сущностью. Если такой возможности нет, следует пронумеровать шаги и ожидаемый результат;
Тест‑кейс связан с задачей (если такое есть в TMS — test management system);
Указана feature/story, либо есть логичное разбиение по папкам;
Нет связей клонирования;
Есть автор (хорошо, если личная, а не техническая общая учётка);
В названии тест‑кейса в начале указан номер для удобного последовательного прохождения при регрессе (уместно, если не используете общие шаги);
Задача/story имеет достаточное тестовое покрытие тест‑кейсами, таблица проверок:
Проверки
Поле1
Поле2
Поле3
Поле4
Корректное значение
NULL (отсутствие поля)
Пустое значение ("")
Пробел (" ")
Превышение длины значения
Другой формат
Несуществующее значение (хардкод/интеграция со справочником)
Примечание:
Несуществующее значение: корректный формат (например, uuid), но отсутствующий в БД, либо несуществующее значение из справочника, в который обращаемся при интеграции.
ОР: 404, в теле ответа указано, что нет такого
законазначения.Некорректное значение: некорректный формат (например, длиннее/короче uuid).
ОР: 400, вывод некорректного поля в теле ответа.
Если в структуре JSON есть массив, таблица проверок:
Элемент1
Элемент2
Присутствует, корректный
Отсутствует
Присутствует, корректный
Присутствует, корректный
Присутствует, корректный
Присутствует, некорректный
Присутствует, некорректный
Присутствует, некорректный
Отсутствует
Отсутствует
Есть позитивный пример JSON или curl в отдельном блоке или во вложении в виде файла;
Если тест-кейс неактуален ввиду изменения аналитики, он имеет статус «Устаревший» (в комментариях к кейсу хорошо бы описать, в чем он устарел; можно добавить ссылку на задачу, в рамках которой произойдут изменения в аналитике);
Если тест-кейс неактуален ввиду того, что еще нет реализации, он может быть помещён в карантин (с добавлением комментария), либо можно создать для него отдельный статус по workflow;
Если найден дефект, он прилинкован к соответствующему тест-кейсу вместе с задачами, либо отдельно;
Моя личная придирка: тест-кейс не имеет шагов «Открыть swagger/postman, найти такой-то запрос, добавить jwt, вставить тело, нажать Execute», сразу к делу: отправить POST /api/v1/create с {условие для тела}.
Делитесь в комментариях, насколько шпаргалка полезна, а также — на что обращаете внимание вы, когда пишете тест‑кейсы, либо читаете у коллег!
До скорого!
