Привет, меня зовут Азалия. Рада что когда-то выбрала Айти и вот уже 7 из 13 лет в тестировании. Что касается сферы - до последних 2 лет в маркетплейсе, был ФинТех. Хочется поделиться накопленным опытом и начать с самой больной темы как для практика – описание тейст кейсов.
Тест-кейс — алгоритм действий для проверки написанной программы, что проверок достаточно для релиза, а так же понимания как система должна работать. Вот от такого немного мной дополненного определения и будем отталкиваться. Если присмотреться для чего же на самом деле используются и пишутся кейсы, то получается, что для прогонов, отчетов и регрессов. В итоге получается большой набор очень разных тестов, порой повторяющих друг друга, не имеющих общей логики и понятной структуры. Приходится добавлять метки, собирать и писать отдельно кейсы для конкретного вида тестирования (автоматизированного, интеграционного или регрессионного). Хотелось бы решить эти проблемы и получить кейсы, которые стали кладезю знаний как система работает на самом деле.
Рассмотрим на примере простого приложения с админкой. Веб часть наполняет и управляет данными через сервер, реализующий методы на Rest архитектуре.
Организуем 2 больших блока: фронт и бек. Начнем с бека, а фронт рассмотрим позже.
Главное - структуры тест кейсов, по беку она может дублировать свагер. Так будет проще ориентироваться в версиях и блоках предоставляемой функциональности (например отдельно получение списков от создания и изменения) и выделим блок общие проверки – универсальные для микросервисов и/или методов. Получится такое дерево: Бекенд –> Общие проверки -> Микросервис –> Версия –> Группа –> Сами методы.
Ниже в примере предлагаю достаточно обширный вариант, которы содержит все самое необходимое для полноценного функционирования системы. Общие проверки в виде чек-листа, где, каждая из которых отдельный шаг, не предполагающий описания ожидаемого результата.
Раздел Общие проверки
Кейс 1. Новый сервис – кейс с шагами чек-листом
-
Отдельный репозиторий
-
Пространство в инфраструктуре проекта (кубер и т.п.)
-
Хост
-
Свагер
-
Миграция на создание БД
-
Хелсчеки
-
Логирование (кибана/грейлог)
-
Трейс в jager
-
Метрики в графане
-
Настройка деплоя
-
Настройка запуска автотестов
Кейс 2. Логирование
-
Бизнес логика в Info уровне
-
Ошибки с уровнем error
-
Подробные логи в debug
-
Скрыты или замаскированы чувствительные данные (персональные, логин-пароль)
-
Есть идентификаторы по которым можно отследить всю цепочку/последовательность вызывов в рамках метода
Первые 2 относятся к создания нового сервиса, а кейсы ниже будут уже применимы и к конкретным методам.
Кейс 3. Действия с БД:
-
Поля соответствуют описанию
-
Типы данных соответствуют описанию/логике
-
Обязательность/необязательность полей
-
Индекс
-
Внешние ключи и связь с другой таблицей
-
Пустое значение (null)
-
Миграция на создание
-
Миграция на добавление/обновление/заполнение данными
Кейс 4. Коды ошибок
Тут уже можно дополнить ожидаемый результат структурой ответа, т.к. она более вариативна и зависит от архитектуры системы и договоренностей внутри компании.
-
Ошибка аутентификации (401 с описанием и внутренними кодами)
-
Ошибка авторизации (403 с описанием и внутренними кодами)
-
Клиентские ошибки (422 с описанием и внутренними кодами)
-
Серверные ошибки (500 с описанием и внутренними кодами)
Раздел. Микросервис/сервис
Подраздел V1
Подраздел Группа методов
Подраздел Метод
Кейс 1
Предусловие: Что и как делает метод, ссылка на документацию. Приложить курл и описание подготовки входных тестовых данных.
-
Каждый шаг раскрывает важную функциональную позитивную проверку.
-
Корнер кейсы
-
Важные негативные тут же или вынести в отдельный кейс, если их много
Может возникнуть справедливое замечание, что такая структура, где в одном кейсе много шагов и проверок, противоречит теории атомарности создания тест кейсов. Да, все так на практике мы часто уходим от теории. Когда я вижу список «правильных» кейсов у меня разбегаются глаза и возникает вопрос а как же все таки должен работать тот или иной сервис/метод. Даже пройдя их все, мне сложно быть уверенной что система работает и ничего не упущено. Так же возникает жуткое сопротивление проходить мелкие, зачастую однотипные кейсы, которые еще и займут много времени, особенно если сталкиваться с ними в первый раз.
Если же фокус кейса на описании сути метода, его основной задачи, важных проверок, то идет более глубокое погружение в функциональность, в ходе прохождения могут появиться дополнительные идеи проверок свежим взглядом (избегаем эффект пестицида – когда одни и те же кейсы пропускают баги). Плюс на своей же практике ни раз убеждалась, что в результате получается полноценный справочник проекта, который позволяет:
-
быстрее погружать новичков и не только тестировщиков, потому что легко читается и воспринимается, за счет своей компактности;
-
вспомнить нюансы, если нужны доработки или рефакторинг;
-
пользоваться всем членам команды;
-
поддерживать единую структуру методов и сервисов за счет блока общих проверок.
Да, нужна тренировка и сноровка, но результат не заставит себя ждать.
Автор: azal_ka