Привет, меня зовут Азалия. Рада что когда-то выбрала Айти и вот уже 7 из 13 лет в тестировании. Что касается сферы - до последних 2 лет в маркетплейсе, был ФинТех. Хочется поделиться накопленным опытом и начать с самой больной темы как для практика – описание тейст кейсов.

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

Рассмотрим на примере простого приложения с админкой. Веб часть наполняет и управляет данными через сервер, реализующий методы на Rest архитектуре.

Организуем 2 больших блока: фронт и бек. Начнем с бека, а фронт рассмотрим позже.

Главное - структуры тест кейсов, по беку она может дублировать свагер. Так будет проще ориентироваться в версиях и блоках предоставляемой функциональности (например отдельно получение списков от создания и изменения) и выделим блок общие проверки – универсальные для микросервисов и/или методов. Получится такое дерево: Бекенд –> Общие проверки -> Микросервис –> Версия –> Группа –> Сами методы.

Ниже в примере предлагаю достаточно обширный вариант, которы содержит все самое необходимое для полноценного функционирования системы. Общие проверки в виде чек-листа, где, каждая из которых отдельный шаг, н�� предполагающий описания ожидаемого результата.

Раздел Общие проверки

Кейс 1. Новый сервис – кейс с шагами чек-листом

Отдельный репозиторий
Пространство в инфраструктуре проекта (кубер и т.п.)
Хост
Свагер
Миграция на создание БД
Хелсчеки
Логирование (кибана/грейлог)
Трейс в jager
Метрики в графане
Настройка деплоя
Настройка запуска автотестов

Кейс 2. Логирование

Бизнес логика в Info уровне
Ошибки с уровнем error
Подробные логи в debug
Скрыты или замаскированы чувствительные данные (персональные, логин-пароль)
Есть идентификаторы по которым можно отследить всю цепочку/последовательность вызывов в рамках метода

Первые 2 относятся к создания нового сервиса, а кейсы ниже будут уже применимы и к конкретным методам.

Кейс 3. Действия с БД:

Поля соответствуют описанию
Типы данных соответствуют описанию/логике
Обязательность/необязательность полей
Индекс
Внешние ключи и связь с другой таблицей
Пустое значение (null)
Миграция на создание
Миграция на добавление/обновление/заполнение данными

Кейс 4. Коды ошибок

Тут уже можно дополнить ожидаемый результат структурой ответа, т.к. она более вариативна и зависит от архитектуры системы и договоренностей внутри компании.

Ошибка аутентификации (401 с описанием и внутренними кодами)
Ошибка авторизации (403 с описанием и внутренними кодами)
Клиентские ошибки (422 с описанием и внутренними кодами)
Серверные ошибки (500 с описанием и внутренними кодами)

Раздел. Микросервис/сервис

Подраздел V1

Подраздел Группа методов

Подраздел Метод

Кейс 1

Предусловие: Что и как делает метод, ссылка на документацию. Приложить курл и описание подготовки входных тестовых данных.

Каждый шаг раскрывает важную функциональную позитивную проверку.
Корнер кейсы
Важные негативные тут же или вынести в отдельный кейс, если их много

Может возникнуть справедливое замечание, что такая структура, где в одном кейсе много шагов и проверок, противоречит теории атомарности создания тест кейсов. Да, все так на практике мы часто уходим от теории. Когда я вижу список «правильных» кейсов у меня разбегаются глаза и возникает вопрос а как же все таки должен работать тот или иной сервис/метод. Даже пройдя их все, мне сложно быть уверенной что система работает и ничего не упущено. Так же возникает жуткое сопротивление проходить мелкие, зачастую однотипные кейсы, которые еще и займут много времени, особенно если сталкиваться с ними в первый раз.

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

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

Да, нужна тренировка и сноровка, но результат не заставит себя ждать.

Тест-кейсы как справочник проекта