Команда Документерры поручила Claude писать автотесты за пять часов

После выпуска функции приходится заново описывать её поведение для тестировщика, а затем переносить сценарии в автотесты. В Документерре попробовали использовать для этого документацию продукта: Claude читает её, составляет тест-кейсы и пишет проверки. На примере восстановления пароля видно, что именно получается на выходе и где человеку приходится проверять предположения модели.

По словам технического директора компании, на подготовку запросов для одной функции уходит час, затем Claude работает ещё пять часов. Это оценка из рассказа команды. В материале нет сравнения с ручной разработкой тестов, стоимости запусков или статистики ошибок, поэтому посчитать выигрыш пока нельзя.

От инструкции до двух тестов

В примере агент получает инструкцию по восстановлению пароля: открыть страницу входа, перейти по ссылке восстановления, ввести логин или почту и запросить письмо. Документацию он читает через MCP — подключение, которое позволяет обращаться к инструментам поиска и чтения страниц.

Из инструкции Claude составляет два сценария. Первый проверяет, что ссылка со страницы входа открывает форму восстановления. Второй — что пустой логин вызывает ошибку валидации и пользователь остаётся на той же странице. Затем появляются автотесты с проверками адреса страницы, видимости полей и сообщения об ошибке.

У второго сценария есть существенная деталь: исходная инструкция ничего не говорит о пустом поле. Модель сама предложила ожидаемое поведение. Для тестировщика это полезная заготовка, но её нужно сверить с требованиями продукта. Правдоподобное предположение ещё не становится правилом только потому, что агент оформил его в тест.

Показанный код также опирается на существующие фикстуры и объект страницы ForgotPasswordPage. Поэтому пример не демонстрирует создание всей тестовой инфраструктуры с нуля. Кроме того, эти две проверки не охватывают полный путь восстановления пароля: получение письма, переход по ссылке и установку нового пароля.

Два ревью остаются за людьми

Команда описывает два обязательных ручных этапа. Сначала человек проверяет документацию, затем — составленные моделью тест-кейсы. После этого контролирует создание автотестов.

Первое ревью защищает от устаревших требований. Если инструкция описывает поведение, которое продукт уже изменил, агент может аккуратно воспроизвести ошибку в сценариях. Зелёный прогон в таком случае покажет соответствие неверному ожиданию.

Второе ревью нужно для проверки покрытия. Специалист, знакомый с пользователями, может заметить пропущенные условия, роли или исключения. В примере восстановления пароля отдельно стоит спросить, какие сценарии нужны для истёкшей ссылки и повторного запроса письма. Это возможные дополнения к плану проверки; материал не показывает, что команда их реализовала.

Сам автор предупреждает: MCP-сервер используют недавно, результаты ранние. Работа со сведениями на скриншотах тоже не проверена. Сервер возвращает Markdown со ссылками на изображения, но команда пока не выяснила, извлекает ли агент из них нужную информацию.

Что можно перенести в свою команду

Практический смысл кейса — в устройстве процесса. Агент получает описание функции, задачу, PR и существующие тест-кейсы, сам ищет документацию, затем предлагает тест-план. Так у тестировщика появляется материал для предметного ревью.

Для такого процесса особенно полезны точные ограничения. Фраза о поддержке загрузки файлов почти не задаёт ожидаемых результатов. Указание предельного размера и конкретной ошибки уже позволяет составить проверки границы. Если правило допускает несколько трактовок, сначала нужно согласовать поведение, затем закреплять его тестом.

MCP в этом кейсе даёт доступ к текущим страницам, включая закрытые материалы при наличии прав. Из рассказа, однако, не следует, что без него подход невозможен: для небольшого эксперимента можно передать агенту выбранный фрагмент документации. Само подключение также не гарантирует, что текст актуален и верен.

Начать можно с одной функции: проверить её описание, получить сценарии, согласовать ожидаемые результаты и только затем запускать генерацию кода. Чтобы оценить пользу, стоит измерить время подготовки и ревью, число исправлений и устойчивость тестов при следующих изменениях. Кейс Документерры даёт воспроизводимую схему такого эксперимента, но пока не доказывает экономию для любой команды.