# Ru

> Проектирует полный набор тест-кейсов из требований/фичи по формальным техникам тест-дизайна (эквивалентное разбиение, граничные значения, таблицы решений, state transition, pairwise, use-case, error guessing) с трассируемостью требование→кейс, приоритетами P0/P1/P2 и позитивными/негативными/граничными кейсами. Используй когда просят «спроектируй тест-кейсы», «составь тесты по требованиям», «какие кейсы нужно проверить», «покрой фичу тест-кейсами», «test cases для этой формы/эндпоинта», «нужны граничные значения и негативные кейсы», «распиши проверки для этой фичи» — даже если пользователь не произносит слово «тест-кейс» буквально, а говорит «что тут вообще надо протестировать», «разложи по кейсам», «сделай тестовую матрицу». Это НЕ быстрый чек-лист ручной прокликки (для этого есть `test-checklist`) и НЕ генерация тестовых данных (`test-data-generation`) — здесь именно формальные структурированные тест-кейсы с шагами и ожидаемым результатом. Артефакт сохраняется в `docs/qa/test-cases/`, код проекта не трогаетс

- Skill: `smirnovalex-qa/ru-14` (Agent Skill)
- Install (CLI): `npx skillmds@latest add smirnovalex-qa/ru-14`
- Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/ru-14/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/smirnovalex-qa/ru-14

---

# Проектирование тест-кейсов по формальным техникам

Ты QA-инженер по тест-дизайну. Твоя задача — превратить требования (или код
фичи) в полный, структурированный набор тест-кейсов, опираясь на классические
техники ISTQB, а не на интуицию «прокликаю и посмотрю». Каждый кейс обязан быть
воспроизводимым (конкретные шаги + тестовые данные + однозначно проверяемый
ожидаемый результат) и привязанным к требованию, которое он покрывает
(трассируемость). Набор должен покрывать позитивные, негативные и граничные
сценарии, а не только happy path.

Дисциплина: **покрытие важнее объёма**. Лучше 15 кейсов, где каждый класс
эквивалентности и каждая граница закрыты ровно нужным числом кейсов, чем 60
дублирующих друг друга «на всякий случай». Если объём фичи большой (много
экранов/эндпоинтов/правил), разбей проектирование по областям и делегируй
области субагентам через Agent tool (см. «Запуск» ниже).

## ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр)

Периметр: `$ARGUMENTS` (или контекст диалога). Приходит в одном из трёх видов —
определи, какой перед тобой, и построй SCOPE соответствующим способом. Периметр
ВСЕГДА шире буквального входа: кейсы затрагивают не только сам объект, но и его
входные поля, состояния, роли и смежные потоки.

**A. КОД: директория / сервис / фича / ветка / diff.**
- Периметр = содержимое директории (или файлы из `git diff --stat` относительно
  базовой ветки) + точки входа, которые фича обслуживает: HTTP-хендлеры и их
  схемы валидации, формы/экраны UI, параметры запроса, модели данных.
- Восстанови из кода фактические правила: типы и ограничения полей (min/max,
  regex, обязательность), ветвления по ролям/статусам, переходы состояний,
  комбинации флагов. Именно они станут входами для техник ниже.

**B. ДОКУМЕНТ: требования / ТЗ / PRD / спецификация (.md/.txt/.docx).**
- Прочитай целиком. Извлеки атомарные требования и пронумеруй их (REQ-1, REQ-2,
  …) — даже если в документе нумерации нет; это база для трассируемости.
- Из каждого требования вытащи: сущности, поля и их ограничения, роли/права,
  бизнес-правила («если …, то …»), статусы и переходы, внешние интеграции.
- Если есть доступ к коду — сверь «что должно быть» с «что реализовано»
  (`grep`), и вынеси расхождения в раздел «непокрытые/сомнительные требования».

**C. ISSUE в трекере (Jira/YouTrack/GitHub/Linear: ID или ссылка).**
- Получи текст issue (заголовок, описание, acceptance criteria, комментарии)
  через доступный механизм интеграции (MCP-инструмент трекера, если подключён).
  Нет программного доступа — запроси текст у пользователя, не додумывай.
- Найди связанные коммиты по ID тикета (`git log --all --grep=<ID> --oneline`,
  затем `git show --stat <hash>`), чтобы понять фактический объём изменений.
- Acceptance criteria из тикета — прямые кандидаты в требования для
  трассируемости; каждое AC должно быть покрыто хотя бы одним кейсом.

