Содержание
Готовые шаблоны промптов
Шаблоны — это промпты, которые ты адаптируешь под свой проект. Скопировал, заменил плейсхолдеры в квадратных скобках, отправил Claude. База — формула контекста из первой части и ежедневные сценарии из второй.
Шаблон: тест-кейсы
Я тестирую: [описание фичи]
Платформа: [web / mobile / API]
Пользователь: [роль пользователя]
Ограничения: [лимиты, валидации, бизнес-правила]
Напиши тест-кейсы в формате таблицы:
ID | Тип | Название | Предусловия | Шаги | Ожидаемый результат | Приоритет
Типы: позитивный / негативный / граничный / безопасность
Приоритет: high / medium / low
Минимум 15 тест-кейсов.
Шаблон: баг-репорт
Оформи баг-репорт для Jira из описания:
[Что произошло — свободный текст, можно как угодно]
Формат:
- Заголовок (кратко, конкретно, начинается с глагола)
- Severity: blocker / critical / major / minor
- Шаги воспроизведения (пронумерованные)
- Ожидаемый результат
- Фактический результат
- Окружение: браузер, ОС, окружение
- Частота: всегда / иногда / один раз
- Workaround (если есть)
Шаблон: чеклист по фиче
Создай чеклист тестирования для: [описание фичи/страницы]
Категории:
- [ ] Функциональность (основной сценарий, альтернативные)
- [ ] Валидация (обязательные поля, форматы, лимиты)
- [ ] UI/UX (отображение, состояния, адаптивность)
- [ ] Безопасность (доступ, инъекции, чужие данные)
- [ ] Производительность (большие данные, множественные клики)
Шаблон: регрессионный чеклист
Создай чеклист регрессии для релиза.
Что изменилось: [список задач/PR из спринта]
Модули системы: [перечисли основные модули]
Для каждого затронутого модуля:
- [ ] Smoke-тест (основной сценарий работает)
- [ ] Связанные модули (что могло сломаться)
- [ ] Критичные сценарии (оплата, регистрация, авторизация)
Расставь приоритет: что проверять первым.
Шаблон: тест-план
Составь тест-план для фичи: [описание]
Включи:
1. Scope — что тестируем и что НЕ тестируем
2. Подход — виды тестирования (функциональное, UI, API, безопасность)
3. Окружения — где тестируем
4. Тест-кейсы — сколько, какие типы
5. Критерии входа/выхода
6. Риски — что может пойти не так
7. Расписание — примерные сроки
Шаблон: тестовые данные
Сгенерируй тестовые данные для [форма/API/таблица].
Поля: [перечисли поля и их типы]
Ограничения: [длина, формат, обязательность]
Нужно:
- 5 полностью валидных наборов
- 5 с невалидными данными (разные ошибки)
- 5 с граничными значениями
- 3 для проверки безопасности (XSS, SQL-инъекции)
Формат: [таблица / JSON / CSV / SQL INSERT]
Адаптация под свой проект
Перед использованием шаблона добавь контекст проекта в начало:
Контекст: я тестирую мобильное приложение для доставки еды.
Платформы: iOS 16+, Android 12+.
Пользователи: клиент, курьер, ресторан, админ.
Критичные модули: оформление заказа, оплата, трекинг.
[далее шаблон]
Чем больше контекста — тем точнее результат.
Работа с документацией
Из ТЗ — тестируемые требования
У тебя документ на 10 страниц. Вместо того чтобы читать и выписывать самому:
Вот техническое задание (или вставь текст).
Выдели все тестируемые требования. Для каждого:
- ID требования
- Формулировка
- Тип проверки (функциональная / UI / производительность / безопасность)
- Приоритет (high / medium / low)
- Можно ли автоматизировать (да / нет)
Матрица трассировки
Вот список требований:
REQ-01: Пользователь может зарегистрироваться по email
REQ-02: Пользователь может войти по email + пароль
REQ-03: Сброс пароля через email
[...]
Создай матрицу трассировки:
Требование | Тест-кейсы | Покрытие | Статус
Подготовка к релизу
Smoke-тест
Создай чеклист smoke-тестирования для [название проекта].
Основные модули: [перечисли]
Для каждого модуля — 2-3 самых критичных проверки.
Весь smoke-тест должен занять не больше 30 минут.
Staging vs Production
Создай чеклист проверок ПОСЛЕ деплоя на production:
- Сайт открывается
- SSL-сертификат валиден
- Авторизация работает
- Основной бизнес-процесс проходит
- Платёжная система работает (тестовый платёж)
- Email-уведомления отправляются
- Логи без критических ошибок
Go/No-Go
Вот результаты тестирования перед релизом:
- Всего тест-кейсов: 120
- Passed: 112
- Failed: 5 (minor: 3, major: 2)
- Blocked: 3
- Открытые баги: 2 major, 3 minor
Дай рекомендацию: Go или No-Go?
Объясни почему. Какие риски при релизе?
Отчётность
Summary для менеджера
Напиши summary тестирования для менеджера проекта.
Язык: простой, без технических деталей.
Данные:
- Спринт: Sprint 14
- Задачи: [список]
- Тестов выполнено: 85
- Найдено багов: 12 (2 critical, 4 major, 6 minor)
- Блокеры: оплата не работает в Firefox
- Регрессия: без проблем
Формат: 5-7 предложений, ключевые выводы и рекомендации.
Анализ багов
Вот список багов за последние 3 спринта:
[вставь список]
Найди паттерны:
- Какой модуль самый багованный?
- Какой тип багов самый частый?
- Есть ли тренд — становится лучше или хуже?
- Где нужно усилить тестирование?
Кроссбраузерное, мобильное, доступность
Кроссбраузерное тестирование
Создай чеклист кроссбраузерного тестирования для [страница/фича].
Браузеры: Chrome, Firefox, Safari, Edge (последние 2 версии).
Разрешения: 1920x1080, 1366x768, 375x812 (iPhone), 360x800 (Android).
Что проверять в каждом браузере:
- Вёрстка не сломана
- Шрифты отображаются
- Формы работают
- Анимации плавные
- Модальные окна корректны
Специфика мобильных
Какие специфичные баги бывают:
1. В iOS Safari (последняя версия)
2. В Android Chrome
3. В мобильных WebView (приложения)
Для каждого: конкретный пример бага и как проверить.
Доступность (WCAG)
Создай чеклист доступности по WCAG 2.1 (уровень AA) для [страница].
Категории:
- Контрастность текста
- Клавиатурная навигация
- Screen reader (alt-тексты, aria-labels)
- Фокус (видимый, логичный порядок)
- Формы (связь label-input, сообщения об ошибках)
- Медиа (субтитры, управление)
Локализация
Чеклист для тестирования локализации:
- RTL-языки (арабский, иврит): вёрстка не сломана?
- Длинные строки (немецкий): текст не обрезается?
- Форматы дат: DD.MM.YYYY vs MM/DD/YYYY
- Форматы чисел: 1.000,50 vs 1,000.50
- Валюты: символ до/после числа
- Спецсимволы в именах: Ö, ñ, 日本語
Рост и развитие
Claude как ментор
Объясни простым языком, что такое boundary value analysis.
Приведи пример для поля "Возраст" (от 18 до 65).
Какие значения тестировать и почему?
Чем отличается smoke-тестирование от regression-тестирования?
Когда использовать каждое? Приведи примеры из реального проекта.
Подготовка к собеседованию
Задай мне 10 вопросов как на собеседовании на QA Middle.
После каждого моего ответа — скажи, что хорошо и что дополнить.
Темы: тест-дизайн, API, SQL, процессы, баг-трекинг.
Первые шаги в автоматизацию
Даже если ты не программист, Claude поможет понять:
Напиши простой автотест на Python + Selenium для сценария:
1. Открыть сайт example.com
2. Ввести логин и пароль
3. Нажать "Войти"
4. Проверить что открылась главная страница
Объясни каждую строку как для человека, который никогда не программировал.
Ты не обязан автоматизировать прямо сейчас. Но понимание того, как это работает, делает тебя ценнее.
В следующей части — твой первый контакт с репозиторием проекта. Не пугайся: код будет читать Claude, не ты.
Обсуждение
Пока нет комментариев. Будьте первым.