Добавить в корзинуПозвонить
Найти в Дзене

Не так давно я описывал свои подходы (офигеть полгода прошло) по формированию тестовой модели на проекте, а так же организацию коллекций в

Postman и тут. Собственно последний год я не мало материала изучал по ведению тестовой документации, что бы уловить современные тенденции. Зачем я это делал? Что бы быть в теме. Что бы на проекте применять только современные практики, если, конечно, они полезны проекту. Сегодня я бы хотел поговорить про API. А конкретно про API тест-кейсы. Один из регулярных вопросов за многие годы от коллег и учеников: "Как правильно писать тест-кейсы для ручного тестирования API?" Я и сам на протяжении многих лет задавался этим вопросом. Но сейчас я хотел поговорить не об этом. В наше время пожалуй правильно будет задавать вопрос: А надо ли писать тест-кейсы на API? Если погулять по зарубежным пабликам посвященным QA (и не только), можно периодически наталкиваться на доклады и статьи о том, что писать ручные тест-кейсы на API это расточительство времени и двойная работа. И вообще это антипаттерн в современной команде разработки. В наше время есть инструменты, которые позволяют легко покрывать 80% A

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

Зачем я это делал?

Что бы быть в теме. Что бы на проекте применять только современные практики, если, конечно, они полезны проекту.

Сегодня я бы хотел поговорить про API. А конкретно про API тест-кейсы.

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

"Как правильно писать тест-кейсы для ручного тестирования API?"

Я и сам на протяжении многих лет задавался этим вопросом. Но сейчас я хотел поговорить не об этом.

В наше время пожалуй правильно будет задавать вопрос:

А надо ли писать тест-кейсы на API?

Если погулять по зарубежным пабликам посвященным QA (и не только), можно периодически наталкиваться на доклады и статьи о том, что писать ручные тест-кейсы на API это расточительство времени и двойная работа. И вообще это антипаттерн в современной команде разработки.

В наше время есть инструменты, которые позволяют легко покрывать 80% API автоматическими проверками. А так же подходы: shift-left testing и контрактное тестирование (про это как-нибудь в будущих постах).

🧐Почему коллекция в Postman может заменить тест-кейсы?

Если вы используете Postman на "максималках", то он от части берет на себя функции TMS (система управления тестированием):

Названия запросов = Заголовки тест-кейсов. Вместо GET /users/1 можете написать [Positive] Получит информацию о пользователе.

Вкладка Scripts (Post-response) = Ожидаемые результаты. Скрипты на JS проверяют статус-коды, структуру JSON и бизнес-логику - то что мы ожидаем.

Описание (Docs) = Шаги теста. В Postman у каждого запроса есть поле Docs, куда можно вписать описание параметров и логику теста. Или другую полезную информацию.

Folders = Наборы тестов (Test Suites). Группировка по фичам или модулям.

Вывод: Если ваша коллекция структурирована так, что сторонний человек может ее запустить и понять, что проверяется - дублировать это в Jira/TestRail текстом действительно бессмысленно. Это лишняя работа по поддержке актуальности.

Поэтому я всегда говорил и буду говорить: если вы используете Postman, потратьте вы на 2 минуты больше времени на один запрос. Напишите тесты в Scripts к нему, простенькую документацию в Docs. Не знаете JS? Или даже знаете? Сгенерируйте тесты, сгенерируйте документацию с помощью AI.

Не слушайте тех кто говорит что это кринж. Что, если писать автоматизацию, то надо обязательно сразу на Python+pytest, а документацию аналитик должен делать.

Когда ручные тест-кейсы (или чек-листы) всё-таки нужны?

Есть зоны, где "просто запроса в Postman" недостаточно:

Сложные бизнес-сценарии (E2E): Если для проверки фичи нужно: "Создать юзера в БД через API → Проверить письмо на почте → Зайти под ним в UI → Выполнить действие в API", - такой сценарий в Postman автоматизировать сложно, его лучше описать текстом.

Интеграции со сторонними системами: Когда API - это лишь часть процесса, и результат нужно проверять где-то "снаружи" (в логах, другой системе, на физическом устройстве).

Передача знаний (Knowledge Transfer): Аналитики или менеджеры редко заходят в Postman. Им нужен высокоуровневый список того, "что вообще мы проверили", чтобы оценить покрытие рисков.

Исследовательское тестирование: Когда вы еще не знаете, как поведет себя система. Тут пишутся краткие чек-листы идей.

Почему же все продолжают упорно писать ручные API тест-кейсы?

Тут эффект старой школы. У меня он тоже пожалуй есть. Раньше это была стандартная практика и многие нынешние руководители это воспитанники "старой" школы. Им куда понятней 500 тест-кейсов в TMS, которые можно открыть посмотреть почитать. А что такое коллекция в Postman? А хрен её разберешь.

С трудом, но всё таки новые тенденции пробираются в команды.

А у вас как с этим дела на проекте? Вы пишите ручные тест-кейсы на API?