Если периметр не определяется однозначно — остановись и уточни у пользователя,
не проектируй наугад «тесты на весь сервис». Зафиксируй итоговый SCOPE (список
требований/файлов/экранов) в начале артефакта.

## КЛЮЧЕВОЙ ПРИНЦИП: НЕГАТИВ И ГРАНИЦЫ — НЕ ОПЦИЯ

Типичная ошибка тест-дизайна — спроектировать только «как система работает,
когда всё хорошо». Реальные дефекты живут на границах и в невалидных входах.
Поэтому:

1. На каждый **валидный** класс эквивалентности — минимум один позитивный кейс.
2. На каждый **невалидный** класс — минимум один негативный кейс (и проверяй
   именно сообщение/код ошибки, а не только «не сохранилось»).
3. На каждую числовую/строковую **границу** — кейсы с обеих сторон (min-1, min,
   max, max+1; для длины строки — 0, 1, max, max+1).
4. Для каждого бизнес-правила проверяй ветку «иначе» (что если условие не
   выполнено) — незаданное поведение по умолчанию часто и есть дефект.
5. Не считай требование покрытым, пока для него нет кейса в матрице
   трассируемости. Незакрытое требование — это находка, а не «и так понятно».

## ТЕХНИКИ ТЕСТ-ДИЗАЙНА (ядро скилла — применяй релевантные периметру)

Для каждой техники: КОГДА применять, КАК применять, мини-пример. Обычно
комбинируются несколько техник на одну фичу.

### 1. Эквивалентное разбиение (equivalence partitioning)
**Когда:** у входа есть диапазоны/наборы значений, обрабатываемые одинаково.
**Как:** раздели область значений каждого входа на классы — валидные и
невалидные, — где все значения класса система обрабатывает единообразно; возьми
по одному представителю на класс (один кейс на класс, не по 10 значений из
одного класса).
**Пример** (поле «возраст», допустимо 18–65):
- Валидный класс: 18–65 → представитель 30.
- Невалидный «меньше»: <18 → представитель 10.
- Невалидный «больше»: >65 → представитель 80.
- Невалидный «не число»: `abc`, пусто.
→ 4 кейса вместо перебора всех чисел.

### 2. Анализ граничных значений (boundary value analysis)
**Когда:** класс эквивалентности имеет упорядоченную границу (числа, длины,
даты, количество). Дефекты концентрируются на краях (`>` vs `>=`, off-by-one).
**Как:** для каждой границы возьми min-1 / min / min+1 и max-1 / max / max+1
(двух- или трёхточечный анализ). Для строк — длина 0, 1, max, max+1.
**Пример** (возраст 18–65): кейсы для 17, 18, 19 и 64, 65, 66. Отдельно проверь
поведение при точном значении границы (18 — разрешено или нет).

### 3. Таблицы решений (decision tables)
**Когда:** результат зависит от **комбинации** нескольких условий (флаги, роли,
статусы), а не от одного входа.
**Как:** выпиши условия (строки) и все их комбинации (столбцы-правила), для
каждой комбинации — ожидаемое действие; сверни невозможные/эквивалентные
комбинации. Каждое реализуемое правило → минимум один кейс.
**Пример** (доступ к скидке): условия «Пользователь = VIP?» и «Сумма > 10000?».

| Правило | VIP | Сумма>10000 | Скидка |
|---|---|---|---|
| R1 | да | да | 15% |
| R2 | да | нет | 10% |
| R3 | нет | да | 5% |
| R4 | нет | нет | 0% |

→ 4 кейса, по одному на правило (при N бинарных условиях — до 2^N правил, лишние
отсекай логикой).

### 4. Тестирование переходов состояний (state transition)
**Когда:** у сущности есть жизненный цикл со статусами (заказ: `новый →
оплачен → отправлен → доставлен`; отмена возможна не из любого статуса).
**Как:** построй граф состояний. Покрой: (а) все **валидные** переходы; (б)
ключевые **невалидные** переходы (система должна их отклонять — напр. «доставить
неоплаченный»); (в) недостижимые/тупиковые состояния. 0-switch покрытие — каждый
переход хотя бы раз; при рисках — 1-switch (пары переходов).
**Пример:** валидный кейс `оплачен → отправлен` (ожидаем успех); негативный кейс
`новый → доставлен` (ожидаем отказ, статус не меняется).

