Testing

Мастер-чеклист «как тестировать что угодно» — 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.