Как документация стала источником автотестов для Claude
В Документерре документация долгое время оставалась финальным этапом разработки: сначала выпускали функцию, затем описывали её для пользователей. Внутри команды эти материалы почти не использовали — разработчики считали, что и так знают продукт, а тестировщики обращались к документации лишь при наличии свободного времени.
В 2025 году подход изменился. Команда подключила опубликованную документацию к Claude через MCP-сервер и стала использовать её как исходный материал для проектирования тестирования. Теперь модель читает описание продукта, формирует тест-кейсы и пишет автотесты, а документация переместилась из конца рабочего процесса в его начало.
Что удалось автоматизировать
По словам технического директора компании, примерно за час настройки промптов и несколько часов работы Claude команда получает рабочие автотесты для новой функции. Тестировщикам не приходится вручную подбирать селекторы, придумывать последовательность действий и сначала подробно изучать интерфейс.
Модель также может готовить тесты для ещё не завершённой функции, если её предусловия уже реализованы. Ей передают описание задачи, pull request, заметки разработчика и имеющиеся тест-кейсы, после чего Claude самостоятельно обращается к документации и составляет тест-план. Такой подход позволяет тестировать функцию, с которой специалист раньше не работал.
Отдельный сценарий — поиск устаревших тестов. Модель сопоставляет ручные и автоматизированные проверки с текущей документацией, находит противоречия и помогает обновить набор тестов. Во время выполнения она может заметить и дефекты: по ошибкам интерфейса, несоответствиям в сценариях или анализу логов тестовых прогонов.
Пример с восстановлением пароля
Для демонстрации команда использовала простой пользовательский сценарий. В документации указано, что пользователь должен открыть страницу входа, выбрать пункт «Забыли пароль?», ввести логин или электронную почту и запросить письмо со ссылкой для установки нового пароля.
На основе этого описания Claude сформировал два тест-кейса. Первый проверяет, что ссылка ведёт на страницу восстановления, где отображаются поле логина и кнопка отправки запроса. Второй — негативный: если нажать кнопку с пустым полем, появляется ошибка валидации, а страница не меняется. Последнего условия в исходной документации не было — модель вывела его из логики формы.
Затем агент сгенерировал автотесты на Playwright с объектом страницы, проверками адреса, видимости элементов и состояния поля. В результате тестировщик получает не только список проверок, но и готовую основу для автоматизации, которую остаётся проверить и при необходимости адаптировать к проекту.
Почему команда использует MCP
Подключение через MCP оказалось удобнее полной выгрузки документации. В больших закрытых базах невозможно заранее определить, какие страницы понадобятся для конкретного теста: сценарий может затрагивать несколько связанных функций. Через MCP модель сама ищет нужные материалы и получает только релевантный контекст.
Есть и вопрос доступа. Функции часто тестируют до публичного релиза, поэтому документация к ним хранится в закрытых публикациях. MCP-сервер может отдавать такие страницы только сотрудникам с соответствующими правами. Кроме того, команда видит, к каким материалам обращалась модель, и может убедиться, что она использовала актуальную внутреннюю документацию, а не случайный внешний текст или устаревшие сведения.
Человеческие проверки остаются обязательными
В рабочем процессе предусмотрены два ручных этапа контроля. Сначала проверяют саму документацию. Если она описывает поведение, которого уже нет в продукте, все последующие результаты будут ошибочными: тест-кейсы закрепят неверную логику, а автотесты будут стабильно проходить, проверяя несуществующий сценарий.
Второй этап — ревью тест-кейсов. Он нужен, чтобы заметить пробелы в покрытии и учесть реальные пользовательские сценарии. Модель хорошо работает с предоставленным текстом, но не всегда понимает, какие действия клиенты совершают в продукте на практике.
При этом автор кейса отмечает, что анализ рассуждений Claude иногда полезнее, чем немедленное изучение сгенерированного кода. По цепочке действий видно, какие материалы использовала модель и как она поняла функцию. Ошибочную интерпретацию можно обнаружить до того, как она превратится в длинный автотест.
Какая документация лучше подходит для генерации тестов
Для автоматизации особенно полезны точные ограничения и числовые границы. Формулировка «система обрабатывает файл» почти не помогает построить проверку, а правило «файлы больше 50 МБ отклоняются с ошибкой 413» сразу превращается в конкретный тест.
Лучше описывать пользовательские сценарии, а не только расположение кнопок. Инструкции, привязанные к конкретному интерфейсу, быстро устаревают после редизайна. Описание цели — например, создания проекта или публикации документа — переживает изменения интерфейса, поскольку модель может заново вывести последовательность действий.
Важную роль играют и release notes. Они показывают, что изменилось в продукте, и помогают определить, какие тесты нужно перегенерировать или пересмотреть. Поэтому команде не потребовалось писать больше документации, но пришлось делать существующие материалы точнее.
Ограничения подхода
Практика с MCP пока остаётся ранним экспериментом. В документации Документерры есть скриншоты, на которых содержится информация, не продублированная в тексте. Сервер возвращает Markdown со ссылками на изображения, но команда ещё не проверила, насколько эффективно Claude использует содержимое этих картинок. Если важные сведения находятся только на скриншотах, рассчитывать на них в таком конвейере пока не стоит.
Есть и системный риск: документация порождает тест-кейсы, а тест-кейсы закрепляют описанное поведение. Если ни один этап не сверяется с реальным продуктом, документация и тесты могут синхронно уйти в неверную сторону. Именно поэтому ручные ревью в Документерре не считают этапом, от которого можно отказаться ради скорости.
Главный вывод команды заключается в том, что документация перестала быть отчётом о уже сделанной работе. Она стала инструментом для следующей задачи — проектирования тестов, автоматизации и поиска дефектов. Когда от её качества зависят несколько инженерных процессов, поддержка документации превращается не только в вопрос редакторской дисциплины, но и в заметную статью расходов компании.
