Тест-кейсы: сортировка и гранулярность в репозитории

Я не могу раскрыть примеры моих репозиториев из-за политики конфиденциальности компании, поэтому постараюсь рассказать абстрактно, насколько это возможно.

Все знают, как писать тест-кейсы (конкретный тест кейс). В интернете достаточно статей на эту тему. Но вот как составлять карту тест-кейсов, особенно в условиях микросервисной архитектуры? Какую стратегию для этого выбрать? На эту тему я до сих пор не встречала хорошей статьи. Поэтому вот вам одна из них 😊)

Предпосылки

У меня сейчас несколько доменов: Определения личности пользователя, Санкции, Микрофронтенд, Апп приложение маркет. Я также унаследовала и занималась переносом тест-кейсов из очень множества других проектов: фрод, магазины, банковские карты, кабинет пользователя и прочее.

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

С чего начать?

Не будем изобретать велосипед и применим C4-модель (Context, Container, Component, Code) к нашему репозиторию. Эта модель позволяет структурировать сложные системы от контекста до отдельных компонентов.

Первый уровень: Контекст (Context)

“Контекст (Context): показывает систему в окружении пользователей и взаимодействующих с ней внешних систем.”

Первый уровень тест-кейсов содержит следующие папки:

Бекенд
Веб
Мобаил
Интеграции

- Integration cases   - ... - Back end cases   - ... - Front end (Web) cases   - ... - Front end (Mobile) cases   - ...

Бэкенд — это «сердце» системы, обеспечивающее обработку данных, выполнение бизнес-логики, взаимодействие с другими частями системы и внешними сервисами. Бекенд может тестироваться не зависимо от фронта проверяя заложенную бизнес логику. Тест-кейсы в этой категории фокусируются на проверке бизнес логики заложенной в сервисе бекенда.
Веб — это точка взаимодействия конечного пользователя с системой. Это та часть системы, которая «общается» с бэкендом для получения данных. Тест-кейсы этой папки фокусируются на 1) проверки сценарии пользователя, 2) проверке верстки и внешнего вида системы.
Мобайл — это другая точка взаимодействия пользователей с системой. Она функционирует как самостоятельный клиент. Тест-кейсы из этой папки также проверяются сценарии пользователя и внешний вид системы.
Интеграции — это папка содержит тест-кейсы которые проверяют взаимодействие нашей системы с внешними системами и микросервисами которых вызываем мы и которые вызывают нас. Точки входа в нашу систему и точки выхода из нашей системы проверяется здесь. В условиях микросервисной (а именно такая архитектура у нас в компании) архитектуры это подход жизненно необходим. Мы отделяем точки входа и точки выхода из системы в отдельный под каталог.

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

Почему такое деление:

Разделение зон ответственности: Это деление позволяет четко разграничить области системы, которые должны покрываться тестами. Оно делает тесты более структурированными и упрощает навигацию по проекту. Каждая папка (сьют набор) имеет свой контекст и этот контекст является целью тестирования этого сьюта. К примеру тест-кейсы на веб и на мобиле начинаются с момента когда все внешние условия (пред условия) входа в систему были выполнены (в Pre-conditions) и не важна, как мы попали в систему (через моки или через путь пользователя). Эти тесты сфокусированы на тестирования конкретно нашей системы а не пред условий. Тест-кейсы на интеграции фокусируются на интеграции (вызов нашей системы из магазина например).
Физическая граница: Разделение по типам системы (бэкенд, веб, мобайл) соответствует физической границе контекста. Различные части системы часто находятся в разных репозиториях, разрабатываются разными командами. Это создает естественные границы, облегчающие управление тестами и их будущую автоматизацию.

Второй уровень: Контейнеры (Containers) — Integration

Контейнеры (Containers): детализирует основные исполняемые элементы системы и их взаимодействия.

- Integration cases   - User portal   - Shops   ...

В разрезе папки интеграционных тестов контейнерами мы считаем интеграции со сторонними сервисами (например, «Shops», «User portal»).

Это дает следующие плюсы:

Логическая изоляция и распределение ответственности: Каждое направление (например, Shops, User portal) представляет отдельную область ответственности сторонней системы.
Явное разделение видов интеграции: Деление по видам интеграции позволяет четко выделить границы каждого контейнера.

Пример из проекта Микрофронт

Shops интеграция: Она проверяется точку входа в Microfront KYC flow. Эти тест-кейсы проверяет 1) что для нового пользователя в сервисе Shops есть вход в KYC flow 2) что для старого пользователя входа в вход в KYC flow нет (он прошел ее в прошлом).

Второй уровень: Контейнеры (Containers) — Back end

Для back end проекта я использую следующий подход: я выделяю основные ключевые сущности бекенда, например: session, event, order, cart. После этого создает тест-сью тестирующий эти сущности. В тест-сьюте, связанным с каждой из этих сущностей, будут находиться тест-кейсы, фокус тестирования которых будет направлен на соответствующую сущность.

