Каждое утро QA-инженер с командой ходит в баню проверяет тестовое окружение. Он не может приступить к таскам, пока не докажет, что тестовое окружение в порядке. 

Ведь если без проверки запустить проекты в облаке, при создании тестовых данных обязательно вылезут ошибки. И тут на помощь приходит Postman — приложение для создания коллекций с запросами к вашему API.

Инструкцию по автоматизации проверок даю в этой статье.

Рутина пожирает время

В микросервисных архитектурах приложения могут использовать десятки сервисов. В нашем случае это:

• сервис авторизации

• сервисы расписаний

• сервис управления пользователями/клиентами

• сервис управления преподавателями

• сервисы биллинга

• сервисы маркетинга

• брокеры сообщений

• сервисы с camunda и temporal

• сервисы отпусков

… и список можно продолжать, если мощности сервера хватит.

Каждый сервис может «упасть» или «не подняться» после раскатки/загрузки окружения.

И пока мы не проверим их (желательно все), начинать тестирование рискованно: можно потратить много времени и обнаружить, что проблема не в коде новой ветки, а просто в недоступном сервисе.

Особенность нашей инфраструктуры

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

Например:

• У тестировщика Анны — окружение test-42

• У разработчика Михаила — окружение test-43

• У тестировщика Дмитрия — окружение test-44

Цена проводимых проверок перед началом работы.

Пара часов после обновления тестинга, при 2-3 обновлениях в неделю, это уже 4–6 часов — почти целый рабочий день.

Как это было раньше: 

1. Открываем браузер, логинимся.

2. Заходим в N сервисов.

3. Проверяем вручную.

4. Фиксируем (обычно в голове) результаты.

5. Думаем, что вроде бы всё работает и можно начинать заниматься самим тестированием.

6. В это время прилетает задача, а мы только половину сервисов чекнули…

7. Закончили проверки, и только после этого можем приступать к работе.

Решение — автоматический Health Check

Postman Collection Runner с правильно организованной коллекцией запускает все эти проверки одной кнопкой из привычного инструмента.

1. Открываете Postman и выбираете коллекцию Health Check.

2. Прописываете своё окружение (например, «Test-42») в Environments или глобальных переменных.

3. Запускаете Collection Runner.

Дальше система сделает всё за вас.

1. Пройдёт авторизацию.

2. Последовательно проверит все N сервисов на вашем окружении.

3. Создаст тестовые данные (учителей, студентов, услуги, начисления и т.д.)

4. Проверит интеграции между сервисами.

5. Протестирует критические API endpoints.

6. Пройдёт критические пользовательские сценарии и проводит другие проверки.

Через 7–8 минут вы увидите визуальный отчёт прямо в Postman:

✓ Suite 1: Login (1/1)

✓ Suite 1: ID Service (1/1)

✓ Suite 1: Schedule (1/1)

✓ Suite 1: TRMN (1/1)

✗ Suite 1: CRM (0/1)

✓ Suite 1: Billing API (1/1)

✓ Suite 1: RabbitMQ (1/1)

---

✓ Suite 2: Create data (1/1)

---

✗ Suite N: Crit_CJM (0/1)

В этом примере сразу видно: CRM не работает на вашем test-42. Получен 5ХХ — пора писать в  #dev-chat или в #devops-chat, остальное можно использовать для тестов.

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

Отличный поинт для более близкого знакомства с коллегами из других отделов и совместной работы!

Структура коллекции: организация проверок

Для начала стоит открыть любое приложение, позволяющее накидать саму схему проверок. Мы в Skyeng взяли блокнот и собрали URL всех самых критичных сервисов. Дальше используем Miro.

Все проверки организованы в Folders (папки) по определённой схеме:

Folder 1: Базовые проверки доступности

Suite_1_Basic_Health

• Авторизация в системе

• Проверка всех микросервисов (GET/POST запросы на health endpoints)

• Проверка RabbitMQ и других инфраструктурных компонентов

Folder 2: Подготовка данных для всех последующих Suite

Suite_2_Data_Preparation

• Создание преподавателей в сервисе ID

• Регистрация преподавателя в TRMN

• Активация рабочего времени

• Открытие набора

• Создание студентов в CRM

• Создание ещё чего-то нужного

На этом этапе можно подготовить данные и записать их значения в переменные на уровне коллекции или на уровне глобальных переменных. Эти значения будут использованы в последующих сьютах.

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

Folders 3-N: Проверки интеграций

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

Suite_3_CJM_workflow

• Полный путь от создания пользователя до назначения ему преподавателя

• Проверка отправки событий в шину Rabbit

