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/др.) и автотесты (в репозитории автотестов проекта): переиспользовать, выявить пробелы, не дублировать. Статусам TMS не верить слепо — сверять с живыми тестами: встречаются «Automated» без существующего автотеста и «требуется автоматизация» на давно покрытом.
• Снять прод/preprod baseline (как фича работает сейчас — для регрессии и воспроизведения багов на актуальной версии).
• Уточнить окружение: стенд, доступы, тестовые учётки/роли, фиче-флаги, состояние данных, версия билда/коммит.
• Определить интеграции и зависимости: внешние API, платёжки, авторизация, очереди — что мокается, что реально.
• Явно зафиксировать out of scope (нативные приложения, неподдерживаемые браузеры, легаси-флоу).

Анализ требований и вопросы аналитику

• Каждый AC → проверка; каждая проверка → ссылка на AC или явная пометка «доп. эвристика».
• Когда скоуп = конкретное ТЗ: вердикты Pass/Fail только по его пунктам; находки вне ТЗ — отдельным блоком «вне скоупа» (наблюдение/вопрос), не Fail и не дефект задачи.
• Выявить неоднозначности («должно корректно работать», нет конкретных значений, неуказанные границы, неопределённое поведение при ошибке).
• Расхождения тикет ↔ 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-критерии и формат отчёта ДО выполнения.