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

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

В последние месяцы стало модно говорить о том, что искусственный интеллект способен автоматизировать всё: от написания кода до генерации тест-кейсов. Казалось бы — дал ИИ документ и получил готовый набор сценариев. Удобно. Эффективно. Будущее.
Но если вы хоть раз пытались генерировать тест-кейсы из реальной проектной документации, вы знаете что это боль. Настоящая, ежедневная, изматывающая боль.
В этой статье я расскажу:
Почему работа с документацией — это главная проблема в генерации тест-кейсов с ИИ;
Почему инструменты вроде TestWriter — это не просто обёртка вокруг GPT, а сложная инженерная система;
И что нужно менять, чтобы генерация действительно начала работать.
? Документация — это хаос

С чего всё начинается? С документации. Но на практике это вовсе не структурированные требования в формате BDD. Это:
Confluence-страницы, сопоставимые по объёму с романом в трёх томах.
Таблицы внутри таблиц с перемешанными столбцами.
Циклические ссылки между разделами.
Скриншоты вместо описаний.
Псевдоязык вроде «если условие выполнено, то возможно...», без конкретики.
ИИ видит в этом хаос — как, впрочем, и человек.
Вот более универсальный и живой пример, в котором такая “боль” считывается с первого взгляда - с человеческими акцентами и четкой визуализацией. Он подойдёт для статьи и попадет точно в нерв тем, кто бывал в похожей ситуации.
? Пример боли: "типовой" документ, с которым работает ИИ
Вот реальный собирательный пример страницы с требованиями, с которыми мы сталкиваемся в проектах.
Выглядит она примерно так:
Документ начинается с уходящего в бесконечность содержания:

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

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

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

Вишенкой на торте к данным требованиям служат:
таблицы, вложенные в колонки основной таблицы с требованиями
ячейки таблиц, заполненные в формате Markdown
непонятные правила валидации непонятно чего: значений, которые могут принимать поля, соответствующих полей в базе данных (отдельный квест - выяснить в какой именно) или фаз Луны в Козероге
правила заполнения полей формы, которые нужно уметь “читать” между строк
множество ссылок на внешние справочники и описания объектов
пометки аналитиков и дизайнеров: “скорее всего будет, если в заявке нет валютных платежей”, скриншот экрана с пометками от дизайнера: "примерная реализация, финальные состояния TBD"
Подпись к скриншоту: "так примерно должно быть, но не финально"
и, наконец, цвета, в которые раскрашена основная таблица, отсутствующие в легенде:

И на этом - всё:
Нет уникальных ID требований
Нет явно отделённых expected results
Нет понятной роли (кто действует: система или пользователь?)
Нет структуры, которую можно было бы интерпретировать без домыслов
ИИ в таких условиях сталкивается с невозможностью принять решение:
Где здесь тестируемое поведение, а где просто обсуждение?
Что является обязательным сценарием, а что примером из переписки?
Где валидные входные данные, а где — домыслы?
И как вообще связаны внешние ссылки на правила валидации и текст с правилами валидации прямо под ней?
? И самое важное: даже если вы каким-то чудом поняли, о чём речь, ИИ не обладает контекстом проекта, вашей терминологией и логикой документа — он работает только с тем, что написано, и если написано плохо — результат будет соответствующий.
? Проблема №1 — отсутствие стандартов

Сегодня мы всё ещё живём в реальности, где каждый проект пишет требования по-своему, исходя из личных предпочтений автора, а не здравого смысла или потребностей автоматизации.
Один аналитик пишет длинные описания в Confluence без единого подзаголовка.
Другой — использует Excel-файл с десятками скрытых листов и вложенными таблицами.
Третий — рисует схемы в Miro и снабжает их подписями вроде «Тут вроде бы создаётся заявка, но не факт».
Кто-то копирует текст требований из Telegram.
А иногда — всё это вместе.
? Результат:
Нет унифицированных шаблонов.
Нет чётких ролей, условий, ожиданий.
Нет машиночитаемой структуры.
Нет даже элементарной валидации: половина требований написана в будущем времени, другая — в сослагательном наклонении.
Итог: ИИ не способен вычленить из этого хаоса полноценные test-cases, пока за него не проведут колоссальную подготовительную работу. А значит — вся автоматизация срывается на этапе первого же документа.
? Генерация — это не "просто прогнать через GPT"
Именно тут рушится самое популярное заблуждение. Кажется, что генерация тестов — это легко: просто скормил текст модели, и она тебе всё разложила по полочкам. Но вот что на самом деле происходит под капотом любой качественной AI-системы генерации:
Сегментация: документ разбивается на логические блоки (semantic chunks).
Нормализация: markdown-преобразования, парсинг таблиц, устранение мусора.
Классификация: каждое утверждение помечается как действие, условие, ожидание, роль (пользователь, система, API).
Реконструкция логики: выстраиваются зависимости между шагами, формируются ветки и альтернативные сценарии.
Формирование структуры тестов: с учётом типа продукта, платформы и требований к тестовой модели.
Ограничения: обрабатываются лимиты на токены, контекст, контракты с другими документами.
Валидация: финальный результат проходит проверку на полноту, связность и логичность.
И всё это нужно только для того, чтобы иметь шанс сгенерировать тест-кейс, который будет похож на правду.
?️ Почему мы сделали 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)
SolutionFound
07.07.2025 07:41Составители подобных документаций действуют по принципу:
Ну блин, если всё привести в идеально читаемый вид, то не нужон ентот ваш ИИ. По такой качественной документации я и сам тесты написать смогу! Но мне лень всё приводить в порядок, поэтому - мучайтесь, разбирайтесь сами. Вам что, зря деньги плотють?
Dhwtj
07.07.2025 07:41вычленить из этого хаоса полноценные test-cases
В общем, идея интересная. Попробую на своих кейсах
Nytoshnaya_Satoshi
Текст написан ИИ