Это подход позволяет держать фокус тестирования на одном объекте и не пытаться в одном ТК проверить все.

Пример:

В тестах на order происходит создание session и отправка events, но проверка session или event не является часть этих ТКs. Фокус проверки в этих ТКс лежит на order сущности.
Аналогично, основная проверка events осуществляется в разделе тестов, посвященных events. Когда проверяется event на создания (это может быть создание order или другой обект) фокус в этих тестах идет на проверке event логики.

Второй уровень: Контейнеры (Containers) — Front end and Mobile

Переходим к самому интересному разделу — Front end.

Пример №1: Микрофронтенд

Возьмём пример — микрофронтенд и порассуждаем о нём. В этой системе есть проверка личности и провайдеры, которые выполняют эту проверку.

Здесь можно выделить три подхода для определения следующего уровня вложенности:

Бизнес сущность провайдер: Разделить тест-кейсы по провайдерам, а дальше ввести деления на функциональные и UI сценарии. Здесь упор делается на уникальность провайдеров во flow.
Тип тестов: Разделить тест-кейсы на функциональные и UI, а уже внутри делать деление по провайдерам. Здесь упор делается на уникальность провайдера во flow.
Возможно, что-то ещё?

На данный момент у меня нет единого подхода.

1. Разделение тест-кейсов по провайдерам → функциональные и UI сценарии

Плюсы:

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

2. Разделение тест-кейсов на функциональные и UI → провайдеры

Плюсы:

Четкое деление по типу тестов позволяет лучше контролировать покрытие (где именно есть пробелы: функциональность или UI).
Удобно для модульного тестирования, если команда или процессы организованы по уровням (например, одна команда отвечает за функциональные тесты, другая — за UI). Проще автоматизировать: тест-кейсы с замоканным бекендам лежат в UI папке. Тест-кейсы для e2e тестов лежат в папке функциональные тест-кейсы.

Минусы:

Дублирование структуры папок: в каждом каталоге будут повторяться одни и те же подкаталоги для каждого провайдера.

Как выбрать оптимальный вариант?

Я считаю здесь могут быть разный подход в зависимости от команды и проекта. Мой подход следующий:

Первый уровень деление на функциональные и UI-тесты.
Внутри них создается вложенность по провайдерам.

- Functional Tests   - [Provider_1]       - Test case 1       - Test case 2   - [Provider:2]       - Test case 1       - Test case 2 - UI Tests   - [Provider_1]       - Test case 1       - Test case 2

Этот подход позволяет мне чётко разграничивать функциональные и UI-тесты (для дальнейшей автоматизации)

Пример №2: Пользовательские проверки

Пользовательские проверки анализируют определённые проверочные данные пользователя. Каждая проверка является атомарной и может выполняться независимо от остальных.

Для этого проекта мы выбрали другое деление:

- Front end (Web) - Проверка 1   - Functional cases       - UI check cases - Проверка 2   - Functional cases       - UI check cases - Front end (Mobile) - Проверка 1   - Functional cases       - UI check cases

Почему так?

Основное разделение по проверкам связано с их природой как независимых модулей. Проверка 1 может быть вызвана одна (без других проверок). Проверки в интерфейсе атомарные единицы (их набор может быть от 0 до 5).

По сути, каждая проверка это отдельный контейнер внутри микросервиса. Каждая проверка — это самостоятельная область ответственности, и выбранная структура чётко это отображает.

Итог:

Для Микрофронтенд я бы выбрала подход с делением на функциональные и UI-тесты → провайдеры, потому что это позволит в будущем лучше покрывать автотестами эти ТКс.
Для Проверок я бы выбрала деление по модулям (проверкам) так как оно лучше отражает природу системы и её тестируемые области.

Третий уровень: Component (Front/Mobile)

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

Для создания и организации тестов внутри контейнера мы придерживаемся принципа разделения ответственности и группировки по компонентам. Обычно этот слой мы примеряем только для Front/Mobile тестов. В других папках такая вложенность избыточна.

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

Дополнительно, мы выделяем проверки модульного функционала в отдельные тест-кейсы. К примеру:

Проверка поиска,
Проверка восстановления пароля,
Проверка навигации,
Проверка валидации данных.

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

Правила которые помогают проверить тест-кейсы на правильную группировку

Для проверки тест-кейсов на правильную архитектуру можно применять следующие правила (опираясь на принципы гранулярности микросервисов):

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

Полезные советы

Полезный совет №1:

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

Полезный совет №2:

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

Задачу в системе трекинга задач (Jira например).
Notion — Документацию фичи (если она есть).
Miro – ссылка на схему или процесс, разработанный для фичи.

Полезный совет №3:

Разделяйте тест-кейсы по репозиториям. Если вы тестируете большой домен, состоящий из 10 микросервисов, оптимальным решением будет разделить общий репозиторий с тест-кейсами этого домена на подрепозитории. Это позволяет не размазывать фокус тестирования.

ссылка на оригинал статьи https://habr.com/ru/articles/866346/