Часть 3. Практика · Глава 11

Встраивание в QA-процесс

Цели раздела

3 пункта

К концу раздела вы сможете:

Понять, как встроить LLM-практики в повседневную работу команды.
Обеспечить воспроизводимость результатов.
Создать культуру ответственного использования ИИ.

LLM по фазам жизненного цикла (ориентир для QA)

Карта этапов и шаблонов главы 7

Этап	Роль QA	Применение LLM	Шаблоны (гл. 7)
Планирование / требования	Анализ, риски	Разбор ТЗ, неоднозначности, вопросы	7.1,7.2
Дизайн	Тест-дизайн	Кейсы, трассировка	7.2,7.7
Разработка	Shift-left	Черновики автотестов, ревью тестируемости	7.9
Тестирование	Выполнение, документирование	Данные, баги, регресс	7.4,7.5,7.6,7.8
Исследовательское	Идеи, сессии	Charter, нестандартные сценарии	7.3
Релиз	Регресс, отчётность	Чек-листы, отчёты	7.8
Сопровождение	Инциденты	Гипотезы по логам, постмортем	7.5

SDLC (жизненный цикл разработки ПО) — этапы от требований до релиза. Таблица выше — не жёсткий регламент, а карта того, где шаблоны из Главы 7 обычно дают лучший эффект. См. Приложение A.

Модель зрелости внедрения (четыре уровня)

Уровень 1: Индивидуально(1–2 недели)

Личные эксперименты, черновики; промпты не зафиксированы.

DoD и командный реестр — в главе 11 и главе 12.

LLM в Definition of Done (фрагмент для командного обсуждения)

Ниже — интерактивный ориентир для обсуждения с командой (адаптируйте под свой процесс):

DoD: фрагмент для артефактов после LLM

0 / 9

Тест-кейсы (если генерировались через LLM)

Проверка по scorecard глава 10; ориентир по IP — порог согласован с командой
Нет кейсов без ссылки на требование / AC
Добавлены недостающие негативные сценарии

Баг-репорты (если формировались через LLM)

Шаги воспроизведения проверены вручную
Гипотезы отделены от фактов
Severity согласован с владельцем модуля / тимлидом

Код автотестов (если генерировался через LLM)

Code review пройден
Тест запущен локально / в CI
Нет «магических» таймаутов и захардкоженных секретов

Метрики эффективности: до и после

Чтобы обосновать внедрение LLM перед командой или руководством, полезно заранее договориться, что именно вы измеряете. Не обязательно все сразу — начните с одной метрики на 2–4 недели.

Метрика	Как измерить	Ожидаемый эффект (ориентир; зависит от задачи)
Время на первичный набор тест-кейсов	Засечь время на одно требование до внедрения шаблонов и после	Часто −40–60% на черновик при том же объёме ревью
Охват тест-кейсами	Число осмысленных кейсов на одно требование до/после	Рост полноты порядка +20–30% при контроле качества
Индекс пригодности (IP)	Доля кейсов (или других артефактов), принятых без существенных правок	Целевой порог команды, например ≥75% через несколько недель калибровки
Время на оформление баг-репорта	От воспроизведения до отправки в трекер	Часто −30–40% на рутинное оформление
Субъективная удовлетворённость	Короткий опрос на ретро (шкала 1–5)	Отслеживать динамику, а не абсолют

Личный план на две недели (минимум)

День 1: Поднять локальную LLM или утвердить корпоративный канал (preface, гл. 9)
День 2: Одна реальная задача шаблоном 7.1 (гл. 7)
День 3–4: Кейсы по 7.2, ревью по scorecard / IP (гл. 7, 10)
День 5: Баг-репорт по 7.5 (гл. 7)
День 6–7: Зафиксировать 3 лучших промпта в Prompt Book (Приложение C)
День 8–9: Регрессионный чек-лист 7.8 (гл. 7)
День 10: Оценить IP по своим кейсам за неделю (гл. 10)
День 11–12: Показать 2–3 промпта коллегам, собрать фидбек (гл. 9–11)
День 13–14: Обновить шаблоны и подумать об общем реестре (гл. 12)

Типичные возражения коллег

Возражение	Короткий ответ
«ИИ придумывает — зачем нам это?»	Используем как черновик; финальное решение и ревью — за людьми.
«Это небезопасно»	Политика каналов + анонимизация; чувствительное — не в публичный чат (Глава 9).
«Ответы каждый раз разные»	Ниже temperature, фиксированный формат вывода, эталонные примеры.
«Я и без этого справляюсь»	LLM сокращает рутину и расширяет охват; метрика — время и качество после ревью.

Когда LLM не стоит использовать

Отметьте прочитанное — список для самопроверки:

Нужен первоисточник (стандарты, регуляторика, юридически значимые спецификации) — опора на документ, а не на генерацию.
Есть формальная проверка — SQL, линтер, контрактный тест, JSON Schema, OpenAPI, unit-тест: сначала формальный механизм, не «мнение модели».
Высокая цена ошибки — удаление данных, релизное решение, инцидент безопасности: LLM не должна быть единственным источником решения.
Нет доменного контекста в промпте — модель уйдёт в общие паттерны, а не в специфику продукта.
Привилегированные действия (команды, внутренние API, смена конфигурации, письма) — нужны ограничения прав, валидация и human approval.

🧪 Пример для QA

Модель предложила 20 тест-кейсов для нового API.
Это полезный черновик.
Но если вы на его основе сразу закрываете тест-дизайн без сверки с OpenAPI, бизнес-правилами и негативными сценариями, вы фактически делегируете качество продукта системе, которая не несёт ответственности за результат.

Создание библиотеки промптов (Prompt Library)

Библиотека промптов — каталог проверенных, версионированных шаблонов для команды. Ключевой элемент масштабирования LLM-практик.

