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

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

Предпосылки

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

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

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

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

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

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

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

1. Бекенд

2. Веб

3. Мобаил

4. Интеграции

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

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

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

3. Мобайл - это другая точка взаимодействия пользователей с системой. Она функционирует как самостоятельный клиент. Тест-кейсы из этой папки также проверяются сценарии пользователя и внешний вид системы.

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

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

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

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

2. Физическая граница: Разделение по типам системы (бэкенд, веб, мобайл) соответствует физической границе контекста. Различные части системы часто находятся в разных репозиториях, разрабатываются разными командами. Это создает естественные границы, облегчающие управление тестами и их будущую автоматизацию.

   ---

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

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

- Integration cases
  - User portal
  - Shops
  ...

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

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

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

2. Явное разделение видов интеграции: Деление по видам интеграции позволяет четко выделить границы каждого контейнера.

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

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: Микрофронтенд

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

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

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

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

3. Возможно, что-то ещё?

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

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

Плюсы:

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

• Легко находить тесты для специфического провайдера, что важно для быстрого обновления локальных функциональностей.

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

Плюсы:

• Четкое деление по типу тестов позволяет лучше контролировать покрытие (где именно есть пробелы: функциональность или UI).

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

Минусы:

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

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

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

1. Первый уровень деление на функциональные и UI-тесты.

2. Внутри них создается вложенность по провайдерам.

- 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. Ограниченный контекст: Тест-кейсы следует группировать по логическим модулям или компонентам системы, обеспечивая, чтобы каждый тест-сьют охватывал определенный контекст без пересечения с другими областями.

3. Связанность и связность:

   • Высокая связность: Тесты внутри одного сьюта должны быть тесно связаны по смыслу, проверяя различные аспекты одной и той же функциональности.

   • Низкая связанность: Минимизируйте зависимости между различными наборами тестов (сьютов), чтобы изменения в одной части системы требовали изменения только соответствующего тест-сьюта.

4. Принцип общего повторного использования: Объединяйте в один тест-кейс проверки, которые всегда изменяются совместно, чтобы избежать избыточности.

5. Принцип общего закрытия: Тесты, которые могут изменяться по одним и тем же причинам, следует группировать вместе, чтобы упростить их поддержку и обновление при внесении изменений в систему.

6. Принцип ацикличности зависимостей: Структурируйте тесты так, чтобы избежать циклических зависимостей, обеспечивая независимость и модульность тестов.

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

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

1. Делайте глоссарий в вашем репозитории тест-кейсов - общий глоссарий поможет унифицировать подход к написанию тест-кейсов.

2. Введите определение основных терминов, чтобы не было путаницы в их интерпретации.

3. Четко обозначьте, что является системой для тестирования и покрытия тестами данного репозитория (фокус).

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

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

1. Задачу в системе трекинга задач (Jira например).

2. Notion - Документацию фичи (если она есть).

3. Miro – ссылка на схему или процесс, разработанный для фичи.

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

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