Почему вопрос уже не в том, можно ли применять ИИ в тестировании 1С
Генеративные модели уже пишут тесты, разбирают легаси-код и закрывают часть рутины в QA. Сложность в другом: без правил и контроля та же модель так же уверенно создаёт бесполезные проверки. Тест есть, он запускается, проходит, а что именно он доказывает, остаётся открытым вопросом.
В разработке генеративные модели давно используют для написания и анализа кода, и похожие сценарии перешли в тестирование. ИИ помогает готовить юнит-тесты, разбирать сложные унаследованные системы и автоматизировать повторяющиеся операции. Наличие модели полезный результат не гарантирует: ей нужно задать контекст, правила и ограничения. Без этого вместо осмысленного набора проверок выходит формально корректная, но бесполезная конструкция.
Главный вопрос сегодня звучит не как «можно ли применять ИИ в тестировании», а как встроить его в процесс, чтобы качество действительно росло. На секции QA конференции INFOSTART TECH EVENT 2026 этой теме посвящены два доклада: «AI-assisted testing для легаси-систем: стратегии, промпты, ограничения и практические подходы» и «Как заставить ИИ писать полезные unit-тесты для 1С, а не уверенную ерунду». Оба названия точно описывают рамку разговора: инструмент есть, а методология к нему ещё нарабатывается.
Где ИИ реально помогает в QA 1С, а где создаёт «уверенную ерунду»
Сценарии делятся на две группы. Первая: черновики юнит-тестов, разбор унаследованного кода, автоматизация повторяющихся операций, подготовка сценариев для дымового тестирования. Вторая: оценка бизнес-логики, критичности отдельных сценариев и реальных рисков системы. Здесь модель работает по формальным признакам и легко уходит в сторону от важного.
| Задача | Что даёт ИИ | Что остаётся человеку |
|---|---|---|
| Черновик юнит-теста | Быстро готовит основу проверки | Проверить, что тест отражает бизнес-правило, а не формальность |
| Разбор легаси-кода | Анализирует код и показывает зависимости | Определить, какие модули критичны для работы бизнеса |
| Рутинные операции | Помогает с подготовкой сценариев и анализом результатов | Решить, что включать в постоянный набор проверок |
| Оценка рисков | Готового ответа не даёт | Расставить приоритеты проверок по критичности |
Цена ошибки выглядит так: тест проверяет, что функция вернула число, и молчит о том, соответствует ли это число бизнес-правилу. Прогон зелёный, отчёт аккуратный, риск на месте. Поэтому специалист проверяет два слоя: сам сгенерированный код и то, что этот тест проверяет.
Юнит-тесты: почему модель быстро пишет основу, но не понимает бизнес-логику
Модель способна быстро подготовить основу теста, но не всегда понимает бизнес-логику, критичность отдельных сценариев и реальные риски системы. Проблема особенно заметна при генерации юнит-тестов: их много, писать вручную долго, а сгенерированные выглядят убедительно и создают ощущение покрытия.
Типичный провал: тест вызывает функцию, убеждается, что она не упала и вернула значение, и не проверяет корректность расчёта. Такая проверка проходит на любом результате, включая заведомо неверный.
Что помогает: до генерации передать модели описание бизнес-правил, список критичных сценариев и ограничений системы. Тогда проверка опирается на правила предметной области, а не на общие представления о том, как «обычно» пишут тесты.
Легаси-код: как ИИ помогает разбирать унаследованные системы
На унаследованных системах польза выше: модель разбирает код, выявляет зависимости между модулями и предлагает сценарии проверок. Для крупных конфигураций 1С, где документация устарела или отсутствует, это экономит часы чтения кода.
Ограничение то же: без контекста модель не знает, какие части системы критичны. Она может предложить тест для функции, которая давно не используется, и пройти мимо модуля, от которого зависит закрытие месяца. Разбор подходов к таким системам прозвучал в докладе про AI-assisted testing для легаси-систем на секции QA.
Порядок работы, который снижает риск: сначала команда проводит инвентаризацию легаси-кода и определяет критичные участки, затем передаёт модели эту карту вместе с кодом. Модель идёт по вашим приоритетам, а не по своим догадкам.
Как задавать контекст, правила и ограничения, чтобы ИИ писал полезные тесты
Полезный тест начинается не с промпта, а с подготовки данных. Модели нужно передать то, чего у неё нет: знание бизнес-логики, критичности сценариев и ограничений системы. Иначе вместо осмысленного набора проверок получается формально корректная конструкция, которая ничего не доказывает.
Какие данные и правила передавать модели перед генерацией тестов
- описание бизнес-процесса и его цели;
- критичные сценарии, ошибки в которых обходятся дороже всего;
- ограничения системы: типы данных, допустимые диапазоны, роли, права;
- примеры корректных и некорректных входных данных;
- ожидаемый результат для каждого сценария;
- граничные условия и исключения.
Пример для расчёта зарплаты: модели передают формулу, правило коэффициента за стаж, список исключений и граничные значения. Без формулы тест проверит, что функция вернула число, и остановится на этом.
Шаблоны промптов под типовые задачи экономят время: контекст описывается один раз, дальше подставляются конкретные модули. Цифры по такому разделению работ уже приводились в разборе об экономии времени и потере экспертизы при работе с ИИ-ассистентами: на шаблонных задачах ускорение заметное, на сложной логике оно падает и может уйти в минус.
Как формулировать ограничения, чтобы тесты не были формально корректными, но бесполезными
Ограничения должны быть конкретными и проверяемыми:
- запрет на проверки несуществующих сценариев;
- требование проверять граничные значения, а не только типовой случай;
- явное указание критичных и некритичных участков;
- запрет на дублирование уже существующих проверок.
Условный пример формулировки для промпта:
Не генерируй тесты для функций, которые не участвуют в бизнес-процессах. Сосредоточься на проверке расчётов и обработке исключений. Для каждого теста укажи, какое бизнес-правило он проверяет.
Без таких ограничений модель охотно проверяет очевидное: что функция существует, что она не падает, что getter возвращает значение. Реальные риски остаются без покрытия, а команда получает объём тестов вместо их качества.
Как проверять сгенерированные тесты и не доверять им слепо
Сгенерированный тест выглядит убедительно и вызывает доверие к себе. Он компилируется, проходит, читается логично. Проверка нужна на двух уровнях: сам код и то, что именно этот тест проверяет. Второй уровень пропускают чаще всего.
Полезный приём: убедиться, что тест краснеет на заведомо некорректных данных. Если проверка проходит и на правильном значении, и на неправильном, она не проверяет ничего. На этом же принципе строится мутационное тестирование: логику намеренно ломают и смотрят, поймает ли это существующий набор проверок.
Чек-лист проверки сгенерированного теста
- Тест компилируется и запускается без ошибок.
- Тест проверяет ту бизнес-логику, которая заявлена в его названии и комментарии.
- Тест покрывает граничные значения, а не только типовой случай.
- Тест падает на заведомо некорректных данных.
- Тест не дублирует другие проверки.
- Тест не проверяет несуществующие сценарии и удалённый функционал.
Пункты 2 и 4 отсеивают основную часть «уверенной ерунды». Пункт 6 ловит фантазии модели о функциональности, которой в конфигурации нет. ИИ не заменяет экспертизу QA-инженера, он ускоряет черновую работу, которую всё равно нужно принимать.
Полезны материалы, после которых остаётся готовый артефакт: репозиторий, шаблон, инструкция, проверочный список. Пример такого формата - чек-лист проверки результатов модели в разборе про one-shot программирование. Про то, почему контроль над делегированными задачами нельзя отдавать автоматике, подробно разобрано в материале о делегировании кода ИИ-агентам и инженерной ответственности.
Что можно автоматизировать без нейросетей: автотесты, шаблоны, чек-листы
Значительную часть повторяющихся операций тестировщика можно сократить без нейросетей: автотестами, шаблонами, чек-листами и правильно выстроенными процессами. Регрессионное тестирование типовых сценариев, подготовка тестовых данных, проверка обязательных полей и форматов - задачи, где стабильный скрипт или список проверок надёжнее и дешевле, чем генерация заново при каждом прогоне.
ИИ стоит подключать там, где нужен разбор сложного случая, анализ логов, подготовка черновика проверок или объяснение незнакомого кода. Ценность инструмента определяется не технологической новизной, а возможностью встроить его в ежедневную работу.
Vanessa Automation и ИИ: практический сценарий для дымового тестирования
Один из рабочих сценариев - сочетание Vanessa Automation и ИИ при дымовом тестировании. Автоматизация берёт на себя выполнение стабильных проверок, а модель может помогать с подготовкой сценариев и анализом результатов. Схема выглядит так: Vanessa Automation прогоняет дымовой набор после сборки, модель разбирает логи упавших прогонов и предлагает, какие проверки добавить или уточнить.
Ручное тестирование такой подход не отменяет. Он снимает рутину с повторяющихся прогонов и ускоряет реакцию на изменения, а решение о составе дымового набора остаётся за QA-инженером.
Качество продукта: ответственность всей команды, а не одного QA
Граница между тестированием, разработкой и аналитикой становится всё менее заметной, и ответственность распределяется по ролям. Разработчик отвечает за тестируемость кода и юнит-тесты, аналитик - за однозначность требований, QA-инженер - за стратегию проверок и оценку рисков, руководитель - за процессы и взаимодействие специалистов.
Пример разрыва: если аналитик формулирует требование неоднозначно, QA-инженер не сможет проверить его корректно, а разработчик напишет код, который сложно покрыть тестами. ИИ эту ответственность не снимает, он меняет инструменты и скорость работы.
Матрица компетенций: как зафиксировать требования к навыкам и зоны ответственности
Матрица компетенций помогает растущим командам фиксировать требования к навыкам и зоны ответственности. Для QA-инженера в ней могут стоять работа с ИИ, знание платформы 1С, умение писать промпты и проверять сгенерированные тесты; для разработчика - проектирование тестируемого кода и юнит-тесты; для аналитика - однозначные формулировки требований. Когда команда растёт, матрица не даёт размыть роли и потерять качество.
Смежная тема - набор компетенций, который сохраняет ценность при активном использовании моделей: разбор четырёх компетенций, которые ИИ не заменяет.
Что остаётся за человеком: ограничения ИИ и практические выводы
ИИ умеет генерировать тесты, разбирать легаси-код и автоматизировать рутину. Без правил и контроля он создаёт бесполезные проверки, поэтому специалисту приходится проверять два слоя: сгенерированный код и то, что этот тест проверяет.
Что делать на практике:
- задавать контекст, правила и ограничения до генерации: бизнес-логику, критичные сценарии, примеры данных, ожидаемые результаты;
- проверять сгенерированные тесты по чек-листу и убеждаться, что проверка падает на некорректных данных;
- отдавать рутину существующим инструментам: автотестам, шаблонам, чек-листам, Vanessa Automation;
- фиксировать зоны ответственности в команде и в матрице компетенций.
Ограничения стоит назвать прямо. В материалах секции QA INFOSTART TECH EVENT 2026, на которые опирается этот текст, нет конкретных метрик, бенчмарков и примеров сгенерированных тестов для 1С, поэтому цифры эффективности приводить нечем: тезисы касаются подходов и организации процесса, а не готовых рецептов на все случаи. Ещё одно ограничение лежит в самих моделях: они не знают критичность ваших модулей, пока им об этом не рассказали.
Практический шаг для старта: выберите один участок системы, опишите его бизнес-правила, сгенерируйте тесты, прогоните их по чек-листу и сравните с тем, что писали вручную. Если проверки ловят реальные ошибки, расширяйте область. Если они подтверждают очевидное, проблема в контексте и ограничениях промпта, а не в модели.