• И так далее…

Практическое применение: несколько сценариев

Сценарий 1: Регулярные проверки

Когда: после каждого пересоздания тестового окружения (у нас это 2-3 раза в неделю).

1. Открываем Postman.

2. Выбираем Environment «Test-42».

3. Нажимаем «Run Collection».

4. Идём пить кофе.

Сценарий 2: Быстрая диагностика

Когда: когда нужно быстро проверить, что все базовые сервисы просто отвечают.

1. Открываем Postman.

2. Выбираем Environment «Test-42».

3. Нажимаем «Run» для папки, содержащей список api базовых сервисов.

Сценарий 3: Быстрое создание набора тестовых данных

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

1. Открываем Postman.

2. Выбираем Environment «Test-42».

3. Нажимаем «Run» для папки, содержащей наборы вызовов, генерирующих тестовые данные.

Сценарий 4: Использование двух и более тестовых окружений для работы

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

1. Открываем Postman.

2. Выбираем Environment «Test-X1». Делаем проверки, что все базово работает.

3. Выбираем Environment «Test-X2». Делаем проверки, что все базово работает.

4. Воспроизводим баг на окружении с мастер-веткой.

5. Тестируем исправление бага на окружении с веткой содержащей правки.

Сценарий 5: Онбординг нового сотрудника

Когда: например, новый коллега (QA/разработчик) просто хочет знать, какие сервисы разрабатывает команда.

1. Передаём коллекцию новому коллеге.

2. В течение дня он спокойно знакомится с базовыми сервисами.

Запускать коллекции можно не только в приложении Postman. Очень удобно это делать с помощью Newman.

Анализ результатов

Когда вы запустили коллекцию через Collection Runner или Newman, важно правильно интерпретировать полученные результаты. 

В интерфейсе Postman/Newman вы сразу увидите общую статистику: количество успешных и провалившихся тестов, общее время выполнения. Кликните на любой запрос с красным крестиком, чтобы увидеть детали ошибки: код ответа, тело ответа, время отклика и текст упавшего теста. 

Это поможет быстро понять, какой именно сервис недоступен и почему.

Следующие шаги

1. Составьте список из 5-10 критичных сервисов для проверки.  

2. Создайте базовую Postman-коллекцию с проверками этих сервисов.

3. Добавьте тесты (pm.test) к каждому запросу.  

4. Добавьте создание тестовых данных (Suite 2).

5. Добавьте проверки, которые покроют базовую интеграцию ваших сервисов, на самые критичные CJM.

Заключение

Автоматизация рутинных проверок в Postman — это не только экономия времени. 

Она даёт вам:

• Уверенность в стабильности окружения перед началом работы.

• Независимость — проверили своё окружение и работаете, не мешая другим.

• Фокус на интересных задачах вместо рутины.

• Профессиональный рост — навыки работы с API и автоматизацией.

• Вклад в качество продукта и культуру команды.

Для Health Check Postman подходит идеально, потому что:

✓ Вы уже знаете этот инструмент.  

✓ Не нужно писать код (только простые JS-скрипты для тестов).  

✓ У него понятный визуальный интерфейс.  

✓ Легко поделиться с командой.  

✓ Можно запускать вручную или автоматизировать через Newman.

✓ Легко переключаться между окружениями.

Начните с малого. 

Автоматизируйте проверку 5 самых критичных сервисов на своём окружении → покажите команде результат → расширяйте постепенно.

Помните: каждая сэкономленная минута рутины — это минута на то, что действительно требует вашей экспертизы. А когда каждый член команды экономит это время на обслуживании своего окружения — выигрывает вся команда.

Полезные ресурсы и советы

Больше информации о тестировании вы можете найти на этих сайтах.

1. https://learning.postman.com/ — официальная документация

2. https://learning.postman.com/docs/tests-and-scripts/write-scripts/variables-list/ — работа с динамическими переменными

3. https://learning.postman.com/docs/writing-scripts/test-scripts/ — гайд по тестам

4. https://learning.postman.com/docs/running-collections/intro-to-collection-runs/ — как запускать коллекции

5. https://learning.postman.com/docs/running-collections/using-newman-cli/ — для интеграции в CI/CD

6. https://community.postman.com/ — форум с ответами на вопросы

7. https://learning.postman.com/docs/sending-requests/managing-environments/ — как работать с окружениями

И вот несколько советов, чтобы автоматизация была ещё эффективнее.

• LLM поможет вам решить почти все попутные вопросы. Например, с тем, как прокинуть значения из ответов и записать их в переменные.

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

Ну а я с удовольствием отвечу на ваши комментарии — пишите!