МАЯК собрал QA-конвейер из 58 блоков и поймал 9 ловушек из 10 в ТЗ

Автор проекта МАЯК собрал конвейер, который доводит техническое задание до прогона тестов через 58 специализированных блоков. На синтетическом ТЗ с десятью заложенными дефектами автомат поймал девять. Десятый нашёл человек, но с вопросником, который составила машина. За 90 секунд система выдала 26 вопросов стейкхолдерам и отметила 20 серых зон, а за 26 минут написала 37 BDD-сценариев.

Документация раньше кнопок

Название проекта задаёт порядок работы: сначала разбираемся с требованиями, потом пишем и запускаем тесты. Цепочка выглядит так: «ТЗ → канонизация → тест-дизайн → прогон». Судя по названию этапа, канонизация приводит разрозненный текст требований к единому структурированному виду. Затем на нём строится тест-дизайн. Логика понятная: тесты, выведенные из расплывчатого ТЗ, наследуют его расплывчатость и только маскируют её аккуратным форматом.

Проект относится к растущему классу систем, где LLM работает не одним промптом, а длинным конвейером узких шагов. Здесь таких шагов 58.

Гейты доверия вместо угадывания

Главная проблема языковых моделей в тест-дизайне — склонность достраивать недостающее правдоподобной конкретикой. В ТЗ написано «страница должна открываться быстро». Модель с готовностью выдаёт «не более 2 секунд» и оформляет это как критерий приёмки. Автор МАЯК закрывает эту дыру двумя правилами:

• каждый критерий приёмки заземляется цитатой из исходного документа, нет цитаты — нет критерия;
• серая зона превращается в вопрос стейкхолдеру, а не в угаданное значение.

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

Что показал прогон

Проверка шла на синтетическом ТЗ, куда автор заранее заложил десять «болезней». Результаты из анонса:

• 9 из 10 ловушек поймал автомат;
• десятую нашёл человек, опираясь на вопросник от машины;
• 26 вопросов стейкхолдерам сформированы за 90 секунд;
• выявлено 20 серых зон;
• 37 BDD-сценариев готовы за 26 минут.

Цифры нужно читать с оговорками. Ловушки придумал сам автор, документ синтетический, прогон один. Это демонстрация работоспособности, а не бенчмарк. Реальные ТЗ обычно длиннее, противоречивее и местами написаны людьми, которые сами не знают, чего хотят. Сам автор обещает рассказать, где платформа врёт и что остаётся недоработанным. Эти разделы есть в полном тексте на Habr, в анонсе деталей нет, поэтому оценить масштаб ошибок пока нельзя.

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

Что взять в работу

Из проекта можно забрать несколько приёмов, даже не копируя его целиком:

• Прогоните свой конвейер на документе с заранее заложенными дефектами и посчитайте долю найденных. Без такого эталона разговоры о качестве остаются мнениями.
• Требуйте от модели цитату-источник для каждого критерия приёмки и автоматически отбрасывайте всё, что без неё.
• Измеряйте не только число сгенерированных сценариев, но и долю вопросов, на которые стейкхолдеры реально ответили. Хороший вопросник бесполезен, если на него не отвечают.
• Кэшируйте промежуточные результаты блоков, чтобы правка одного абзаца ТЗ не перезапускала весь конвейер.
• Оставляйте человека на финальном ревью. Девять из десяти на синтетике ещё не гарантия на боевом документе.

Если у вас накопился архив ТЗ с известными постфактум проблемами, это готовый тестовый набор для такого подхода.