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

в 15:38, , рубрики: тест-кейсы, тестирование по

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

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

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

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

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

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

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

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

  • Отдельный репозиторий 

  • Пространство в инфраструктуре проекта (кубер и т.п.)

  • Хост

  • Свагер

  • Миграция на создание БД

  • Хелсчеки

  • Логирование (кибана/грейлог)

  • Трейс в jager

  • Метрики в графане

  • Настройка деплоя

  • Настройка запуска автотестов

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

  • Бизнес логика в Info  уровне

  • Ошибки с уровнем error

  • Подробные логи в debug

  • Скрыты или замаскированы чувствительные данные (персональные, логин-пароль)

  • Есть идентификаторы по которым можно отследить всю цепочку/последовательность вызывов в рамках метода

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

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

  • Поля соответствуют описанию

  • Типы данных соответствуют описанию/логике

  • Обязательность/необязательность полей

  • Индекс

  • Внешние ключи и связь с другой таблицей

  • Пустое значение (null)

  • Миграция на создание

  • Миграция на добавление/обновление/заполнение данными

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

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

  • Ошибка аутентификации (401 с описанием и внутренними кодами)

  • Ошибка авторизации (403 с описанием и внутренними кодами)

  • Клиентские ошибки (422 с описанием и внутренними кодами) 

  • Серверные ошибки (500 с описанием и внутренними кодами)

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

Подраздел V1

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

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

                Кейс 1

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

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

  2. Корнер кейсы

  3. Важные негативные тут же или вынести в отдельный кейс, если их много

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

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

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

  • вспомнить нюансы, если нужны доработки или рефакторинг;

  • пользоваться всем членам команды;

  • поддерживать единую структуру методов и сервисов за счет блока общих проверок.

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

Автор: azal_ka

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js