Кольцо Автотестов и документация, которая всегда актуальна

Кольцо автотестов необходимо для контроля над кодовой базой. Автодокументация — возможность его переиспользовать, исключительно эффективная и эффектная. Станет ли эта возможность реальностью с помощью ИИ?

2008: контрольные примеры

В 2008-м захотелось распространить наш биллинг «Ватерман» на группу водоканалов и, возможно, выйти в другие регионы. И сразу встал вопрос про контрольные примеры. Контрольный пример — это другое название для автотеста, только сказанное на языке отрасли, а не на языке разработки: кросс-функциональная проверка, которая повторяет сценарий работы ключевого специалиста от действия до результата, видимого бизнесу. Копий экрана для простейшей пользовательской документации может и хватить. Но только контрольный пример связывает всё в единую логику и проверяет корректность расчётов. Мы написали такие примеры для юридических лиц и для физических. И это вылилось в документацию на сайте.

Вокруг Кодовой Базы получилось защитное кольцо — отсюда и название, с намеренной отсылкой к Толкину. Одно кольцо, чтобы править всеми.

В том же 2008-м я открыл для себя Мартина Фаулера — для меня Test Driven Development начался с него. В некоторых выступлениях он говорил прямо: если есть кросс-функциональные тесты, отражающие пользовательские сценарии, начинайте с них — так быстрее всего поймёте суть происходящего.

Там, где выбора не было

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

Возьмите приёмку быстрого открытия расчётного счёта: перебор параметров и сценариев там факториальный. Ручным тестированием это закрывается либо стрессово, через перегрузки, либо не закрывается вовсе. И ЖКХ, и банки — высокорегулируемые отрасли, у банков зарегулированность выше.

Что из этого выросло

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

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

Сколько это стоит

Тридцать процентов платятся один раз, на написании. Напротив них — кривая Боэма, известная с 1981 года: стоимость изменений растёт экспоненциально по мере движения от разработки к эксплуатации. ИИ обрушил стоимость написания почти до нуля, стоимость сопровождения — нет. Подробнее — в разборе бенчмарка SWE-CI.

А вот сожмёт ли ИИ сами эти тридцать процентов — вопрос открытый и самый интересный. Стоимость входа он уже уронил. Станет ли дешевле сама обвязка, увидим на ближайших работах.

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

Никто не перепрыгивает с первого раза

Первая волна — TDD конца девяностых и двухтысячных: идея сформулирована, книги написаны, массово не перепрыгнуло. Вторая — сейчас, вместе с ИИ.

Барьера было два. Экономический — дорого и долго; его ИИ снял. Организационный — у пользовательского сценария должен быть автор, который понимает и бизнес, и систему. В фрагментированной структуре такого автора нет: аналитик знает сценарий, разработчик знает код, тестировщик знает инструмент, целого не видит никто. Этот барьер ИИ не снимает.

Что изменил ИИ

Берём типовое отраслевое ТЗ — доставшееся исторически или собранное с помощью ИИ, — оставляем суть и по ней составляем приёмочные автотесты. Дальше разделение труда: один агент пишет тесты, второй пишет программу, которая должна им соответствовать. Между ними идёт back-and-forth: выясняется, что какие-то нюансы не учтены, агенты задают друг другу вопросы и правят обе стороны. Так собрана следующая версия «Ватермана» — Billing321.

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

И ещё одно, про язык. Пользователи говорят не так, как ИТ, и документацию поддержка должна писать их словами. Здесь достаточно один раз записать видео, где ключевой специалист описывает процесс своими словами: дальше модель подхватывает его словарный запас и отраслевой сленг — тот самый ubiquitous language, на котором говорит BizOps.

Рельсы для ИИ-поезда

Раньше документацию читал человек. Теперь по ней работает ещё и агент, и ему нужно ровно то же самое — описание того, что в этой предметной области означает слово «правильно», в исполняемом виде. Одна и та же спецификация обслуживает и сотрудника, и машину.

Если по-матричному: поручим машинам машинную работу. Машинное здесь — перевести сценарий в код, прогнать, собрать отчёт, держать документацию свежей. Человеческое — знать, что значит «правильно». Второе не перекладывается: у сценария должен быть автор, и это ключевой специалист.

Кольцо в такой картине — это не ограждения по краям дороги (в английском их зовут guardrails), а рельсы: они не столько не дают съехать, сколько задают путь. Может оказаться, что автодокументация и есть те рельсы, по которым поедет ИИ-поезд. Проверим.

Чего это требует

• Кольцо нужно поддерживать: меняется интерфейс — тесты актуализируются.
• Нужен стенд с данными, реальными по структуре.
• Нужна команда полного цикла: отдельная группа тестирования Кольцо не построит, она не знает бизнеса.

Сентябрь 2026. Текст собран из трёх голосовых записей и доведён вместе с ИИ-соавтором.