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

Не так давно я описывал свои подходы (офигеть полгода прошло) по формированию тестовой модели на проекте, а так же организацию коллекций в 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, а документацию аналитик должен делать.

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

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

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

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

🔥  Кейсы на API не пишем

🤔  Пишем и кейсы, и коллекции ведем (двойная работа, а что делать...)

⚡️ Только код, только хардкор (автотесты, контракт-тестинг)

🌚 Кейсов нет, коллекций нет, тестируем по памяти

🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman