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

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

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

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

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

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

ID

Input

Expected Result

Notes

TC-001

Логин и пароль OK

Авторизация успешна

TC-002

Пароль неверный

Ошибка 401

Проверить локализацию

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

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

  • 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 в целом! — там делюсь мыслями, новостями и практическими примерами из жизни!

Комментарии (4)


  1. Nytoshnaya_Satoshi
    07.07.2025 07:41

    Текст написан ИИ


  1. swame
    07.07.2025 07:41

    Кто хочет документацию, написанную как эта статья?


  1. SolutionFound
    07.07.2025 07:41

    Составители подобных документаций действуют по принципу:
    Ну блин, если всё привести в идеально читаемый вид, то не нужон ентот ваш ИИ. По такой качественной документации я и сам тесты написать смогу! Но мне лень всё приводить в порядок, поэтому - мучайтесь, разбирайтесь сами. Вам что, зря деньги плотють?


  1. Dhwtj
    07.07.2025 07:41

    вычленить из этого хаоса полноценные test-cases

    В общем, идея интересная. Попробую на своих кейсах