Я работаю с тестированием и автоматизацией уже много лет. В последние месяцы активно внедряю ИИ-инструменты в рабочие процессы своей команды — в том числе для генерации тест-кейсов на основе проектной документации. Казалось бы, задача очевидная: вот у нас есть документация, вот — языковая модель. Генерируем тесты, экономим время - и все счастливы. Однако реальность оказалась совершенно другой. Я раз за разом сталкивался с одними и теми же проблемами:

• сложные, неудобные, противоречивые документы,

• отсутствие четкой структуры,

• размытая терминология и вложенные таблицы,

• постоянная борьба за контекст и точность.

Именно поэтому я написал эту статью — чтобы подсветить реальную, системную проблему, которую многие уже приняли как «неизбежную данность». Но эта данность мешает нам двигаться вперёд. Она тормозит автоматизацию. Она делает даже мощные AI-инструменты бесполезными.

✨ Иллюзия простоты

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

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

В этой статье я расскажу:

• Почему работа с документацией — это главная проблема в генерации тест-кейсов с ИИ;

• Почему инструменты вроде TestWriter — это не просто обёртка вокруг GPT, а сложная инженерная система;

• И что нужно менять, чтобы генерация действительно начала работать.

? Документация — это хаос

С чего всё начинается? С документации. Но на практике это вовсе не структурированные требования в формате BDD. Это:

•  Confluence-страницы, сопоставимые по объёму с романом в трёх томах.

•  Таблицы внутри таблиц с перемешанными столбцами.

•  Циклические ссылки между разделами.

•  Скриншоты вместо описаний.

•  Псевдоязык вроде «если условие выполнено, то возможно...», без конкретики.

ИИ видит в этом хаос — как, впрочем, и человек.

Вот более универсальный и живой пример, в котором такая “боль” считывается с первого взгляда - с человеческими акцентами и четкой визуализацией. Он подойдёт для статьи и попадет точно в нерв тем, кто бывал в похожей ситуации. 

? Пример боли: "типовой" документ, с которым работает ИИ

Вот реальный собирательный пример страницы с требованиями, с которыми мы сталкиваемся в проектах.

Выглядит она примерно так:

Документ начинается с уходящего в бесконечность содержания:

под которым указывается цель разработки экранной формы со ссылками на внешнюю документацию и скудные “детали” реализации. Все требования к UI представлены в виде скриншота:

За этим “описанием” UI следует таблица с частично заполненными хештегами полей, по которым в системе можно найти те либо иные параметры и объекты, участвующие в расчетах с поставщиком и цветовая легенда для расшифровки последующих таблиц:

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

Вишенкой на торте к данным требованиям служат:

• таблицы, вложенные в колонки основной таблицы с требованиями

• ячейки таблиц, заполненные в формате Markdown

• непонятные правила валидации непонятно чего: значений, которые могут принимать поля, соответствующих полей в базе данных (отдельный квест - выяснить в какой именно) или фаз Луны в Козероге

• правила заполнения полей формы, которые нужно уметь “читать” между строк

• множество ссылок на внешние справочники и описания объектов

• пометки аналитиков и дизайнеров: “скорее всего будет, если в заявке нет валютных платежей”, скриншот экрана с пометками от дизайнера: "примерная реализация, финальные состояния TBD"

• Подпись к скриншоту: "так примерно должно быть, но не финально"

• и, наконец, цвета, в которые раскрашена основная таблица, отсутствующие в легенде:

И на этом - всё:

• Нет уникальных ID требований

• Нет явно отделённых expected results

• Нет понятной роли (кто действует: система или пользователь?)

• Нет структуры, которую можно было бы интерпретировать без домыслов

ИИ в таких условиях сталкивается с невозможностью принять решение:

• Где здесь тестируемое поведение, а где просто обсуждение?

• Что является обязательным сценарием, а что примером из переписки?

• Где валидные входные данные, а где — домыслы?

• И как вообще связаны внешние ссылки на правила валидации и текст с правилами валидации прямо под ней?

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

? Проблема №1 — отсутствие стандартов

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

• Один аналитик пишет длинные описания в Confluence без единого подзаголовка.

• Другой — использует Excel-файл с десятками скрытых листов и вложенными таблицами.

• Третий — рисует схемы в Miro и снабжает их подписями вроде «Тут вроде бы создаётся заявка, но не факт».

• Кто-то копирует текст требований из Telegram.

• А иногда — всё это вместе.

? Результат:

• Нет унифицированных шаблонов.

• Нет чётких ролей, условий, ожиданий.

• Нет машиночитаемой структуры.

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

Итог: ИИ не способен вычленить из этого хаоса полноценные test-cases, пока за него не проведут колоссальную подготовительную работу. А значит — вся автоматизация срывается на этапе первого же документа.

? Генерация — это не "просто прогнать через GPT"

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

1. Сегментация: документ разбивается на логические блоки (semantic chunks).

2. Нормализация: markdown-преобразования, парсинг таблиц, устранение мусора.

3. Классификация: каждое утверждение помечается как действие, условие, ожидание, роль (пользователь, система, API).

4. Реконструкция логики: выстраиваются зависимости между шагами, формируются ветки и альтернативные сценарии.