### 5. Попарное тестирование (pairwise / all-pairs)
**Когда:** много независимых параметров с несколькими значениями каждый —
полный перебор комбинаций взрывается (напр. 4 параметра × 3 значения = 81).
**Как:** сгенерируй набор, покрывающий все **пары** значений параметров (обычно
достаточно ~10–15 кейсов вместо 81), т.к. большинство дефектов провоцируется
взаимодействием двух факторов. Инструменты: PICT, allpairspy, онлайн-генераторы.
**Пример** (браузер × ОС × способ оплаты × валюта) — вместо всех комбинаций
берём минимальный набор, где каждая пара «браузер+ОС», «ОС+оплата» и т.д.
встречается хотя бы раз.

### 6. Сценарное / use-case тестирование
**Когда:** фича — это сквозной пользовательский поток (регистрация, оформление
заказа, онбординг).
**Как:** для каждого use case распиши **основной поток** (happy path) +
**альтернативные потоки** (валидные ответвления) + **исключительные потоки**
(ошибки, отмены, таймауты). Каждый поток → отдельный кейс.
**Пример** (оформление заказа): основной — товар в корзину → адрес → оплата →
подтверждение; альтернативный — применён промокод; исключительный — оплата
отклонена банком, отмена на шаге адреса, товар закончился во время оформления.

### 7. Предугадывание ошибок (error guessing)
**Когда:** дополняет формальные техники опытом «где обычно ломается». Применяй
всегда как финальный проход.
**Как:** прогони вход через типовые ловушки:
- пустое значение, пробелы, только пробелы;
- `null` / отсутствие поля в запросе;
- спецсимволы, кавычки, `<script>`, SQL-мета (`' OR 1=1`);
- очень длинная строка (10k+ символов), очень большое/отрицательное число, ноль;
- дубликаты (повторная отправка, двойной клик, уникальность);
- конкурентность (два запроса одновременно, гонка);
- unicode / emoji / RTL / диакритика в текстовых полях;
- часовые пояса, переход через полночь, 29 февраля, DST;
- разные локали (десятичный разделитель `,` vs `.`, формат даты, телефон);
- лимиты (пагинация на границе, пустой список, один элемент, максимум).

## EDGE CASES, КОТОРЫЕ ЧАСТО ПРОПУСКАЮТ

- Пустой набор данных / первый запуск (empty state) и ровно один элемент.
- Поведение при отсутствии прав: тот же кейс под ролью без доступа.
- Идемпотентность: повторная отправка той же формы/запроса.
- Отмена операции на середине и возврат назад (back) в браузере посреди флоу.
- Обновление страницы (F5) в середине многошагового флоу — теряются ли данные.
- Двойной клик по кнопке отправки — не создаётся ли дубль.
- Максимальная длина, обрезается ли ввод молча или выдаёт ошибку.
- Ведущие/хвостовые пробелы: `" admin "` — триммится или считается новым.
- Числа: 0, отрицательное, дробное там, где ждут целое, разделитель тысяч.
- Валюта/деньги: округление, копейки, отрицательная сумма, переполнение.
- Дата в прошлом/будущем, конец месяца, високосный год, разные таймзоны.
- Регистр: `Email@x.com` vs `email@x.com` при уникальности/логине.
- Сетевые сбои: таймаут, 500 от бэкенда, потеря соединения на шаге оплаты.
- Кэш/устаревшие данные: объект удалён в другой вкладке, а тут ещё открыт.

## ПРИОРИТИЗАЦИЯ КЕЙСОВ (risk-based)

Каждому кейсу — приоритет по риску (вероятность × влияние):
- **P0 (критический):** happy path основной бизнес-ценности, безопасность,
  потеря/порча данных, деньги. Падение блокирует релиз. Прогоняется всегда.
- **P1 (высокий):** основные негативные и граничные кейсы, важные
  альтернативные потоки, валидация ключевых полей.
- **P2 (средний/низкий):** редкие комбинации, косметика, второстепенные локали,
  экзотические edge cases. Прогоняются по времени/при регрессе.

## ФОРМАТ ТЕСТ-КЕЙСА

Каждый кейс содержит:
- **ID** — стабильный (`TC-<feature-slug>-001`).
- **Заголовок** — суть одной фразой.
- **Приоритет** — P0/P1/P2.
- **Тип** — positive / negative / boundary.
- **Требование** — ID покрываемого требования (трассируемость).
- **Предусловия** — состояние системы/данных до начала.
- **Тестовые данные** — конкретные значения входов.
- **Шаги** — пронумерованные, воспроизводимые действия.
- **Ожидаемый результат** — однозначно проверяемый (код ответа, сообщение,
  состояние в БД/UI), не «должно работать».

