Claude для тестировщика: 10 реальных сценариев и промпты

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

Дальше — 10 конкретных сценариев, где Claude реально экономит часы, с примерами промптов и реалистичными ожиданиями. Применимо к любой LLM (ChatGPT, Gemini), но Claude чаще выигрывает в задачах с длинным контекстом и точностью.

1. Генерация тест-кейсов из требований

Самый прямой use-case. На входе — текст требования, юзер-стори или Jira-описание. На выходе — структурированный набор позитивных, негативных и edge-case кейсов.

Я QA-инженер. Прочитай требование ниже и сгенерируй чек-лист тест-кейсов: позитивные, негативные, граничные, security. Для каждого кейса — название, шаги, ожидаемый результат. Формат: markdown table. <требование>

Качество сильно зависит от полноты требования. Пустяковое «должен работать поиск» даст шаблонные кейсы. Подробное «поиск по имени и фамилии, нечувствителен к регистру, поддерживает 2-30 символов, exact и partial match» — получишь 40+ конкретных кейсов с пограничными значениями.

**Совет: **перед генерацией всегда давайте модели «контекст» — что за продукт, какая платформа, какие ограничения. Без этого она генерит generic-кейсы, не учитывающие, что у вас, скажем, моб. игра без клавиатуры.

2. Разбор багов и стектрейсов

Вы видите exception в логе — Claude помогает быстро понять, что вообще произошло, и как могло прийти к этой точке. Особенно полезно с незнакомой технологией (Unity, Cocoa, Android internals).

Объясни, что означает этот stacktrace и какие могут быть причины. Я QA, разбираюсь в high-level логике, но не глубоко в Unity internals.

Дальше можно итеративно: «А если входной index был 0, мог ли он попасть в эту ветку?», «Какие тесты помогли бы это поймать раньше?» — модель неплохо рассуждает в диалоге.

3. Генерация тест-данных

Особенно сильно на boundary values, валидные/невалидные строки, locale-specific edge cases.

Сгенерируй 30 строк для тестирования поля “email”: валидные (включая edge-cases типа plus-addressing, IDN, длинных), невалидные с разными типами ошибок, потенциально-опасные (SQL injection, XSS, path traversal). Формат: CSV с колонками email,expected_result,why.

Не забудьте проверить генерацию руками. Модель иногда упускает редкие, но валидные кейсы (например, email c quoted local-part).

4. Локализация: плюрализация и edge cases

Если в продукте 5+ языков — Claude хорошо находит проблемные кейсы. «Покажи мне все формы числа N для русского / польского / арабского» → получишь готовые таблицы с правилами CLDR.

Я тестирую локализацию игры в RU/EN/DE/AR. Для каждого языка покажи: 1) сколько форм plural и какие; 2) какие числа triggerят редкие формы; 3) типичные баги локализации в этих языках, которые легко пропустить. Дай контрпример для каждого.

Также: «Сгенерируй 10 строк на немецком разной длины — короткие, средние, длинные compounds — для тестирования UI overflow.» Получите готовые Bestätigung, Geschwindigkeitsbegrenzungseinrichtung и подобное.

5. Превращение бага в нормальный bug-report

У вас есть кривое «оно не работает, тапаешь — ничего» от продакта. Claude помогает структурировать:

Перепиши этот сырый баг-репорт в нормальный с разделами Steps to Reproduce, Expected, Actual, Environment, Severity. Не выдумывай детали, которых нет в исходном тексте — отметь то что нужно уточнить. <сырой текст>

Реально экономит время, особенно если в день оформляешь 5-10 тикетов.

6. Помощь с регулярками, JQL, XPath

Это область, где LLM работает почти на 10/10. «Напиши regex для проверки RFC 5322 email» / «JQL для всех багов в SH за последние 2 недели, не закрытых, без assignee» / «XPath к 3-й кнопке внутри div с классом dialog__actions» — получите за секунду.

Полезно проверять на boundary cases. Особенно регулярки на email и URL — это два «проклятых» примера, где даже LLM иногда промахивается.

7. Сравнение API-ответов и логов между билдами

Закинули два JSON-ответа от одного endpoint (билд 1.5 и 1.6) — попросили показать diff с интерпретацией.

Это JSON-ответ /api/levels из билдов 1.5 и 1.6. Покажи семантические отличия (не форматирование). Что могло сломаться у клиента, если он не ожидал этих изменений?

Особенно полезно при contract-testing на пути «бекенд изменил поле — клиент об этом не узнал».

8. Анализ скриншотов UI на тест-кейсы

Современные Claude-модели работают с картинками. Кидаете скриншот экрана из приложения — модель описывает что на нём, выдаёт список тест-кейсов.

