Почему ИИ в автотестах не работал и что изменилось (1/2)
Сразу оговорюсь: я был одним из ярых скептиков использования ИИ в автоматизации тестирования. У технологии был целый ряд проблем, которые она не могла решить — и отчасти не может по сей день. Но ИИ-агенты прогрессируют быстрее, чем вам кажется.
Это первый пост из двух: почему ИИ в автотестах не работал ещё вчера, что сломало мой скепсис — и во что всё упёрлось, когда технические препятствия исчезли.
Год-два назад применение ИИ в автоматизации блокировали не капризы моделей, а конкретные технические препятствия:
— Доступ к моделям. Внешние API упирались в политику безопасности — код и тестовые данные нельзя отдавать за периметр. А собственный деплой требовал серьёзного «железа»: GPU-серверы, настройка, поддержка.
— Модели были «текст на входе — текст на выходе». Они только-только учились вызывать инструменты: открыть файл проекта, выполнить код, заглянуть в систему управления тестированием — скорее эксперимент, чем рабочий механизм. Эффективный контекст был маленьким, модель не видела проект целиком, фрагменты приходилось скармливать вручную.
— Стиль написания кода. Модель не сохраняла принятые в проекте архитектуру, паттерны и соглашения — каждый ответ приходилось «причёсывать» руками.
— Узкие места: локаторы, интеграции — всё то, что требует глубинного понимания конкретного продукта.
— Бизнес-логика, которую невозможно полноценно передать в документации.
Пять пунктов, и почти в каждом — тупик. Но препятствия рухнули разом — и, что интересно, не из-за самих моделей.
Переломным для меня стало осознание: главное изменение произошло не в моделях, а в инфраструктуре вокруг них. Харнес (harness, дословно «упряжь») — слой программной инфраструктуры, который превращает «голую» модель, просто генерирующую текст, в действующего агента. Он даёт модели:
— «руки» — инструменты для работы с файлами, запуска команд, управления браузером; — «глаза» — управление контекстом: что именно из проекта показать модели в данный момент; — «рамки» — права и ограничения на действия.
Именно харнес связал проекты разработки и автоматизации, инструменты тестовой документации, Git и CI в единое целое, а протоколы уровня MCP сделали подключение новых источников почти plug-and-play. Сегодня это целые продукты — Cursor, Claude Code и другие.
Отсюда и магия, которая когда-то казалась мне фантастикой: говоришь агенту «напиши автотест по кейсу номер такому-то» — и он сам находит кейс, изучает фреймворк, смотрит примеры готовых тестов и пишет новый по образцу. Простой happy path — за минуты, а не за часы.
Честная оговорка: не закрыт только пункт про бизнес-логику — документация по-прежнему не передаёт её всю. Но агент может вывести её из кода и истории изменений, и это работает заметно лучше. Правда, за корректность такого «вывода» отвечает человек — запомните этот момент, он ещё пригодится.
Технические барьеры упали. И ровно в этот момент началось самое интересное — об этом в финальном посте.
· 19.10
У вывода бизнес-логики из кода есть риск: агент закрепит текущий баг как ожидаемое поведение. Было бы полезно, чтобы вместе с тестом он показывал, откуда взял ожидание — из требования, существующего теста или только из реализации; тогда спорные места видны до ревью кода.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён