> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/ai-v-testirovanii/context-engineering.md).

# Context Engineering

**Context Engineering** — дисциплина проектирования и управления контекстом, который передаётся AI-модели для получения точных и воспроизводимых результатов. В отличие от разовых промптов, Context Engineering — системная практика: стандарты, шаблоны и процессы, обеспечивающие стабильное качество AI-вывода.

Термин возник как реакция на «Prompt Engineering» — практику создания эффективных промптов. Context Engineering расширяет её: важен не только текст промпта, но и весь контекст — примеры, структура запроса, прикладываемые данные, порядок информации.

***

## Почему контекст важнее промпта

Модель видит только то, что передано в её контекстное окно. Промпт — часть контекста, но не единственная. Что ещё входит в контекст:

* System prompt (роль, инструкции, ограничения)
* Примеры ввода-вывода (few-shot examples)
* Прикладываемые документы, код, данные
* История диалога
* Структура и порядок информации
* Метаданные (дата, версия, окружение)

**Пример:** один и тот же вопрос «Найди баги в этом коде» даёт разный результат в зависимости от того, передан ли контекст команды (стайлгайд, архитектура, типичные ошибки проекта) или нет.

***

## Компоненты контекста

### System Prompt

Задаёт роль, поведение и ограничения модели. Для QA-задач:

```
Ты — старший QA-инженер с 10-летним опытом тестирования веб-приложений.
Когда тебе передают код или требования, ты:
1. Ищешь потенциальные дефекты
2. Предлагаешь тест-кейсы в формате Given/When/Then
3. Явно указываешь граничные условия
4. Отвечаешь по-русски, используя технические термины на английском
```

### Few-Shot примеры

Примеры ввода и желаемого вывода — самый мощный инструмент управления поведением модели:

```
Пример 1:
Вход: функция деления двух чисел
Выход:
- Позитивный: 10 / 2 = 5
- Негативный: деление на ноль → исключение
- Граничные: очень большие числа, отрицательные числа

Пример 2:
Вход: форма регистрации с полями email и пароль
Выход: [детальные тест-кейсы]
```

### Retrieval-Augmented Context (RAC)

Динамическое добавление релевантной информации в контекст перед запросом:

* Документация на функцию, которую тестируем
* История дефектов в этом компоненте
* Требования к тестируемому модулю
* Стайлгайд команды

### Структура и порядок

Порядок информации в контексте влияет на качество ответа. Принцип: самое важное — в начале и в конце (эффект primacy и recency). Чёткая структура (заголовки, списки) помогает модели выделить ключевые части.

***

## Context Engineering в QA-практике

### Шаблоны контекста для типовых задач

#### Генерация тест-кейсов по требованию

```markdown
## Задача
Сгенерируй тест-кейсы для следующего требования.

## Стандарт формата
Каждый тест-кейс:
- ID: TC-[номер]
- Название: [краткое описание]
- Предусловия: [состояние системы]
- Шаги: [нумерованный список]
- Ожидаемый результат: [конкретный, проверяемый результат]
- Тип: [позитивный / негативный / граничный]

## Требование
[ВСТАВИТЬ ТРЕБОВАНИЕ]

## Контекст системы
[ВСТАВИТЬ: технологический стек, ограничения, смежные функции]
```

#### Анализ кода на дефекты

```markdown
## Роль
Ты проводишь security и quality ревью кода.

## Что искать
1. OWASP Top 10 уязвимости
2. Необработанные исключения
3. Граничные условия без валидации
4. Race conditions
5. Memory leaks

## Код для анализа
[ВСТАВИТЬ КОД]

## Контекст
Язык: [Python/Java/JS]
Фреймворк: [название и версия]
Этот код: [что делает, с чем взаимодействует]
```

#### Анализ баг-репорта

```markdown
## Задача
Проанализируй баг-репорт и предложи:
1. Возможные корневые причины
2. Дополнительные шаги для воспроизведения
3. Смежные области для регрессионного тестирования

## Баг-репорт
[ВСТАВИТЬ БАГИ]

## Контекст
Версия: [X.X.X]
Окружение: [staging/production]
Последние изменения: [если известно]
```

***

## Принципы качественного контекста

### 1. Минимальная достаточность

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

**Плохо:** передать весь файл кода, когда нужен анализ одной функции **Хорошо:** передать функцию + её зависимости + интерфейс

### 2. Конкретность над общностью

```
❌ «Найди проблемы в коде»
✅ «Найди уязвимости SQL-инъекций и необработанные null-pointer ошибки в этом коде»
```

### 3. Явные ограничения

Указывайте, что модель НЕ должна делать:

```
Не предлагай рефакторинг — только ищи баги.
Не изменяй архитектуру — только добавляй тесты.
Отвечай строго в указанном формате.
```

### 4. Версионирование контекста

Шаблоны контекста — артефакты команды. Они должны:

* Храниться в репозитории
* Версионироваться вместе с кодом
* Проходить ревью при изменении
* Иметь changelog

{% hint style="info" %}
Шаблон контекста для генерации тест-кейсов — такой же командный стандарт, как шаблон баг-репорта или тест-кейса. Вложите время в его создание один раз и используйте постоянно.
{% endhint %}

***

## Context Window Management

Контекстное окно модели ограничено (в токенах). При работе с большими кодовыми базами важно управлять тем, что попадает в контекст.

### Стратегии

| Стратегия                            | Описание                                  | Когда применять        |
| ------------------------------------ | ----------------------------------------- | ---------------------- |
| Chunking                             | Разбивка на части, обработка по очереди   | Анализ большого файла  |
| Summarization                        | Сжатие истории диалога                    | Длинные сессии         |
| Selective inclusion                  | Добавление только релевантных файлов      | Анализ конкретной фичи |
| RAG (Retrieval-Augmented Generation) | Динамический поиск релевантных фрагментов | Большие кодовые базы   |

### Приоритеты при нехватке контекста

1. Задача и инструкции (критично)
2. Прямой объект анализа (код, требование)
3. Примеры ожидаемого формата
4. Дополнительный контекст (история, зависимости)

***

## Context Engineering vs Prompt Engineering

| Аспект            | Prompt Engineering   | Context Engineering            |
| ----------------- | -------------------- | ------------------------------ |
| Фокус             | Формулировка запроса | Весь контекст модели           |
| Масштаб           | Разовый промпт       | Системная практика             |
| Артефакты         | Текст промпта        | Шаблоны, библиотеки, стандарты |
| Версионирование   | Редко                | Обязательно                    |
| Тестирование      | Интуитивно           | Структурировано                |
| Воспроизводимость | Непоследовательная   | Высокая                        |

***

## Тестирование контекста

Контекстные шаблоны нуждаются в тестировании так же, как код:

### Что тестировать

* **Стабильность**: один и тот же контекст → стабильный формат вывода
* **Полнота**: все необходимые элементы присутствуют в выводе
* **Соответствие формату**: вывод соответствует ожидаемой структуре
* **Граничные случаи**: что происходит при пустых или минимальных входных данных
* **Регрессия**: обновление модели не ухудшило качество вывода

### Метрики качества контекста

| Метрика                | Описание                                       |
| ---------------------- | ---------------------------------------------- |
| Точность               | % выводов, соответствующих ожиданиям           |
| Полнота                | % требуемых элементов, присутствующих в выводе |
| Форматное соответствие | % выводов в правильном формате                 |
| Стабильность           | Вариация качества между запусками              |

***

## Применение в QA-команде

### Создание библиотеки контекстов

```
qa-prompts/
├── test-design/
│   ├── generate-test-cases.md
│   ├── boundary-analysis.md
│   └── risk-analysis.md
├── defect-analysis/
│   ├── root-cause-analysis.md
│   └── regression-scope.md
├── documentation/
│   ├── bug-report-review.md
│   └── test-plan-review.md
└── CHANGELOG.md
```

### Процесс обновления

1. QA-инженер обнаруживает, что шаблон даёт неточный результат
2. Создаёт issue с примером плохого вывода
3. Предлагает улучшение шаблона
4. Команда проводит ревью
5. Обновлённый шаблон тестируется на наборе эталонных случаев
6. Публикуется с changelog

***

## Источники

* [Anthropic — Prompt Engineering Guide](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) — официальное руководство по работе с контекстом
* [Simon Willison — Prompt Injection and Context Attacks](https://simonwillison.net/) — риски управления контекстом
* [LangChain — RAG Documentation](https://python.langchain.com/docs/concepts/rag/) — реализация Retrieval-Augmented Generation