Я QA, смотрю на этот экран мобильной игры. Сгенерируй список тест-кейсов: что проверить визуально, функционально, на разных размерах экрана, в разных локалях, на разных permission states. <скриншот>

Особенно полезно для regression-чек-листов экранов, которые делает дизайнер. Дизайн → 30 кейсов за минуту.

9. Написание автотестов

Selenium, Playwright, Appium, pytest — модель пишет тесты по описанию сценария. Не «всё под ключ», но скелет получаете за минуты.

Напиши Playwright-тест на TypeScript для следующего сценария: открыть login, ввести email и password, тап Sign In, проверить redirect на /dashboard, проверить welcome-баннер. Используй web-first assertions, без waitForTimeout.

Если у вас уже есть Page Object паттерн — можно скормить модели один пример и попросить генерить новые тесты в том же стиле. Это работает удивительно хорошо.

10. Объяснение незнакомых технологий

QA часто работает на пересечении технологий — сегодня iOS, завтра Kafka, послезавтра gRPC. Claude хорошо объясняет концепции «на пальцах», без воды.

Объясни мне, QA-инженеру, что такое gRPC и чем отличается от REST. Какие особенности тестирования: что я должен проверять, какие инструменты использовать, на какие подводные камни смотреть.

Не заменяет глубокое изучение — но даёт быстрый bootstrap, после которого можно конкретно гуглить детали.

Что Claude НЕ заменит

Глаза. UI-баги, edge-cases в анимациях, кривые иконки — это про человека за устройством.
Знание продукта. Модель не знает, что в вашей игре «уровень 47» — это особый случай с другим контентом. Контекст должен дать человек.
Доступ к runtime. Модель не может запустить вашу игру, нажать кнопку, проверить сетевой трафик. Это вы делаете.
Креатив за пределами шаблонов. Хитрый exploration test, где надо «думать как сломать» — человек по-прежнему лучше.

Подводные камни и риски

Галлюцинации URL и API. Модель уверенно выдумает endpoint, который не существует. Особенно опасно при работе с конкретными вендорами. Всегда проверять курлом или гуглом.
Устаревшие данные. У модели есть cutoff date. iOS 19 API она может не знать.
Confidential data. Не кидайте в public-LLM реальные логи юзеров, PII, токены. Используйте Enterprise-режим или локальные модели для чувствительного.
Overreliance. Если QA перестаёт думать сам и просто «пихает в Claude» — теряется насмотренность. Используйте как ускоритель, не как замену головы.

Промпт-инжиниринг для QA

Несколько паттернов, которые повышают качество ответа:

Дайте роль: «Ты QA с 10 годами опыта в моб. играх» — модель сильно меняет тон и точность.
Покажите формат: «Ответ в виде markdown-таблицы с колонками X, Y, Z» — гораздо лучше чем пытаться разобрать прозу.
Дайте пример: «Вот один тест в нужном формате — сгенерируй ещё 10 в таком же стиле».
Просите альтернативы: «Дай 3 разных подхода» — отдельный вариант на «critical» делает ответ более продуманным.
Итерируйте: не пытайтесь получить идеал с первого промпта. Уточняйте в диалоге, дополняйте контекст.

Claude Code — отдельная история

Если задачи выходят за «написать текст» и связаны с реальной работой над репозиторием, логами, файлами — есть Claude Code. Это CLI/IDE-инструмент, который умеет читать файлы вашего проекта, запускать команды, открывать тикеты в Jira, дёргать API.

Реальные QA-сценарии где это незаменимо:

Анализ логов в файле: «Прогрепай по ошибкам этот логкат на 50000 строк, сгруппируй по типу, дай top-10 классов проблем».
Массовое создание test-кейсов в TestRail: «Скопируй структуру из проекта A в проект B через API».
Прогон чек-листа по конфигам: «Проверь, что во всех Localizable.strings присутствует ключ error.network».
Сравнение версий: «Что изменилось в файлах remote_config_defaults.json между релизами 1.5 и 1.6?»
Создание Jira-тикетов из результатов теста — связка с Atlassian API.

С чего начать

Откройте claude.ai (или ChatGPT, Gemini — паттерны те же). Возьмите свежую задачу с реальными требованиями. Попробуйте сгенерировать чек-лист тест-кейсов — оцените покрытие.
Заведите личный сборник промптов в Notion / Obsidian / .md-файле. Хороший промпт переиспользуется десятки раз — экономия растёт.
Через неделю-две выберите одну рутинную задачу, которую делаете еженедельно (regression-чек-лист, оформление багов, чтение логов) — формализуйте промпт под неё.
Не пытайтесь автоматизировать всё за раз. Один use-case за раз, до полной интеграции в workflow.