Comments 8
Тестирование API согласно предложенной стратегии - очень затратное дело. Понятно, что не для всех проектов она подходит. Но когда вчерашние менеджеры по продажам становятся сегодняшними программистами у IT-индустрии нет другого выхода, как садить одних вчерашних менеджеров проверять код других вчерашних менеджеров. Сегодня IT - это искусство управления работой "шестерёнок", создающих ПО. Возникает некий парадокс - несмотря на то, что программистов становится всё больше, создавать программы становится всё дороже и программистов всё равно не хватает. Особенно на проекты с небольшим бюджетом.
Я слышал, что есть истории отказа от QA в команде, и увеличение нагрузки на разработчиков по написанию модульных тестов на свой код. Если "бывший менеджер" хочет быть в рынке, то пусть пишет чище и сам себя же проверяет.
Касаемо стратегии из статьи, кажется что описано максимально возможные элементы процесса тестирования. Сомневаюсь, что заказчик будет писать настолько подробные требования. На усмотрение QA можно выделить наиболее критичные и нужные, в зависимости от уровня доступности API - открытое тестировать более тщательно, закрытое - на усмотрение внутреннего заказчика.
Спасибо за перевод! Полезная информация.
Спасибо за перевод! Было полезно
Спасибо за статью! А вы не рассматривали возможность отказаться от тестирования API в пользу юнит/интеграционных тестов? Тестировать те же сценарии, но на более низком уровне, без необходимости поднимать все приложение - а значит быстрее и стабильнее. Непротестированной останется только код, ответственный за получение/отправку REST запросов, но его можно покрыть отдельно.
Так вот я же выше написал по этому поводу. Отказ от ручных тестов в пользу юнит.
Если смотреть с точки зрения управления ресурсами, час тестировщика стоит меньше, чем час разработчика. И чем больше тестировщик залазит в код(в чужой или в свой), тем дороже он стоит.
Я извиняюсь, не очень корректно передал контекст: я сравнивал автоматизированное тестирование API (через всякие rest-assured, karate и прочее) с автоматизированными интеграционными тестами. И, в моем понимании, последние должны быть эффективнее.
Думаю, что минус будет в том, что последние будут труднее поддерживать в актуальном состоянии. Если при тестировании API мы смотрим ответ и интерфесную часть(имена эндпоинтов и параметры), то автоматизированные интеграционные тесты будут зависеть от реализации классов. А они могут изменяться чаще.
Но я могу ошибаться.
Стратегия тестирования REST API: что именно вам нужно тестировать?