Чек-лист ревьюера тест кейсов

И снова привет, Хабр!

Любите ли вы чек-листы так, как люблю их я?

Как-то на старте проекта мы с командой тестировщиков задались вопросом, чего бы такого внедрить, чтобы меньше находить друг за другом багов. Придумали, что нужно ревьюить тест-кейсы – так больше шансов, что правильно поняли аналитику (как минимум, две головы лучше, чем одна), а также будет больше разнообразия по сценариям.

В этом процессе осознали, что каждый обращает внимание на что-то своё, и пора бы это стандартизировать и расшарить на команду (обмен опытом, наш любимый). Так был создан чек-лист проверок для ревьюера тест-кейсов.

Хорошая практика, когда сначала по нему проходишь сам, а потом уже отдаёшь коллеге в более чистом виде. С ним, кстати, удалось и подтянуть менее опытных коллег – например, они использовали его как шпаргалку, где ожидаемый результат должен быть 400, а где – 404, какие проверки валидны, какие – уже и нет, а какие – следует добавить. Поехали!

Чек-лист для ревьюера тест-кейсов

1. Название тест-кейса соответствует содержанию (база, но при клонировании можно упустить);

2. В названии тест-кейса присутствует ожидаемый код ответа (нам так удобно делать тест-планы/запуски);

3. Указаны корректные теги – сервис, позитивный/негативный, smoke;

4. Указан приблизительно корректный приоритет;

5. На основе тегов и приоритета – статусы или другие теги для автоматизаторов, например: позитивный+высокий приоритет -> AT_Ready (готово к автоматизации), AT_Done – автоматизирован;

6. На каждый шаг есть ожидаемый результат (код ответа, тело ответа, есть/нет запись в БД, проверка полей записи в БД, логирование и др.). Например, в тестОпс можно создавать шаг + ожидаемый результат одной сущностью. Если такой возможности нет, следует пронумеровать шаги и ожидаемый результат;

7. Тест-кейс связан с задачей (если такое есть в TMS – test management system);

8. Указана feature/story, либо есть логичное разбиение по папкам;

9. Нет связей клонирования;

10. Есть автор (хорошо, если личная, а не техническая общая учётка);

11. В названии тест-кейса в начале указан номер для удобного последовательного прохождения при регрессе (уместно, если не используете общие шаги);

12. Задача/story имеет достаточное тестовое покрытие тест-кейсами, таблица проверок:

Примечание:

• Несуществующее значение: корректный формат (например, uuid), но отсутствующий в БД, либо несуществующее значение из справочника, в который обращаемся при интеграции.

  ОР: 404, в теле ответа указано, что нет такого закона значения.

• Некорректное значение: некорректный формат (например, длиннее/короче uuid).

  ОР: 400, вывод некорректного поля в теле ответа.

13. Если в структуре JSON есть массив, таблица проверок:

14. Есть позитивный пример JSON или curl в отдельном блоке или во вложении в виде файла;

15. Если тест-кейс неактуален ввиду изменения аналитики, он имеет статус «Устаревший» (в комментариях к кейсу хорошо бы описать, в чем он устарел; можно добавить ссылку на задачу, в рамках которой произойдут изменения в аналитике);

16. Если тест-кейс неактуален ввиду того, что еще нет реализации, он может быть помещён в карантин (с добавлением комментария), либо можно создать для него отдельный статус по workflow;

17. Если найден дефект, он прилинкован к соответствующему тест-кейсу вместе с задачами, либо отдельно;

18. Моя личная придирка: тест-кейс не имеет шагов «Открыть swagger/postman, найти такой-то запрос, добавить jwt, вставить тело, нажать Execute», сразу к делу: отправить POST /api/v1/create с {условие для тела}.

Делитесь в комментариях, насколько шпаргалка полезна, а также – на что обращаете внимание вы, когда пишете тест-кейсы, либо читаете у коллег!

До скорого!