Как я написал 15 000+ автотестов в Postman и перестал бояться релизов

В этой статье я расскажу, как за полтора года я написал более 15 000 автоматизированных тестов в Postman для ITSM-платформы, и как это изменило наш подход к качеству.

С чего всё началось

Работая системным аналитиком в .tech, я отвечал за развитие ITSM-платформы — системы управления IT-сервисами. Мы быстро росли, добавляли новые интеграции, и с каждым релизом регрессионное тестирование занимало всё больше времени.

QA-инженеры тратили 2-3 дня на ручную проверку API перед каждым релизом. И всё равно баги проскакивали в прод. Знакомая ситуация?

Почему Postman

Выбор пал на Postman по нескольким причинам:

• Низкий порог входа — писать тесты могут и аналитики, и разработчики
• Runner и Collection Runs — можно прогонять наборы тестов одной кнопкой
• Работа с переменными — легко переключаться между окружениями
• Chaining запросов — передача данных между запросами через переменные
• Newman — запуск из CI/CD

Архитектура тестов

Я разбил тесты на несколько уровней:

1. Смоук-тесты — проверка, что сервис жив и отвечает (50 тестов)
2. Функциональные тесты — проверка бизнес-логики каждого эндпоинта (5 000+ тестов)
3. Интеграционные тесты — проверка связанных сценариев (7 000+ тестов)
4. Негативные тесты — проверка обработки ошибок (3 000+ тестов)

Как это работает

Каждый тест — это набор запросов, объединённых в сценарий. Например, тест создания заявки:

// 1. Авторизация → получаем токен
// 2. Создаём заявку → получаем ID
// 3. Проверяем статус заявки
// 4. Назначаем исполнителя
// 5. Проверяем уведомление

Тесты используют переменные окружения — при переключении между dev/stage/prod меняется только base URL.

Результаты

• Сократили время регрессионного тестирования с 3 дней до 4 часов
• Количество багов в продукте снизилось на 60%
• QA теперь фокусируются на сложных сценариях, а не на рутине
• Релизы стали выходить чаще и стабильнее

Главные выводы

Автоматизация тестирования — это не про "заменить тестировщиков". Это про то, чтобы дать команде уверенность в каждом релизе. Когда у тебя 15 000 тестов, которые прогоняются за час, ты перестаёшь бояться нажимать кнопку "Deploy".

Если вы только начинаете путь автоматизации — начните с малого. Напишите 10 тестов на самый критичный сценарий. Потом 20. Потом 100. Через полгода вы удивитесь, как работали без этого раньше.