| name | testing |
| description | Универсальный фреймворк тестирования (frontend + backend) — дотошный прогон любой задачи на тестирование с доказательной дисциплиной. Используй, когда нужно протестировать фичу/форму/билд/API/сервис, составить план тестирования, прогнать проверки, провести исследовательское или регрессионное тестирование, найти дефекты. |
| allowed-tools | ["Read","Write","Bash","Glob","Grep","Agent"] |
Мастер-чеклист «как тестировать что угодно» — frontend/UI и backend/сервисы. Доктрина:
- Дотошность по умолчанию. Покрывай всё сам: happy path → негатив → границы → редкие комбинации. Глубина пропорциональна риску, но классы проверок не пропускай.
- Доказательность. Pass/Fail ставится ТОЛЬКО по наблюдённому артефакту (скриншот, ответ сети, лог, дамп БД). Не проверял —
Not tested, помешали — Blocked с причиной. Никаких галлюцинаций и «по логике должно работать».
- Логируй каждое отклонение сразу. Любое расхождение с макетом/требованиями фиксируй немедленно, даже минорное (отступ, копирайт, цвет).
- Цель — заменить ручное тестирование. Надёжность важнее скорости; «не успел/не смог» пишем прямо.
0. Процесс (для любой задачи)
Сбор контекста
- Прочитать тикет целиком: описание, AC/Gherkin, комментарии, вложения, связанные задачи (blocks/relates/epic), компонент, релиз.
- Зафиксировать source of truth для каждого требования (AC → ТЗ/Confluence → Figma → прод-поведение) и приоритет при конфликте.
- Сверить Figma: версия, режим (desktop/mobile/adaptive), states (default/hover/focus/active/disabled/loading/error/empty), варианты компонентов, токены; что в макете vs что «подразумевается».
- Найти существующие ТК (в вашей TMS — Zephyr/TestRail/др.) и автотесты (в репозитории автотестов проекта): переиспользовать, выявить пробелы, не дублировать.
- Снять прод/preprod baseline (как фича работает сейчас — для регрессии и воспроизведения багов на актуальной версии).
- Уточнить окружение: стенд, доступы, тестовые учётки/роли, фиче-флаги, состояние данных, версия билда/коммит.
- Определить интеграции и зависимости: внешние API, платёжки, авторизация, очереди — что мокается, что реально.
- Явно зафиксировать out of scope (нативные приложения, неподдерживаемые браузеры, легаси-флоу).
Анализ требований и вопросы аналитику
- Каждый AC → проверка; каждая проверка → ссылка на AC или явная пометка «доп. эвристика».
- Выявить неоднозначности («должно корректно работать», нет конкретных значений, неуказанные границы, неопределённое поведение при ошибке).
- Расхождения тикет ↔ Figma ↔ прод ↔ доку — НЕ закрывать допущением, выписать вопросом.
- Зафиксировать неопределённое поведение: пустые состояния, ошибки сети/сервера, таймауты, отказ интеграции, параллельные действия, истёкшая сессия.
- Уточнить: валидации (обязательность, форматы, маски, длины, допустимые символы, клиент vs сервер, тексты ошибок); права/роли (кто видит/может, неавторизованный, без permission); локаль/форматы (язык, дата/время/валюта/числа, TZ, направление текста).
- Все вопросы — списком с пометкой блокирующий/неблокирующий; блокирующие закрыть до старта.
Приоритизация и риск
- Риск по областям = вероятность дефекта × влияние (деньги, безопасность, данные, репутация, частота использования).
- Фокус на изменённом коде и его blast radius, а не ровным слоем.
- Решить: что автоматизировать (стабильное, регрессоопасное) vs ручная проверка (разведка, UX, разовое, визуал).
- Выделить smoke-подмножество (критичное для быстрой проверки билда) и regress-подмножество.
- Под дедлайн договориться о глубине явно, а не молча урезать.
План / матрица покрытия
- Scope: что входит/нет, на каких окружениях/браузерах/вьюпортах.
- Матрица: браузеры (Chromium/WebKit/Firefox) × вьюпорты × роли × состояния данных.
- Классы проверок: функциональные (happy/negative/boundary), UI/верстка/адаптив, валидации, навигация/роутинг/deeplink, состояния (loading/empty/error/success), доступы/роли, интеграции/API, данные/персистентность; нефункциональное (перф, security) где релевантно.
- Для каждого пункта: предусловие → действие → ожидаемый результат → привязка к AC/источнику.
- Тестовые данные: валидные/невалидные/граничные, спецсимволы, длинные строки, пустые значения, разные роли/состояния аккаунта.
- Согласовать exit-критерии и формат отчёта ДО выполнения.
Выполнение (доказательно)
- Масштаб прогона. Крупную задачу (длинный многошаговый флоу, полный регресс экрана, сверка прод/тест, E2E релиза) выполнять через fan-out (
references/fan-out.md): оркестратор последовательно ведёт браузер и собирает артефакты, затем параллельные субагенты (Agent) разбирают их по осям, синтез сводит находки. Мелкую (одна страница, smoke, один баг) — линейным проходом.
- Воспроизводить по шагам; для каждого результата — наблюдаемый артефакт (скриншот, видео, ответ сети, консоль, дамп DOM/БД).
- Различать: «работает как ожидалось» / «баг» / «вопрос к требованиям» / «не воспроизводится» — не сваливать в одно.
- Проверять не только UI, но и сеть (статус-коды, payload, обработку 4xx/5xx, ретраи, отсутствие чувствительных данных) и персистентность (перезагрузка, повторный вход).
- Консоль держать открытой весь прогон: ошибки/ворнинги JS, 404 ресурсов, CSP/CORS.
- Состояние после действия проверять в нескольких слоях: UI ↔ сеть ↔ БД/хранилище.
- Изолировать дефект: минимальные шаги, частота (always/intermittent), окружение, билд, предусловия; при нестабильности — повторить N раз, зафиксировать частоту, не маскировать ретраем без понимания причины.
- Реальный ввод vs программный. Программная установка значения (
fill(), setInputValue, .value=, а также автоматизационный «type», оборачивающий их) может обходить собственный событийный пайплайн приложения — фреймворковые onChange/onBlur, кастомные searchable/select-компоненты, коммитящие значение только кликом по опции. В поле визуально есть текст, а привязанный state пуст → ложная ошибка «required»/валидации (или, наоборот, маскируется настоящая). Любую находку про required/валидацию/выбор подтверждать реальным пользовательским вводом (клик по опции, посимвольный набор / pressSequentially, клавиатура) до выставления Pass/Fail. Если результат зависит от способа ввода значения — это ещё не доказательство.
- Карта действий (page map) — не переизучать страницу. Первый проход по экрану — исследование; всё найденное (рабочие селекторы, порядок кастомных контролов, эндпоинты API, DOM-квирки, baseline шума консоли стенда) сразу фиксировать в заметку прогона/проекта. Последующие проверки на том же экране выполнять по карте без повторного discovery; повторяющиеся флоу (дойти до шага N визарда) оборачивать в скрипт-хелпер и вызывать одним действием. В начале нового прогона перепроверить 1–2 ключевых селектора карты на живой странице — могли устареть.
- Инструментарий браузерных прогонов. Интерактивные шаги — через MCP-браузер (Playwright / Chrome DevTools MCP). Повторяющиеся флоу и скрипт-хелперы из page map — через
playwright-cli (отдельные процессы/профили; масштабируется на параллельных агентов, §7.8). Кросс-браузер: критичные сценарии (вёрстка, скролл, дата-пикеры, фокус/ховер, файловые инпуты) прогонять минимум в двух движках — Chromium + WebKit (MCP-сервер playwright-webkit или playwright-cli --browser webkit; при наличии — iOS-эмуляция): заметная часть UI-багов движко-специфична и в одном Chromium не видна.
- Обходной путь ≠ прохождение шага. Если целевое действие ТК не выполняется штатным пользовательским способом (клик/тап/ввод) — это Fail (дефект) или Blocked, даже когда технический workaround существует (
focus(), native setter, прямой вызов API). Workaround допустим только чтобы разблокировать ПОСЛЕДУЮЩИЕ проверки, и это явно фиксируется в отчёте; сам заблокированный шаг «зелёным» через обход не делается.
Фиксация / DoD
- Каждый ТК со статусом + доказательством: Pass (артефакт), Fail (баг + артефакт), Blocked (причина), Not tested (почему). Blocked ≠ Fail.
- Формат записи результатов в TMS (комментарии, окружение, вложения) — строго по конвенции команды, не изобретать свой; доказательства в любом случае сохраняются в артефактах прогона и сводном отчёте.
- Дефекты заведены, связаны с тикетом, severity/priority проставлены, шаги и артефакты приложены.
- Покрытие сверено с AC: каждый AC закрыт ≥1 проверкой; непокрытые — явно с причиной.
- Прогон зафиксирован: окружение, билд/коммит, браузеры/вьюпорты, дата, исполнитель.
- Регресс затронутых областей выполнен (или осознанно отложен с фиксацией риска); блокеры эскалированы; вопросы связаны.
- Новые/обновлённые ТК внесены в TMS; кандидаты на автоматизацию помечены.
- Негатив-гейт (обязательно). Прогон НЕ Done, пока не покрыты негативные и граничные классы и не сверено с
references/common-misses; в отчёте обязателен раздел «Негатив» с результатом по каждому классу или явной причиной пропуска. «Объект простой/навигационный» — не основание пропускать негатив: happy-path-only прогон считается неполным.
- Done = все неблокированные AC проверены с доказательствами, негатив/границы покрыты (или пропуск обоснован), баги заведены, отчёт и статусы ТК актуальны, остаточные риски и непокрытое перечислены честно.
1. Техники тест-дизайна
Классы эквивалентности (EP) — разбить вход на классы (валидные/невалидные/спец: пустое, null, пробелы). Один представитель из каждого валидного класса; КАЖДЫЙ невалидный класс отдельно (разные сообщения = разные классы). Числа: отриц./0/полож./дробные/сверх лимита. Строки: латиница/кириллица/цифры/спецсимволы/эмодзи/RTL/регистр. Перечисления: каждый вариант + вне списка. Файлы: разрешённый/запрещённый/пустой/битый. Даты: прошлое/настоящее/будущее/невалидный формат/несуществующая (31.02).
Граничные значения (BVA) — точные границы ±1. Для [min..max] проверить ровно: min−1, min, min+1, max−1, max, max+1 (не «маленькое/большое»). Длина строки: 0, 1, min±1, max±1. Граница на 0: −1, 0, 1 (счётчики, остатки, корзина). Деньги: 0.00, мин. платёж, мин−0.01, макс, макс+0.01, округление копеек. Дата/время: 23:59:59→00:00:00, последний день месяца, 29.02 високос/невисокос, переход через полночь/год. Пагинация: 0 элементов, ровно страница, страница+1 элемент, последняя неполная. Возраст/срок: ровно 18 (день в день), ±1 день, expiry ровно в момент.
Таблицы решений — для бизнес-правил с комбинациями условий. Условия × правила × ожидаемое действие; покрыть каждую значимую комбинацию (не все 2^n); включить невозможные/противоречивые (система отвергает). Применять для: скидок/тарифов/расчётов, доступа к фиче (роль × флаг × подписка × состояние), доступности submit (поле A × поле B × чекбокс), взаимоисключающих условий.
Переходы состояний (STT) — для сущности с жизненным циклом (черновик→модерация→опубликовано→архив→удалено). Проверить каждый разрешённый переход и КАЖДЫЙ запрещённый (событие в недопустимом состоянии → блок). Переходы по таймауту/системному событию (автоотмена, истечение сессии); действия, недопустимые в текущем состоянии (редактировать опубликованное, оплатить отменённое); циклы/возвраты; состояние после прерывания; конкурентные переходы двух пользователей.
Pairwise / комбинаторика — когда параметров >3 и полный перебор нереален (ОС × браузер × роль × язык × тема). Сгенерировать набор, покрывающий все пары (PICT/allpairspy); вручную добавить критичные бизнес-связки, которые pairwise может пропустить; проверить дефолты каждого параметра.
Error guessing — для зрелой/легаси-функциональности по слабым местам: двойной/тройной клик, отправка до завершения валидации, спецсимволы/инъекции, очень длинный ввод (10k+), вставка большого текста, пробелы/zero-width, эмодзи, autofill, медленная сеть, Back после успеха, F5 на промежуточном шаге, правка payload в DevTools в обход UI, действие с истёкшим токеном.
Дополнительно: причинно-следственный анализ (AND/OR/NOT между условиями, каскадные/зависимые поля); CRUD-матрица как базовый каркас для любой сущности; матрица доступов (роль × действие × ресурс) + проверка серверной защиты. Всегда: позитив (валидные классы, разрешённые переходы) + негатив (невалидные классы, запрещённые переходы, обход UI).
Выбор техники: диапазон/лимит → BVA+EP; много параметров → pairwise; комбинации условий → таблица решений; жизненный цикл → STT; зависимые условия → cause-effect; сущность с данными → CRUD; легаси → error guessing.
2. Справочники (references/) — обязательное чтение по типу задачи
Детальные чек-листы вынесены в references/. До составления плана прочитай целиком (Read) каждый файл, релевантный задаче — не выборочно и не по памяти; план без прочитанного справочника считается неполным.
| Файл | Когда читать | Что внутри |
|---|
references/frontend.md | Любая задача с UI | Поля/формы (маски, лимиты, paste/autofill), визуал и все состояния элементов, сверка с Figma, токены, overflow, адаптив и кросс-браузер (канонические разрешения) |
references/backend.md | API / сервисы / БД / интеграции | HTTP-методы и коды, схемы/контракты, пагинация, идемпотентность, PATCH, БД (целостность, транзакции, конкурентность, миграции), AuthN/AuthZ/IDOR/мультитенантность, очереди/вебхуки/cron, нагрузка и устойчивость, OWASP API Top 10 |
references/cross-cutting.md | Почти всегда (фронт и бэк вместе) | Сетевые ошибки и моки, consistency UI↔Backend, сессии/storage/мультивкладки, навигация/deeplink, время/TZ/i18n, перф и консоль, security с фронта, файлы/экспорт, поиск/фильтры, платежи, аналитика |
references/artifacts.md | Перед фиксацией результатов и багов | Доказательства, HAR/консоль, структура баг-репорта, severity vs priority, расхождения с макетом, трекер/TMS, сводный отчёт прогона |
references/common-misses.md | Всегда — перед финальным отчётом | Чек-лист «частые пропуски»: финальная самопроверка полноты прогона |
references/fan-out.md | Крупный прогон: длинный флоу, полный регресс экрана, сверка прод/тест | Как дробить дотошный прогон на параллельных субагентов по осям: сбор артефактов оркестратором → fan-out → синтез. Про способ исполнения, не класс проверок |
Минимальные наборы: UI-задача → frontend + cross-cutting (+artifacts при заведении багов); API/бэк → backend + cross-cutting; полный E2E/релиз → все. Крупный прогон / длинный флоу → дополнительно fan-out.md на этапе выполнения. common-misses.md — всегда последним, перед выводом отчёта.
Применяй технику и трек по контексту задачи. Для каждой реальной задачи сверяйся с её требованиями и макетами, а не с этим списком как с истиной — список напоминает классы проверок, но не заменяет AC и source of truth.
