Привет всем заглянувшим!
В этой статье я поделюсь опытом автоматизации API‑тестирования связкой Postman + Newman, но с небольшим "секретным ингредиентом". Мы не просто будем запускать коллекции в Jenkins напрямую, а используем универсальный Python‑скрипт, который превращает стандартный прогон в мощный инструмент мониторинга.
В зрелом iOS-проекте автоматизированные тесты — давно не экзотика. Unit-тесты проверяют отдельные компоненты, интеграционные тесты контролируют взаимодействие между слоями, а XCUITest проходит критичные пользовательские маршруты. Проблема начинается не с отсутствия автоматизации, а с её масштабирования.
Я работаю автоматизатором на Python в одном российском банке, устроился относительно недавно и уже начал писать знакомым, мол качественно зарефералю. Времена нынче странные, так что возможность рефералки — в моём представлении благо. Ну и денежный бонус вкусный, что уж скрывать.
И вот мне написал мой хороший знакомый — Коля Черкасов. Мол на него уже и так вышли рекрутеры моего работодателя да даже на ту же должность, на которую взяли меня, а посему не мог бы я поделиться с ним секретами о том, как проходят собесы в данную компанию на данного специалиста.
От чего не мог бы? С радостью.
Пару месяцев назад я попросил агента проверить форму обратной связи после рефакторинга. Через несколько минут получил отчёт: все проверки пройдены, форма работает корректно. Зелёные галочки, уверенный тон.
Я тогда только начинал отдавать тестирование агенту, поэтому работал по схеме «доверяй, но проверяй»: следом прошёл форму руками, с открытой вкладкой Network. Снаружи всё честно: валидация зелёная, кнопка активная, тост «Спасибо!» показывается, сервер отвечает 200. А в payload вместо темы обращения уходит строка [object Object]. Агент проверил всё, кроме того, что реально уходит на сервер.
«Нам нужно сделать регрессионное, функциональное и интеграционное тестирование» — а ты автоматизатор и уже задумываешься о том, что попал куда‑то не туда. Или же ты новичок, решивший пойти в тестировщики, смотришь вакансии и видишь, что этих видов тестирования чуть ли не сотня. Как же понять, что от тебя требуют и куда идти? Попробуем разобраться.
Важно сразу сказать, что виды тестирования разделяют по категориям — всё равно что разработчиков делят не только по яп, но и по тому, где этот яп применяется. Ведь java backend разработчик и java mobile разработчик это совершенно разные вещи!
Вступление
Привет! Меня зовут Илья, я работаю Manual QA в команде, которая отвечает за качество продукта с большим количеством микросервисов, API и регулярными релизами. Если вы хоть раз писали тест-кейсы по тикету из Jira, потом руками собирали Postman-коллекцию по OpenAPI-спецификации, а после ревью документации обнаруживали, что половину сценариев забыли — эта статья для вас.
Хочется поговорить о том, что происходит с QA в 2026-м и правда ли, что «нас вот-вот заменит ИИ». Но не в формате очередного треда в духе «всё пропало» или «всё отлично, завтра уволим половину отдела». А по-взрослому: с опытом, цифрами, ограничениями и выводами. То есть попробовать не просто порассуждать, а разобрать тему как небольшое исследование: что реально меняется, где ИИ помогает, а где начинается та самая реальность, которая не влезает в красивую презентацию.
![Создаем свой проектный фреймворк автотестирования API [Часть 1-3] - 1](https://www.pvsm.ru/images/2026/01/03/sozdaem-svoi-proektnyi-freimvork-avtotestirovaniya-API-chast-1-3.png "Создаем свой проектный фреймворк автотестирования API [Часть 1-3] - 1")
Head of QA
Большинство проектов на определенном этапе своего развития сталкивается с тем, что бизнесу требуется внедрить такую диковинную вещицу, которую реализовывать самим: не получится / нельзя / дорого.
Тут выходят на сцену вендоры и внешние системы, которые готовы спасти ситуацию и предоставить свой функционал на растерзание ласковые поглаживания трафиком нашей компании.
Вроде понятно, как так вообще вышло, что есть какие-то там зависимости, хотя мы все сильные и независимые! Но как же дело обстоит с тестовым покрытием? Тут в общем понимании варианта два:
Проблема нестабильных E2E-тестов не нова. Про флаки, ретраи и «зеленые прогоны» написаны десятки статей, и в каждой есть правильные мысли. Но, как это часто бывает, читать — одно, а заставить это работать в реальном проекте — совсем другое.
Я тоже не искал лёгких путей и пришёл к своим решениям через боль, страдания и разбор бесконечных падений (не повторяйте этот путь, если есть возможность). В этой статье я расскажу, какие подходы помогли нам в команде приблизиться к стабильным E2E-прогонам, которым действительно можно доверять.
