QA-инженер превратил Claude в настоящего охотника за багами с помощью набора правил
Разработчик создал пакет навыков для ИИ-агента Claude, который заставляет его не просто формально проходить проверки, а активно искать реальные ошибки, как в случае с отправкой некорректного `[object Object]` вместо данных формы.
Опыт QA-инженера показал, что ИИ-агенты при стандартном подходе часто пропускают критические ошибки, ограничиваясь поверхностными проверками. Классический пример: после рефакторинга формы агент доложил об успешных проверках, но ручной анализ выявил, что в данных, отправляемых на сервер, вместо темы обращения уходила некорректная строка. Агент проверил все, кроме реальных данных на бэкенд. Этот случай стал переломным.
По данным Habr, инженер целенаправленно перекладывает рутинную работу на ИИ. Его методология напоминает обучение стажера: каждый пропущенный баг превращается в новое правило или навык через систему скиллов и замечаний. Из этого опыта вырос целый пакет навыков, выложенный в открытый доступ. Суть подхода — запретить агенту говорить «все работает» без конкретных доказательств и заставить его мыслить как тестировщик, который скептически проверяет каждое утверждение системы. Это включает обязательную проверку сетевых запросов, валидацию данных на всех этапах, анализ ответов сервера и поиск неочевидных сценариев поломки.
Для автоматизации тестирования этот кейс демонстрирует эволюционный шаг: переход от использования ИИ как простого исполнителя скриптов к созданию агентов, способных к критическому анализу. Стандартные подходы часто страдают от «слепых зон» — они проверяют запрограммированное, но не ищут неизвестные проблемы. Методика постоянного дообучения через анализ ошибок позволяет создавать более надежных помощников. Это актуально в контексте непрерывной интеграции и доставки, где скорость и качество тестирования напрямую влияют на цикл разработки.
Практическая ценность для разработчиков — в экономии времени и повышении надежности продукта. Высвобождая инженера от рутинных проверок, агент позволяет сосредоточиться на сложных задачах: проектировании тестовой стратегии или исследовательском тестировании. Однако автор отмечает ограничения метода: он не работает в ситуациях, требующих глубокого понимания бизнес-логики, сложной визуальной проверки или тестирования в изолированных средах без доступа к инструментам разработчика. Тем не менее, правильно настроенный агент становится мощным инструментом, сокращая время на регрессионное тестирование и повышая вероятность обнаружения багов до релиза. Метод требует постоянной настройки и обучения, но окупается повышением качества и снижением рисков.