Нажмите на папку, чтобы раскрыть

📦

prompt-library/Git-репозиторий команды

5 папок · 13 файлов

README.mdОписание, правила использования, версионирование

functional-test-cases.md— Функциональные тест-кейсы по RTCCO

boundary-values.md— Граничные значения и классы эквивалентности

exploratory-charters.md— Чартеры для исследовательского тестирования

security-test-cases.md— Тест-кейсы безопасности (OWASP)

🔖Версионируйте промпты через Git — история помогает при смене модели

👤Добавляйте метаданные: автор, дата, для какой модели оптимизирован

🔄Обновляйте при смене LLM — промпты GPT-4o ≠ промпты Claude 3.5

📣Делитесь лучшими промптами на стендапах и ретроспективах

Рекомендации по ведению библиотеки:

Версионируйте промпты через Git.
Добавляйте метаданные: автор, дата, модель.
Проводите регулярное ревью.
Делитесь лучшими промптами на стендапах.

Определение стандартов качества (DoD) для LLM-артефактов

DoR для LLM-генерируемых артефактов — отметьте критерии готовности входа:

Критерий	Описание	Проверка
Полнота контекста	Все необходимые требования предоставлены	Чек-лист контекста
Корректность промпта	Промпт прошёл ревью по RTCCO	Чек-лист RTCCO
Безопасность	Нет чувствительных данных	Сканер анонимизации
Верифицируемость	Результат можно проверить	Чек-лист качества

Интеграция в CI/CD пайплайны (GenAIOps)

Возможные сценарии:

Автогенерация тестов при коммите: LLM генерирует черновик тест-кейсов в pull request.
Анализ логов сбоев: При падении тестов в CI LLM анализирует логи.
Оценка LLM-компонентов: Интеграция автоматической оценки в пайплайн.

Пример GitLab CI для генерации тестов:

YAML

generate_tests:
  stage: test
  script:
    - pip install openai
    - python scripts/generate_tests.py --changed-files "$CHANGED_FILES"
  only:
    - merge_requests

Инструменты: Promptfoo, DeepChecks, DeepTeam, Microsoft Prompt Flow.

Метрики эффективности использования LLM

Метрика	Как измерять	Целевое значение
Экономия времени на анализ требований	Сравнение до/после	30-50%
Скорость создания черновиков тест-кейсов	Время на N кейсов	50-70% ускорение
Частота галлюцинаций в принятых артефактах	Ревью случайной выборки	< 5%
Процент LLM-артефактов без доработки	Принято сразу / всего	> 60%
Удовлетворённость команды	Опросы	> 4/5

Практический пример: Рабочий процесс QA-инженера с LLM

Обозначения:🤖 LLM👤 Вручную🤝 LLM + человек

Анализ & Дизайн

📋

Анализ🤖 LLM

Получение user story→Промпт «Анализ требований»→Список вопросов к Product Owner

↓

✅

Тест-дизайн🤖 LLM

Уточнённые AC от PO→Промпт «Генерация тест-кейсов»→Черновик тестов

↓

🔍

Ревью🤖 LLM

Черновик тест-кейсов→Промпт «Ревью тест-кейсов»→Оценка и рекомендации

↓

🔧

Доработка👤 Вручную

Оценка и рекомендации→Ручная доработка QA-инженером→Финальный набор тест-кейсов

↓

Автоматизация

🤖

Автоматизация🤖 LLM

Финальные тест-кейсы→Промпт «Генерация автотестов»→Скелет кода для Playwright

↓

💻

Разработка👤 Вручную

Скелет кода→Ручная доработка и отладка→Рабочие автотесты в CI/CD

↓

Поддержка & Отчёт

🐛

Анализ сбоев🤖 LLM

Падение теста в CI/CD→Промпт «Анализ логов»→Гипотеза о причине сбоя

↓

📊

Отчётность🤝 LLM + человек

Завершение итерации→Промпт «Release report» + ревью→Финальный отчёт о качестве

🏁

Полный цикл завершён

LLM ускоряет шаги 1, 2, 3, 5, 7, 8 — человек критически важен на шагах 4 и 6. Типичная экономия: 40–70% времени на черновую работу при сохранении полного контроля качества.

Неделя 1: Только вы по чек-листу.

Неделя 2: Один общий шаблон на команду.

Далее: Библиотека промптов и DoD для артефактов.

Кого подключать: Тимлид/менеджер — для политики; все QA — для шаблонов.

Материалы к главе

Microsoft — GenAIOps for MLOps

Интеграция генеративного ИИ в DevOps-процессы.

Статья / Доки

genaiops

devops

Microsoft — GenAIOps with Prompt Flow and Azure DevOps

Сквозная интеграция Prompt Flow с Azure DevOps.

Microsoft — Azure AI Foundry

Платформа для корпоративного использования LLM.

Статья / Доки

microsoft

devops

Microsoft — Prompt Flow в AI Foundry

Оркестрация промптов и пайплайнов в Foundry.

Статья / Доки

microsoft

prompt-flow

Prompt Flow (open-source)

Открытый фреймворк оркестрации промптов.

Статья / Доки

prompt-flow

oss

LangChain — документация

Фреймворк для построения приложений на LLM.

Статья / Доки

langchain

orchestration

LlamaIndex — документация

Инструменты для RAG и работы с данными в LLM-приложениях.

Статья / Доки

llamaindex

orchestration

NIST AI RMF 1.0 (PDF)

Полный текст NIST AI Risk Management Framework 1.0.

Стандарт

nist

pdf

NIST AI RMF Playbook

Практический playbook по применению AI RMF.

Гайд

nist

playbook

OWASP — AI Agent Security Cheat Sheet

Чек-лист безопасности AI-агентов.