Применение языковых моделей в тестировании программного обеспечения упирается в одну практическую проблему раньше, чем доходит до промптов и агентов: модель должна понимать предметную область. Без этого она не найдёт противоречий в требованиях, не увидит связей между компонентами и не предложит осмысленных тест-кейсов. Именно поэтому подготовка контекста — первый и самый трудоёмкий этап.
Под контекстом здесь понимается структурированная информация о продукте: описания компонентов, бизнес-правила, сценарии использования и связи между сущностями. Это не просто дамп документации — сырой текст из Confluence, выгруженный одним файлом, скорее мешает модели, чем помогает. LLM «тонет» в неразмеченном потоке и теряет иерархию смысловых блоков.
| Ошибка при подготовке контекста | Последствие для работы LLM |
|---|---|
| Слишком мало контекста | Модель не видит связей между частями продукта |
| Слишком много неструктурированного или дублирующего текста | Сложнее анализировать, выше риск «шума» |
| Устаревший контекст | Ложные замечания и лишние вопросы |
| Нет явных связей между сущностями и компонентами | Противоречия между разделами ТЗ не всплывают |
Для небольших продуктов — например, калькулятора страховой премии для онкологических заболеваний с пятью основными экранами — автор описывает пятишаговый процесс. Сначала вся информация собирается в одну папку: текст из Confluence копируется в единый файл, таблицы с описанием элементов выгружаются в CSV. Затем материал структурируется по UI-компонентам: внутри каждого — описание элементов, сценарии, правила. На третьем шаге применяется Markdown: заголовки для разделов, списки для правил, блоки для сценариев. Это помогает модели ориентироваться в иерархии. Если информации слишком много — она разбивается на несколько файлов, оптимальный размер одного файла составляет от 5 до 15 страниц. Пятый шаг — актуализация: при изменении требований контекст обновляется сразу.
Для простых ТЗ достаточно пяти шагов: сбор в одну папку, структурирование, Markdown-разметка, разбиение на файлы и актуализация.
Все эти операции — структурирование, Markdown-разметка, внесение правок — автор рекомендует делегировать самой LLM. Модель хорошо справляется с форматированием текстовых файлов и может подсказать, в какие именно разделы нужно добавить новую информацию. Дополнительно предлагается создавать README.md с описанием структуры папки, словарь терминов предметной области и проверять контекст, попросив модель кратко пересказать, что она поняла.
Сложнее ситуация с крупными командами, чьи технические задания занимают до ста страниц и включают таблицы и макеты. Простое копирование из Confluence здесь не работает. Экспорт из Confluence доступен только в форматах PDF и Word, ни один из которых Cursor не читает в нужном виде напрямую. Решение — Python-скрипты, которые разбирают PDF на текст и изображения. Скрипт целиком написал Cursor по описанию задачи: извлечь весь текст и сохранить в Markdown, извлечь все изображения и сохранить в PNG в отдельную папку. Для извлечения текста скрипт последовательно пробует три библиотеки — pdfplumber (лучше работает с таблицами), pymupdf (быстрее и точнее) и PyPDF2 как базовый вариант.
Такой подход показывает характерную для современного рабочего процесса с LLM логику: модель используется не только как аналитик требований, но и как инструмент для подготовки собственного контекста — пишет скрипты, форматирует документы, обновляет файлы. Это снижает ручную работу тестировщика на подготовительном этапе, хотя и требует понимания того, какая структура нужна на выходе.