5. Формирование структуры тестов: с учётом типа продукта, платформы и требований к тестовой модели.

6. Ограничения: обрабатываются лимиты на токены, контекст, контракты с другими документами.

7. Валидация: финальный результат проходит проверку на полноту, связность и логичность.

И всё это нужно только для того, чтобы иметь шанс сгенерировать тест-кейс, который будет похож на правду.

?️ Почему мы сделали TestWriter

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

• Распознаёт структуру документа и превращает её в обучающий контекст для модели.

• Умеет работать с вложенными таблицами, списками, графами — и извлекать из них смысл.

• Разбирает каждую строчку на действия, условия, роли, сценарии, ветки.

• Формирует output в понятном формате: CSV, Markdown, JSON.

• Вставляет чек-листы, добавляет ожидаемые результаты и проверку edge-кейсов.

И всё это — не ради модного слова “AI”, а потому что иначе автоматизация генерации попросту невозможна. Без мощной обработки — ИИ бессилен.

? Как навести порядок в документации (и помочь ИИ)

Если вы хотите, чтобы генерация тестов работала стабильно — придётся вложиться в порядок и структуру. Ниже — подходы, которые делают жизнь проще и вам, и ИИ-инструментам.

1. Внедрите шаблоны требований

Название: Авторизация по логину и паролю  

ID: AUTH-001  

Как пользователь, я хочу войти в систему по логину и паролю.  

Условия:

• Пользователь зарегистрирован

• Введён валидный логин и пароль

Ожидаемый результат:

• Успешная авторизация

• Перенаправление на главную страницу

ИИ лучше всего работает, когда текст разбит на логические фрагменты: роли, действия, условия, ожидания. Чем ближе к BDD — тем надёжнее результат.

2. Таблицы — только нормализованные

Не допускается:

• Вложенные таблицы.

• Markdown в ячейках.

• Перемешивание UI, API и бизнес-логики в одном блоке.

3. Всегда указывайте роль субъекта

ИИ не понимает, кто действует:

• Пользователь нажимает кнопку.

• Система отвечает.

• Сервис возвращает ошибку.

Без указания — путаница и тесты "в воздух".

4. Пишите «по-структурному», не «по-человечески»

? Плохо: 

Если пользователь ввёл некорректный пароль, и система поняла это, то, возможно, стоит показать ошибку.

? Хорошо:

Условие: пароль некорректный

Действие: нажата кнопка "Войти"

Ожидание: сообщение об ошибке

Код ошибки: 401

5. Минимизируйте внешние ссылки

ИИ не открывает вложенные Excel-файлы и Telegram-скрины. Всё важное должно быть в тексте документа. Если вы используете Confluence — не делайте вложенные страницы, старайтесь всё держать рядом.

6. Заводите глоссарии

«Объект», «блок», «юнит», «сегмент» — если эти слова значат разное, документ становится нечитаемым. Сделайте глоссарий. Это поможет и ИИ, и команде.

7. Дробите монолиты

Техническое задание на 60 экранов = провал генерации. Разбивайте на логические части по 2–5 страниц.Так проще:

• Обрабатывать,

• Проверять,

• Поддерживать.

Финальный вывод: документация — это самое трудное звено

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

• Большинство проектных документов непригодны для автоматизации.

• Большинство таблиц и описаний требуют предобработки.

• Генерация тестов — это не творчество, а сложный NLP-инжиниринг.

В реальности автоматизация — это не история про "вот тебе GPT, сгенерируй мне тесты". Это:

• Интеграция с Confluence/Jira/API.

• Парсинг и нормализация вложенных структур.

• Семантический анализ языка и классификация сущностей.

• Построение пайплайнов генерации: от chunk'ов и подсказок до анализа валидности.

• И всё это — под капотом.

Создание таких инструментов, как TestWriter, требует месяцев (если не лет) инженерной работы:

• Над обработкой плохих данных.

• Над стабилизацией результата.

• Над объяснимостью и валидацией генерации.

Это не про красивый UI. Это про глубокую интеграцию с реальностью.

Призыв к действию

? Если вы — аналитик:

• Задумайтесь, насколько ваши документы читаемы не только людьми, но и машинами.

• Используйте шаблоны, избегайте вложенности, пишите с акцентом на однозначность.

? Если вы — QA или инженер:

• Требуйте структурированную документацию.

• Помогайте внедрять шаблоны.

• Изучайте инструменты, которые умеют работать с реальной документацией.

? Если вы — архитектор или техлид:

• Поддержите внедрение процессов, которые сделают документацию пригодной для автоматизации.

• Помните: хорошая документация — это не бюрократия. Это актив. Это основа любого AI-подхода.

Документация — это самый недооценённый фронт в битве за автоматизацию.

Мы хотим жить в мире, где ИИ помогает нам тестировать быстро, качественно и масштабируемо. Но без структурированных требований, без порядка — никакой ИИ не поможет. 

Спасибо Ирине за помощь в подготовке примера того самого хаоса, с которым ИИ сталкивается в реальности. Без её участия он был бы не таким красноречивым.

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

Борьба с документацией только начинается. И мы её не проиграем.

? Подписывайтесь на мой Telegram-канал про тестирование, AI и IT в целом! — там делюсь мыслями, новостями и практическими примерами из жизни!