Как использовать AI-ассистентов для более быстрого написания скриптов автоматизации и как проверять их результат.
AI-ассистенты для написания кода — инструменты, которые предлагают или генерируют код прямо в редакторе, — стали обычной частью написания скриптов автоматизации тестирования, а не только прикладного кода. Для QA-инженера, переходящего в автоматизацию, они могут заметно сократить время написания скрипта на Selenium, Playwright или Cypress — при условии, что результат проверяется с той же строгостью, что и код от младшего коллеги.
В этой статье рассматриваются:
AI-ассистенты для кода предлагают код по мере набора, генерируют целую функцию или скрипт по описанию на обычном языке и могут объяснить или отрефакторить существующий код по запросу. Для автоматизации тестирования это обычно означает генерацию черновика page object, скрипта теста для описанного пользовательского сценария или набора проверок (assertions) для заданного сценария — работу, которая следует хорошо известным паттернам, множество примеров которых модель видела при обучении.
Самый надёжный способ использовать ассистента для автоматизации — точно описать тестовый сценарий: конкретные шаги, конкретные элементы и конкретный ожидаемый результат, а не просить что-то расплывчатое вроде «напиши тест для страницы входа». Чем больше промпт похож на хорошо написанный ручной тест-кейс, тем ближе сгенерированный скрипт будет к пригодному для использования. Также полезно заранее указать фреймворк, язык и любые соглашения проекта (именование, структуру папок, существующие вспомогательные функции), поскольку иначе ассистент не может их знать.
Сгенерированные AI скрипты автоматизации должны проходить ту же проверку, что и написанный человеком скрипт: корректные локаторы, которые не сломаются при следующем небольшом изменении интерфейса, подходящие ожидания вместо фиксированных задержек (sleep), проверки, действительно проверяющие нужное, и отсутствие захардкоженных тестовых данных, которые незаметно устареют. Сгенерированный скрипт, который один раз запустился и прошёл, — не то же самое, что стабильный и поддерживаемый скрипт; эта разница обычно проявляется только после проверки человеком, а не от самого ассистента.
AI-ассистенты для кода заметно слабее во всём, что специфично для конкретного тестируемого приложения и не было видно в промпте или окружающем коде: собственные внутренние фреймворки, необычные потоки аутентификации или особенности приложения, примеров которых модель никогда не видела. Они также склонны генерировать код, который выглядит правдоподобно и запускается без ошибок, но незаметно проверяет не то — например, проверяет наличие элемента, а не то, что он содержит правильное значение, — что делает внимательную проверку обязательной, а не опциональной.
Относитесь к ассистенту как к быстрому «печатнику» с навыками распознавания паттернов, а не как к инженеру автоматизации, понимающему ваш продукт. Давайте точные, детальные промпты, проверяйте всё, что он производит, прежде чем коммитить, и используйте его наиболее активно для повторяющихся частей работы по автоматизации — шаблонного кода, page objects, стандартных паттернов проверок, — где экономия времени наибольшая, а риск незаметной ошибки легче всего поймать.
Prompt engineering для задач QA
Автоматизированное тестирование