AI в тестировании в 2026 году: практическое руководство для QA

1. Определи роль AI до первого промпта

LLM предсказывает продолжение текста, а не наблюдает твой стенд и не знает последнюю версию требований. Поэтому полезно заранее назначить ей ограниченную роль: собрать вопросы к аналитику, предложить классы данных, объяснить чужой код, сформировать черновик SQL или покритиковать уже готовый набор тестов. Формулировка «протестируй форму» слишком широка и провоцирует правдоподобный общий список.

До запроса запиши oracle — откуда берётся правильный ответ. Это может быть acceptance criterion, OpenAPI, правило расчёта, схема БД или согласованное решение product owner. Если oracle отсутствует, AI не должен придумывать ожидаемое поведение: его результатом становится перечень уточняющих вопросов и рисков.

• Цель: какое решение нужно принять после ответа?
• Контекст: какие правила уже известны?
• Ограничение: чего модель не может подтвердить?
• Формат: таблица, список, SQL или тест-кейсы?
• Проверка: какой источник или запуск подтвердит результат?

2. Дай контекст, ограничения и формат результата

Хороший промпт похож на постановку задачи коллеге. Укажи систему, роль пользователя, бизнес-правило, входные данные, известные состояния и требуемый формат. Попроси модель отделить факты от предположений и пометить вопросы, на которые контекста не хватает. Такой контракт уменьшает воду и делает ответ проверяемым.

Не проси сразу сотню тестов. Сначала запроси модель рисков и области эквивалентности, затем уточни важные ветви. Для сложной функции удобно использовать два прохода: генератор предлагает набор, критик ищет дубли, пропуски и неподтверждённые expected results. Финальный список всё равно сверяется человеком.

Контекст: CRM. Менеджер может конвертировать lead в customer.
Известно: email customer уникален; повторный запрос возможен после timeout.
Задача: составь таблицу рисков и тест-идей.
Для каждой строки дай: условие, действие, наблюдаемый результат, источник oracle.
Не придумывай правила. Неясности вынеси в Questions.

3. Используй AI для тест-дизайна, а не для количества

Модель хорошо предлагает варианты, когда ей даны параметры и правила: границы количества, состояния заказа, роли, способы оплаты. Попроси сначала вывести классы эквивалентности, decision table или state model, а уже затем минимальный набор тестов. Так можно увидеть логику сокращения, а не получить двадцать похожих формулировок.

Проверяй покрытие независимо. Для диапазона 1–10 должны быть значения около обеих границ; для переходов состояния — разрешённые и запрещённые ребра; для pairwise — пары действительно должны встречаться. Особенно внимательно относись к значениям, которые модель назвала «очевидными»: они часто основаны на типовом продукте, а не на твоём контракте.

Параметры: role={manager,lead}; status={new,won,lost}; action={view,edit,convert}.
Построй decision table. Отдельно отметь запрещённые комбинации.
После таблицы предложи минимальный набор тестов и объясни, какое правило покрывает каждый тест.

4. Проверяй сгенерированные API, SQL и автотесты запуском

Синтаксически правдоподобный код может обращаться к несуществующей колонке, путать LEFT JOIN с INNER JOIN или проверять только status 200. Перед генерацией дай минимальную схему и контракт. После неё прочитай запрос, запусти на контролируемых данных и заранее вычисли ожидаемый результат. Для destructive SQL используй тестовую БД и транзакцию.

В автотестах проверь локаторы, ожидания, очистку данных и диагностические артефакты. AI часто создаёт sleep, длинные цепочки зависимых тестов и CSS-селекторы, привязанные к вёрстке. Полезный результат должен проходить несколько повторов, падать по ожидаемой причине при намеренной поломке и оставлять trace, request или screenshot.

-- Сначала сформулируй expected: customer 3 и 4
SELECT c.id
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL
ORDER BY c.id;
-- Затем добавь заказ customer 3 и ожидай только customer 4

5. Не отправляй модели секреты и пользовательские данные

Production-логи, токены, cookies, приватные URL, персональные данные и внутренний код могут нарушить правила компании и договоры. До отправки минимизируй контекст: замени имена и email синтетическими, маскируй credentials, оставь только нужные поля request/response. Одной замены имени недостаточно, если набор полей всё ещё идентифицирует человека.

Уточни, какие модели и режимы разрешены организацией, как используются данные, где они хранятся и можно ли отключить обучение. Для чувствительной задачи безопасным результатом иногда будет не промпт, а локальное описание проблемы без исходных данных. Prompt injection из логов или документов также считается недоверенным вводом.

• Bearer token, cookie и API key удалены.
• PII заменены синтетическими данными.
• Внутренние адреса и идентификаторы обобщены.
• Передан минимальный фрагмент, а не полный дамп.
• Использование модели соответствует политике команды.

6. Оценивай ответ по рубрике и сохраняй происхождение

Для повторяющихся задач создай рубрику: корректность относительно источника, полнота рисков, отсутствие выдумок, исполнимость, безопасность и диагностичность. Оценка «выглядит хорошо» не обнаружит неверный статус-код или пропущенное право доступа. Спорные пункты помечай до уточнения, а не превращай в тест с выдуманным expected.

Сохраняй версию требования, существенный промпт, модель или инструмент, дату, отредактированный результат и способ проверки. Это не бюрократия: после изменения продукта становится понятно, почему появился тест и что нужно пересмотреть. Не публикуй сырой AI-текст как документацию без владельца и review.

Correctness: каждое expected связано с источником
Coverage: роли, состояния, границы, интеграции и ошибки
Evidence: запрос можно выполнить, результат наблюдаем
Safety: секретов и PII нет
Maintainability: нет дублей, понятны данные и приоритет

7. Внедряй AI в команду через маленький измеримый эксперимент

Не начинай с правила «все задачи теперь делаем с AI». Выбери один повторяемый процесс, например review acceptance criteria или подготовку API test ideas. Собери baseline без AI: время, число полезных вопросов, ошибки после review. Затем проведи несколько итераций с единым шаблоном и той же рубрикой качества.

Запиши границы: какие данные разрешены, кто подтверждает результат, где хранится provenance и когда нужно отказаться от модели. Успешный пилот должен улучшать проверенный итог, а не количество сгенерированных строк. После пилота команда решает, стандартизировать шаблон, изменить его или закрыть эксперимент.

Use case: review acceptance criteria
Baseline: 20 stories без AI
Pilot: 20 сопоставимых stories с шаблоном
Metrics: время review, принятые вопросы, ошибки, утечки=0
Owner: QA lead; review: analyst
Decision date: после 40 stories

8. Как рассказать об AI на собеседовании QA

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

Будь готов объяснить ограничения: hallucination, устаревшие знания, nondeterminism, утечки данных, prompt injection и automation bias. Для Middle-уровня добавь способ командного контроля: шаблон промпта, рубрику review, набор eval-кейсов и правила, где AI запрещён или требует второго проверяющего.