Как тестировщику работать с Claude: рабочий процесс, а не игрушка

Большинство тестировщиков открывают Claude, задают вопрос вроде «напиши тест-кейсы для логина», копируют ответ и разочаровываются: получилось поверхностно. Проблема не в модели, а в подходе. Claude — не поисковик и не генератор текста. Это младший коллега, который знает много, работает быстро, но ничего не знает про ваш продукт, пока вы не расскажете.

Разберём, как встроить его в реальный QA-процесс.

Что Claude реально закрывает

Сильные стороны — там, где нужно быстро переработать много текста и структуры:

Генерация тест-кейсов и чек-листов из требований, описания фичи или скриншота.
Разбор логов и stacktrace — быстро найти аномалию, сгруппировать похожие ошибки, объяснить незнакомое исключение.
Ревью тест-плана и требований — найти дыры, противоречия, невалидные допущения.
Черновики баг-репортов из сырых заметок — превратить «сломалось при оплате картой» в структурированный тикет с шагами.
Тестовые данные — граничные значения, невалидные входы, edge-кейсы для дат, денег, юникода.
Автотесты — каркас Page Object, перевод ручного кейса в Playwright/Selenium, объяснение чужого кода.
Рутинный текст — release notes, сообщение стейкхолдерам, перевод чек-листа на английский.

Что он закрывает плохо

Реальное поведение вашей системы. Он не знает, что кнопка «Оплатить» дизейблится через 3 секунды. Он предполагает.
Актуальность фактов — версии SDK, API, лимиты сторов меняются; проверяйте.
Числа и подсчёты без данных — не спрашивайте «сколько кейсов нужно», спрашивайте «какие сценарии я упустил».
Ответственность. Финальное решение о качестве — на вас, не на модели.

Контекст решает всё

Разница между мусором и пользой — в контексте. Сравните два запроса:

Плохо: «Напиши тест-кейсы для формы регистрации».

Хорошо: «Мобильное приложение банка, форма регистрации: телефон + SMS-код + пароль. Есть биометрия на втором шаге. Пароль 8+ символов, одна цифра. Регион — РФ и Казахстан. Дай тест-кейсы, сгруппируй по: валидация полей, безопасность, локализация, сеть/оффлайн. Формат — таблица: шаги / ожидаемый результат».

Второй ответ будет в разы точнее, потому что модель знает домен, ограничения и нужный формат. Правило: если бы новый стажёр не смог сделать задачу с вашим текстом — Claude тоже не сможет.

Рабочий процесс, а не «спроси-скопируй»

Один запрос редко даёт финал. Работает итеративный цикл:

Дай контекст — продукт, фича, ограничения, что уже протестировано.
Поставь задачу узко — не «протестируй оплату», а «дай негативные кейсы для оплаты картой при плохой сети».
Проси встречные вопросы — «прежде чем отвечать, задай мне 3 уточняющих вопроса». Это резко поднимает качество.
Критикуй ответ — «кейсы 4 и 7 дублируются, добавь сценарии с истёкшей картой».
Фиксируй формат — таблица, JSON, Gherkin. Модель отлично держит структуру.

Где не доверять

Всё, что касается фактов и чисел — перепроверяйте (версии, лимиты, ссылки).
Сгенерированный код — запускайте, не коммитьте вслепую. Особенно селекторы и ассерты.
«Уверенный» тон — модель звучит убедительно, даже когда ошибается. Уверенность ≠ правота.
Приватные данные — не вставляйте реальные учётки, токены, персональные данные пользователей.

Итог

Claude не заменяет тестировщика — он убирает рутину, чтобы вы занимались тем, что действительно требует головы: рисками, приоритетами, нестандартными сценариями. Относитесь к нему как к быстрому младшему коллеге: дайте контекст, поставьте узкую задачу, проверьте результат. Тогда он экономит часы, а не создаёт иллюзию работы.

Конкретные шаблоны промптов — в отдельной шпаргалке по промптам для QA.