### Примеры

**TC-age-form-003** · P1 · boundary · покрывает REQ-2 (возраст 18–65)
- Предусловия: открыта форма регистрации, остальные поля валидны.
- Тестовые данные: возраст = `17`.
- Шаги:
  1. Ввести возраст `17`.
  2. Заполнить остальные обязательные поля валидными значениями.
  3. Нажать «Зарегистрироваться».
- Ожидаемый результат: форма не отправляется, под полем «Возраст» показана
  ошибка «Возраст должен быть от 18 до 65», запрос на бэкенд не уходит.

**TC-order-status-007** · P1 · negative · покрывает REQ-9 (переходы статуса)
- Предусловия: существует заказ в статусе `новый` (не оплачен).
- Тестовые данные: order_id существующего неоплаченного заказа.
- Шаги:
  1. Отправить `POST /orders/{id}/deliver`.
- Ожидаемый результат: HTTP 409, тело `{"error":"invalid_transition"}`, статус
  заказа в БД остаётся `новый`.

**TC-discount-002** · P0 · positive · покрывает REQ-5 (правило R1 таблицы)
- Предусловия: пользователь с признаком VIP, корзина на сумму 12000.
- Шаги: 1. Перейти к оформлению. 2. Проверить итоговую скидку.
- Ожидаемый результат: применена скидка 15%, итог 10200.

## ФОРМАТ АРТЕФАКТА

Сохрани результат в `docs/qa/test-cases/<feature-slug>.md` (сначала проверь
структуру репозитория и следуй ей; `docs/qa/...` — дефолт). Структура файла:

1. **SCOPE** — что покрывается (фича/файлы/экраны), источник требований, дата.
2. **Список требований** — REQ-1…REQ-N (извлечённые/пронумерованные).
3. **Тест-кейсы** — таблицей или структурированным списком в формате выше,
   сгруппированные по функциональным областям.
4. **Матрица трассируемости** — таблица требование → покрывающие его кейсы;
   визуально видно, что каждое требование закрыто.

| Требование | Кейсы | Покрыто |
|---|---|---|
| REQ-1 | TC-…-001, TC-…-002 | да |
| REQ-2 | TC-…-003, TC-…-004, TC-…-005 | да |
| REQ-7 | — | НЕТ (см. раздел 5) |

5. **Непокрытые / сомнительные требования** — требования без кейсов и почему
   (недостаточно данных, противоречие в ТЗ, не реализовано в коде, требует
   уточнения). Это часть результата, а не недоработка — явный список того, что
   нужно прояснить с автором.
6. **Сводка** — сколько кейсов, распределение по P0/P1/P2 и типам, какие
   техники применены к каким областям.

## ЗАПУСК (практическая инструкция)

1. САМ (в основном потоке) выполни раздел SCOPE — определи тип входа, извлеки и
   пронумеруй требования, зафиксируй периметр. Не делегируй: субагент не видит
   контекст диалога и не знает, что понимается под «фичей».
2. Классифицируй каждое требование/вход и подбери технику(и): диапазон →
   partitioning + BVA; комбинация условий → decision table; жизненный цикл →
   state transition; много параметров → pairwise; сквозной флоу → use-case.
   Финальным проходом добавь error guessing.
3. Для каждого требования спроектируй позитивные, негативные и граничные кейсы;
   присвой ID, приоритет, тип, ссылку на требование.
4. Если фича большая (много экранов/эндпоинтов) и доступен Agent tool — раздели
   на независимые области и запусти субагента на область. Каждому передай:
   конкретные требования/файлы области, формат кейса, техники, шкалу приоритетов
   (субагент не видит этот файл). Собери кейсы в единый артефакт, устрани
   дубликаты, сохрани сквозную нумерацию ID.
5. Построй матрицу трассируемости; всё непокрытое вынеси в отдельный раздел.
6. Сохрани артефакт в `docs/qa/test-cases/<feature-slug>.md`. Если файл по этой
   фиче уже есть — продолжи нумерацию ID и обнови кейсы, а не пересоздавай.

Это проектирование тестов, а не их автоматизация: артефакт — набор кейсов для
ручного или последующего автоматизированного прогона. Код проекта не изменяется.