Вопросы для повторения

Тестирование — это процесс оценки качества продукта и поиска расхождений между ожидаемым и фактическим поведением. Цели: снизить риски, обнаружить дефекты раньше, дать прозрачную картину качества для бизнеса.

• Проверяем, что продукт делает то, что должен.
• Ищем поведение, которое может навредить пользователю или бизнесу.
• Помогаем принимать решение о релизе.

• анализ требований/макетов, поиск неоднозначностей и противоречий
• оценку рисков (что важнее всего для бизнеса/пользователя)
• подготовку тестовых данных и окружения
• проведение проверок (manual/авто), анализ результатов
• заведение дефектов и коммуникацию с командой
• подведение итогов (что проверено, что не успели, какие риски остаются)

Цель — предоставить объективную информацию о качестве и рисках, а не доказать отсутствие ошибок. Полностью доказать «безошибочность» невозможно из-за бесконечного числа сценариев и ограниченного времени.

• Мы подтверждаем соответствие требованиям и ожиданиям пользователя.
• Мы минимизируем риски критичных дефектов.

• бесконечное/очень большое пространство сценариев (комбинации данных, устройств, ролей)
• неполные/меняющиеся требования (ожидания могут отличаться от ТЗ)
• разные окружения (браузеры, ОС, сети, локали) и недетерминизм (тайминги, асинхронность)
• ограничения по срокам → тестируем выборочно, по рискам

• Ошибка (Error) — человеческая ошибка: неверное понимание/реализация.
• Дефект (Defect) — результат ошибки в артефакте (код, требование, дизайн).
• Баг (Bug) — дефект, проявившийся в работе системы.
• Инцидент (Incident) — наблюдаемое отклонение в проде, требующее разбирательства.

Коротко: ошибка → дефект → баг → инцидент в бою.

• Error (ошибка) — действие человека: неправильно понял требование, допустил опечатку, ошибся в формуле
• Defect — «след» ошибки в артефакте: требование/дизайн/код/конфиг
• Bug — проявление дефекта при выполнении: некорректный результат, падение, нарушение UX
• Incident — баг в проде/на эксплуатации, который влияет на пользователей и требует реакции (разбор, хотфикс, коммуникации)

Это путь дефекта от обнаружения до закрытия. Типичный цикл:

• New → Assigned → In Progress → Fixed → Ready for QA → Verified → Closed
• Возможные ветки: Reopened, Duplicate, Won't Fix, Can't Reproduce

Важно уметь пояснить статус и обосновать, почему баг закрыт или переоткрыт.

• какие статусы используются в вашей команде и что они означают (Definition of status)
• кто владелец на каждом шаге (QA/Dev/PO/Support)
• что нужно, чтобы перевести баг дальше (критерии «готово к ретесту»)
• ветки Duplicate / Won’t Fix / Can’t Reproduce / Need info и как вы их обосновываете
• когда уместен Reopen (фикс не сработал/не там/побочный эффект/частичный фикс)

Качество — это соответствие требованиям + удовлетворенность пользователя + надежность. Измеряется через метрики и наблюдения:

• Дефекты: количество, плотность, критичность.
• Покрытие: тестами/требованиями.
• Надежность: стабильность, отсутствие падений.
• Пользовательские метрики: NPS, удержание, обращения в поддержку.

• дефекты: распределение по severity, дефект‑плотность, доля «утечек» в прод (escaped defects)
• стабильность: crash‑free rate, error rate, uptime/SLA, MTTR/MTBF (если применимо)
• скорость: lead time дефекта, время на ретест, время реакции на инцидент
• покрытие: по требованиям/рискам/модулям, доля критических сценариев под регрессом
• пользовательские сигналы: обращения в поддержку, конверсия ключевых воронок, отмены/возвраты

• Верификация: «Мы делаем продукт правильно?» Проверка соответствия спецификациям.
• Валидация: «Мы делаем правильный продукт?» Проверка ценности для пользователя.

Формула: верификация = соответствие требованиям, валидация = соответствие ожиданиям/нуждам.

• верификация — ревью требований, тесты по AC/спеке, проверка бизнес‑правил, контрактов API
• валидация — пилоты, UAT, пользовательские сценарии, UX‑наблюдения, аналитика после релиза
• верификация чаще «до релиза», валидация может быть и «после» (по данным поведения пользователей)

• Тест-кейс — подробные шаги, входные данные и ожидаемый результат.
• Чек-лист — краткий перечень проверок без детальных шагов.
• Баг-репорт — документ о дефекте (шаги, фактический/ожидаемый результат, окружение).

• Тест‑кейс — когда нужна повторяемость, аудит, делегирование и точные шаги (регресс, критичные флоу)
• Чек‑лист — когда важна скорость и гибкость (смоук, исследовательские сессии, быстрые проверки)
• Баг‑репорт — когда нужно воспроизведение, влияние, контекст и доказательства (логи/скрины/видео)

• Severity — насколько сильно баг влияет на работу системы.
• Priority — насколько срочно его нужно исправить.

Пример: опечатка в слове — низкая criticality, но может быть высокий priority перед релизом.

• High severity + High priority: падение, потеря денег/данных, блокер ключевого сценария
• High severity + Low priority: редко встречающийся краш на экзотическом устройстве, если риск принят
• Low severity + High priority: маркетинговый текст/юридическая формулировка перед релизом
• Low severity + Low priority: косметика без влияния на поведение

• Smoke — быстрый набор ключевых проверок «продукт вообще жив».
• Sanity — узкая проверка конкретной фичи после фикса/изменения.
• Regression — проверка, что новые изменения не сломали старый функционал.

• Smoke: очень короткий набор «система вообще запускается и основные флоу живы» (часто после деплоя)
• Sanity: прицельная проверка конкретной области/фикса «не сломали ли мы это» (после правок)
• Regression: более широкий прогон важного функционала, чтобы убедиться, что изменения не поломали старое

• Позитивное — правильные данные, ожидаем корректную работу.
• Негативное — неправильные данные/сценарии, ожидаем корректную ошибку/защиту.

Баланс важен: позитивное подтверждает, негативное защищает от сбоев.

• пустые значения, слишком длинные строки, неверные форматы (email/телефон/даты)
• запрещенные символы и инъекции (если уместно), двойные клики/повторные запросы
• несоответствие прав (роль не может выполнить действие)
• сбой сети/таймауты, недоступность сервиса, повтор отправки формы
• граничные значения (мин/макс), комбинации полей

• Функциональное — проверка соответствия функциональным требованиям.
• Нефункциональное — производительность, безопасность, usability.
• Интеграционное — взаимодействие модулей.
• Системное — система целиком как единый продукт.
• Приемочное (UAT) — подтверждение от бизнеса/заказчика.

• производительность (нагрузка, время ответа, устойчивость)
• безопасность (аутентификация/авторизация, уязвимости)
• удобство (UX/usability, доступность)
• совместимость (браузеры/устройства/ОС), надежность и отказоустойчивость

• Unit — отдельные функции/классы.
• Integration — взаимодействие компонентов.
• System — проверка всего продукта.
• Acceptance — соответствие бизнес-ожиданиям.

• Unit: чистая логика (функции/классы), без внешних зависимостей или с моками
• Integration: взаимодействие компонентов (сервис↔БД, сервис↔сервис), контракты, схемы данных
• System: end‑to‑end сценарии «как пользователь», в реальном окружении
• Acceptance: критерии бизнеса/заказчика (AC), соответствие ожиданиям и готовность к релизу

• Black-box — тестируем без знания кода, только вход/выход.
• White-box — тестируем с доступом к коду/логике.
• Grey-box — частичное знание внутренностей.

• Black‑box: тесты по требованиям/интерфейсу, на уровне входов/выходов (UI/API), без знания кода
• Grey‑box: частичное знание (логика, схемы БД, документация API) → более точные тесты и быстрый дебаг
• White‑box: чтение кода/ветвлений, покрытие условий, помощь в написании unit‑тестов

• Exploratory — одновременно исследуем продукт и создаем тесты.
• Ad-hoc — быстрое тестирование без подготовки, часто хаотично.

Exploratory структурирован и осознан, ad-hoc — скорее импровизация.

• определить цель сессии (например: «найти дефекты в регистрации на мобиле») и таймбокс
• вести заметки: что проверил, какие данные использовал, что нашел
• использовать ходы: boundary/negative, смена ролей, прерывание сети, повторные действия
• в конце — короткий отчет: находки + риски + рекомендации

Проверка полного пользовательского сценария от начала до конца с участием всех систем. Пример: регистрация → оплата → подтверждение → уведомление.

• выделить критические цепочки (регистрация→покупка→оплата→доставка)
• контролировать тестовые данные (идемпотентность, очистка, уникальность)
• следить за внешними интеграциями (платежи/смс/почта) — часто нужны стабы/песочницы
• собирать артефакты: логи, запросы, скриншоты, чтобы быстро дебажить

Usability — насколько продукт удобен и понятен пользователю. Проводится через наблюдение: сценарии, тестовые пользователи, сбор фидбэка, анализ ошибок.

• определить целевые задачи (например: «оформить заказ за 2 минуты»)
• описать портрет пользователя и контекст (мобильный интернет, новичок/опытный)
• провести сценарное прохождение, фиксируя точки боли (где пользователь ошибается/зависает)
• проверить тексты ошибок, подсказки, доступность (контраст, таб‑навигация)
• оформить рекомендации с приоритетом (что исправлять в первую очередь)

• Cross-browser — одинаковая работа в разных браузерах.
• Cross-platform — одинаковая работа на разных ОС/устройствах.

• ориентироваться на аналитику: доли браузеров/ОС у вашей аудитории
• выделять критические пути (логин/оплата) и прогонять их на целевых платформах
• проверять проблемные зоны: адаптив, формы, загрузки файлов, медиа, canvas/видео
• использовать облака (BrowserStack/Firebase Test Lab) и локальные девайсы выборочно

A/B — сравнение двух вариантов функционала на разных группах пользователей. Тестировщик проверяет корректное разделение трафика, сбор метрик и отсутствие ошибок в обоих вариантах.

• рандомизация/бакетизация: один и тот же пользователь стабильно попадает в одну группу
• таргетинг: условия попадания (гео, платформа, версия приложения)
• эксклюзии: не пересекаются ли эксперименты, корректны ли флаги
• сбор аналитики: события, параметры, отсутствие дублей, корректные значения
• фоллбек: что видит пользователь при отключении флага/ошибке

• Retesting — повторная проверка конкретного исправленного бага.
• Regression — проверка, что ничего не сломалось рядом или в других частях.

• сделать ретест по шагам дефекта + вариации данных (границы/негатив)
• проверить смежные области («окрестный регресс») — то, что могло затронуться
• если дефект был в прод‑критичном месте — расширить регресс на критический путь

• I18n — подготовка продукта к поддержке разных языков/регионов.
• L10n — конкретная адаптация под язык/культуру (форматы дат, валюты).

Тестируем корректные переводы, длины строк, форматы, направления текста.

• переводы и терминология (без «смешения языков»), корректные сокращения
• переполнение UI: длинные строки, переносы, кнопки/таблицы
• форматы: дата/время, валюта, разделители, единицы измерения
• сортировка/поиск с учетом локали, регистр, диакритика
• RTL‑языки (если актуально): направление, выравнивания

Тест-дизайн — это методика выбора и описания тестов для максимального покрытия с минимальными затратами. Цель: найти дефекты быстрее и дешевле, чем хаотичное тестирование.

• декомпозицию требований на проверки и риски
• выбор техник (классы эквивалентности, границы, decision table и т.д.)
• определение данных и предусловий
• приоритизацию: критический путь → потом менее критичное
• трассируемость (что покрывает какой тест)

Делим входные данные на классы, где поведение одинаковое. Берем по 1–2 значения из каждого класса. Пример: возраст 1–17, 18–65, 66–120 — проверяем по одному значению из каждого диапазона.

• выделить валидные и невалидные классы (например: «возраст 18–65» и «<18», «>65», «пусто», «буквы»)
• для каждого класса выбрать представителя (типичное значение)
• не забыть про сочетания полей (когда валидации зависят друг от друга)

Проверяем значения на границах диапазонов, где чаще всего ошибки. Пример: если допустимо 1–10, то тестируем 0,1,2 и 9,10,11.

• значение на границе (min или max)
• значение чуть ниже границы (min−1)
• значение чуть выше границы (min+1)

Это таблица всех комбинаций условий и ожидаемых действий. Полезна, когда много логических правил (например, скидки, тарифы).

• выписать условия (например: «пользователь авторизован», «есть промокод», «доставка доступна»)
• выписать действия/результаты (например: «применить скидку», «показать ошибку»)
• составить набор правил‑колонок (комбинации) и покрыть их тестами
• свести комбинации, если они эквивалентны (чтобы не взорвать количество тестов)

Метод для систем, где есть состояния (например, заказ: создан → оплачен → доставлен). Проверяем корректные и некорректные переходы между состояниями.

• валидные переходы (допустимые последовательности)
• невалидные переходы (например, «доставить» до «оплаты»)
• побочные эффекты переходов (уведомления, списания, блокировки)
• повторные события и идемпотентность (двойной клик, повторный вебхук)

Тестирование по принципу «каждая пара параметров встречается хотя бы один раз». Снижает количество тестов при множестве параметров (браузер, ОС, язык и т. д.).

• кроссплатформенность (ОС×браузер×разрешение×язык)
• настройки/фильтры с большим числом опций
• комбинации ролей/тарифов/флагов

Матрица трассировки связывает требования с тестами. Помогает контролировать покрытие и видеть, какие требования не проверены.

• контроль покрытия требований (ничего не забыли)
• оценка влияния изменений (impact analysis)
• аудит/комплаенс (если есть регуляторика)
• прозрачность для команды и стейкхолдеров

Фокус на рисках:

• Критичные бизнес-сценарии.
• Зоны с историей дефектов.
• Новые/измененные компоненты.

Можно применить Risk-based testing + Smoke/Regression минимум.

• значение на границе (min или max)
• значение чуть ниже границы (min−1)
• значение чуть выше границы (min+1)

Тестирование на основе опыта и предположений о типичных ошибках. Пример: пустые поля, спецсимволы, большие числа, двойные клики.

• граничные значения и форматы (даты, валюты, часовые пояса)
• обработчики ошибок и сообщения пользователю
• права доступа и роли
• асинхронность и гонки (двойные клики, повторные запросы)
• интеграции (платежи, почта, внешние API)

Для чисел: диапазоны (валидные/невалидные). Для строк: длина, формат, допустимые символы. Пример: пароль 8–16 символов: классы 0–7, 8–16, 17+; спецсимволы допустимы/нет.

• выделить валидные и невалидные классы (например: «возраст 18–65» и «<18», «>65», «пусто», «буквы»)
• для каждого класса выбрать представителя (типичное значение)
• не забыть про сочетания полей (когда валидации зависят друг от друга)

• SDLC — жизненный цикл разработки ПО (идея → анализ → разработка → тестирование → релиз → поддержка).
• STLC — жизненный цикл тестирования (анализ требований → планирование → дизайн тестов → выполнение → отчет).

• SDLC: планирование → анализ требований → дизайн → разработка → тестирование → релиз → поддержка
• STLC: анализ требований → план/стратегия → дизайн тестов → подготовка окружения/данных → выполнение → отчетность → закрытие

• Анализ требований: выявление неоднозначностей.
• Проектирование: review спецификаций.
• Разработка: тесты, тестовые данные.
• Тестирование: выполнение, отчеты, риски.
• Релиз: качество, sign-off.
• Поддержка: анализ инцидентов.

• требования: уточнения, примеры, выявление edge‑кейсов, согласование AC
• дизайн: проверка UX‑логики, валидности потоков, доступности
• разработка: синк по тестируемости, логированию, фича‑флагам
• тестирование: риск‑ориентированные проверки, баг‑репорты, регресс
• релиз/прод: smoke после деплоя, мониторинг, участие в разборе инцидентов

• Waterfall — последовательные этапы, изменения дорогие.
• Agile — гибкая разработка короткими итерациями.
• Scrum — Agile-фреймворк со спринтами, ролями, церемониями.
• Kanban — визуализация потока задач и ограничение WIP.

• Waterfall: этапы идут «водопадом», изменения дорогие, тестирование часто в конце
• Scrum: спринты, роли, церемонии, инкремент в конце спринта
• Kanban: непрерывный поток задач, WIP‑лимиты, фокус на пропускной способности

• Product Owner
• Scrum Master
• Dev Team (включая QA)

• Waterfall: этапы идут «водопадом», изменения дорогие, тестирование часто в конце
• Scrum: спринты, роли, церемонии, инкремент в конце спринта
• Kanban: непрерывный поток задач, WIP‑лимиты, фокус на пропускной способности

• Sprint — фиксированный отрезок времени (1–4 недели).
• Backlog — список задач/фич.
• User Story — описание ценности для пользователя.
• Acceptance Criteria — условия, при которых задача считается выполненной.

• история должна быть тестируемой (ясные AC, примеры, ограничения)
• AC — основа для тестов и приемки, но не заменяют тест‑дизайн
• не бойтесь задавать вопросы на refinement: роли, данные, ошибки, исключения

• DoR — критерии готовности задачи к разработке.
• DoD — критерии завершенности задачи (код, тесты, документация).

• DoR: описаны AC, понятны роли/состояния, есть макеты, известны интеграции, согласованы риски
• DoD: реализовано по AC, пройден смоук/регресс, заведены дефекты, обновлена документация, готово к релизу

Решение QA о готовности релиза с учетом рисков и результатов тестирования. Это не «разрешение», а информирование бизнеса о состоянии качества.

• объем проверок (что вошло/что не вошло)
• результаты (пройдено/провалено, критичные дефекты)
• остаточные риски и рекомендации (можно ли релизить и при каких условиях)
• ограничения: окружение, данные, известные проблемы

В планировании оценивает риски, уточняет требования, предлагает тестовую стратегию. В ретроспективе помогает улучшать процесс: где были дефекты, что можно автоматизировать.

• задает вопросы по тестируемости (логи, фичафлаги, тестовые данные)
• предлагает критерии приемки и минимальный набор проверок (smoke/regress)
• выносит проблемы качества: поздние требования, нестабильное окружение, долгие фиксы
• договаривается о действиях (action items) и метриках улучшений

Сообщить риски и влияние, предложить варианты:

• Отложить релиз.
• Откатить/закрыть фичу флагом.
• Выпустить с известным риском и планом фикса.

Решение принимает бизнес, QA дает данные.

• оценить severity/impact и затронутые пользователи/деньги/безопасность
• предложить компромиссы: отключить фичу флагом, частичный релиз, hotfix‑ветка
• сделать минимальный smoke по критическому пути + ретест фикса, если есть
• зафиксировать остаточный риск и решение в задаче/канале релиза

Уточнить изменения, обновить тестовую документацию и оценку времени. Отметить, какие тесты устарели и какие нужны новые проверки.

• уточнить изменения и критерии приемки (что теперь «правильно»)
• пересмотреть тест‑набор: какие кейсы устарели, какие добавить
• обновить тестовые данные/окружение, предупредить о рисках и сроках
• перепроверить смежные части (регресс вокруг измененной логики)

• Test Plan — стратегия и объем тестирования.
• Test Case — сценарий с шагами.
• Test Suite — набор тест-кейсов.
• Test Run — выполнение набора тестов в конкретном окружении.

• Test Plan: цель, объём, риски, окружения, роли, критерии входа/выхода, отчётность
• Test Case: предусловия, шаги, данные, ожидаемый результат, пост‑условия
• Test Suite: набор кейсов по модулю/фиче/регрессу
• Test Run: запуск suite на конкретной сборке + результаты (pass/fail/blocked)

Тест-кейс — детальные шаги. Чек-лист — только перечень проверок. Чек-лист быстрее поддерживать, тест-кейсы лучше повторяемы.

• чек‑лист: смоук, быстрые проверки, exploratory сессии
• тест‑кейс: регресс, критические флоу, сложные сценарии с данными
• гибрид: чек‑лист + ссылки на детальные кейсы для важных пунктов

• Заголовок и краткое описание.
• Шаги воспроизведения.
• Фактический и ожидаемый результат.
• Окружение (OS, браузер, версия).
• Вложения: скриншот, логи.

• краткое, конкретное название (что/где/при каких условиях)
• окружение: версия, платформа, браузер/устройство, роль пользователя
• шаги воспроизведения + тестовые данные
• Actual vs Expected, частота (100%/иногда), влияние/риски
• вложения: скрин/видео, логи, HAR, request/response, console errors

Таблица соответствия требований и тестов. Показывает, что каждое требование проверено.

• каждое требование/AC связано с одним или несколькими тестами
• при изменении требования видно, какие тесты обновить и что ретестить
• можно быстро ответить «покрыто/не покрыто» и показать прогресс

• Expected — что должно произойти по требованиям.
• Actual — что произошло фактически.

Пишем четко, без эмоций, с конкретными данными.

• Expected: конкретный результат (сообщение, статус, изменение данных, редирект)
• Actual: то, что реально видим (включая коды/тексты/значения)
• если ожидание не определено — это отдельный вопрос к требованиям (не придумывать молча)

Это условия, при которых функционал считается выполненным и приемлемым для бизнеса.

• однозначные и проверяемые (без «удобно», «быстро» без метрики)
• покрывают позитив + важный негатив
• учитывают роли/права, ошибки и граничные условия
• согласованы со всеми (PO/Dev/QA) до начала разработки

Это TMS — системы управления тестами. Помогают хранить тесты, запускать прогоны, формировать отчеты.

• иерархия тестов (suite/sections), теги, версии
• прогоны (runs), отчеты (pass rate, flaky, blocked)
• связь с требованиями/задачами/дефектами (traceability)
• шаблоны шагов, параметризация, хранение тестовых данных

Итоговый отчет о тестировании: объем, результаты, найденные дефекты, риски, вывод о качестве.

• объем: что тестировали и на каком окружении/версии
• результаты: pass/fail/blocked, ключевые сценарии
• список критичных дефектов + статус, остаточные риски
• что не успели/ограничения тестирования
• рекомендация по релизу (go/no-go/условно go)

В TMS или таблице: статус теста (Pass/Fail/Blocked), комментарии, ссылки на баги.

• в TMS отмечать pass/fail/blocked и причину блокировки
• для fail — ссылка на баг + доказательства (скрин/видео/логи/HAR)
• фиксировать версию билда, окружение, тестовые данные
• если отклонение спорное — ссылка на требования/AC и обсуждение

Указываем в тест-кейсе/чек-листе: аккаунт, роль, баланс, состояние системы. Храним тестовые данные отдельно, чтобы можно было быстро повторить тест.

• роль/учетная запись (права, тариф, статус), необходимые настройки
• состояние сущностей (заказ «оплачен», корзина «не пустая»)
• данные (номера, суммы, даты) и правила их уникальности
• способ подготовки (через UI, API, SQL, фикстуры) и очистки после теста

Веб-приложение состоит из:

• Frontend — интерфейс в браузере.
• Backend — серверная логика.
• DB — хранение данных.

Запросы идут из браузера на сервер, сервер обращается к БД и возвращает ответ.

• где может быть причина дефекта: UI (верстка/валидация), API (контракт/логика), БД (данные/ограничения)
• как выглядит запрос: URL + метод + headers + body → response (status + body)
• роль состояния: cookies/localStorage/sessionStorage, серверные сессии
• наблюдаемость: логи, ошибки в console, network traces

• Функционал (формы, кнопки, сценарии).
• UI/UX (верстка, адаптивность).
• Скорость загрузки и ошибки в консоли.
• Безопасность (авторизация, сессии).

• критические пользовательские сценарии (логин, покупка, поиск, профиль)
• формы и валидации, сообщения об ошибках
• верстка: адаптив, переполнение, шрифты, локализация
• кроссбраузерность и разное разрешение/масштаб
• производительность субъективно (долгие загрузки), ошибки в Console
• безопасность на уровне здравого смысла (права, прямые ссылки, сессии)

Проверяем:

• Обязательные поля, пустые значения.
• Границы длины (мин/макс).
• Формат (email, телефон).
• Недопустимые символы и инъекции.

• валидации по каждому полю: обязательность, формат, диапазон, длина
• сообщения об ошибках: понятность, где показываются, исчезают ли после исправления
• обработка пробелов/регистра, автозаполнение, вставка из буфера
• маски и форматирование (телефон, карта): корректность при вводе/удалении
• отправка: двойной клик, блокировка кнопки, индикатор загрузки
• серверные ошибки: 4xx/5xx, таймаут — понятное сообщение, данные не теряются

Используем DevTools (responsive mode), проверяем ключевые брейкпоинты, прокрутку, наложения. Важно: доступность, читаемость, кликабельность элементов.

• переполнение текста (длинные названия, локализация), обрезания, наложения
• адаптив: брейкпоинты, меню, таблицы, модалки на маленьком экране
• состояния элементов: hover/focus/disabled/error, видимость фокуса
• масштаб браузера 80–200%, системный шрифт крупнее
• кроссбраузер: отличия рендера шрифтов, flex/grid, scroll
• доступность: таб‑навигация, контраст (минимум здравого смысла)

Это проверка корректной работы в разных браузерах и версиях. Используем реальные браузеры и сервисы вроде BrowserStack.

• выбрать целевые браузеры по аналитике и требованиям
• прогнать критический путь и проблемные зоны (формы, видео, загрузки, печать)
• зафиксировать known issues и их приоритет
• использовать облачные фермы/виртуалки для редких комбинаций

• Проверяем поведение при обновлении/очистке кэша.
• Проверяем хранение токенов в cookies/storage.
• Проверяем срок жизни и безопасность (HttpOnly, Secure).

• cookies: срок жизни, secure/httponly/samesite, удаление при logout
• localStorage/sessionStorage: что хранится, очистка, миграции значений
• кэш ресурсов: обновляется ли фронт после деплоя (cache busting)
• поведение при очистке cookies/кэша и при приватном режиме
• корректность сессии при нескольких вкладках/устройствах

Используем вкладки Elements, Console, Network, Application. Проверяем ошибки, стили, запросы, storage.

• Elements: проверка DOM, CSS, размеров/overflow, состояние элементов
• Console: JS‑ошибки, предупреждения, логи, исключения
• Network: запросы/ответы, коды, тайминги, payload, HAR‑экспорт
• Application/Storage: cookies, localStorage, service workers, cache
• Device toolbar: эмуляция экранов, сетей, DPR

Смотрим URL, метод, статус, headers, payload, response. Это помогает отловить ошибки API и неверные параметры.

• URL, метод, статус‑код, время ответа
• request headers (auth, content-type) и payload (body/query)
• response body: данные/ошибка, соответствие контракту
• редиректы (301/302), CORS‑ошибки, смешанный контент (mixed content)
• повторные запросы, дубли, кэширование (from disk cache/from memory cache)

• 200 — OK
• 301 — Redirect
• 400 — Bad Request
• 401 — Unauthorized
• 403 — Forbidden
• 404 — Not Found
• 500 — Server Error

• 200/201 — успех (создание часто 201)
• 301/302 — редирект (проверь цепочки, SEO, сохранение параметров)
• 400 — неверный запрос/валидация, 401 — не аутентифицирован, 403 — нет прав
• 404 — ресурс не найден, 500 — внутренняя ошибка сервера

Проверяем корректность URL, статус 301/302, отсутствие циклов. В Network проверяем 404/500 для CSS/JS/картинок.

• корректность 301/302: куда ведет, сохраняются ли query‑параметры и хэш
• битые ссылки (404), ссылки в новых вкладках, относительные/абсолютные пути
• загрузка ресурсов (JS/CSS/шрифты/картинки): нет ли 404/403, корректные mime‑типы
• CORS/Access-Control заголовки, mixed content при HTTPS
• поведение при медленной сети/частичной загрузке

Сравниваем ответ API с тем, что отображается на UI. Проверяем формат, порядок, корректность округлений.

• контракт: поля, типы, обязательность, обработка неизвестных/лишних полей
• форматирование: даты/валюты/локаль, округления, единицы измерения
• пустые состояния: нет данных, частичные данные, null
• ошибки API: 4xx/5xx — корректные сообщения и UI‑состояния
• пагинация/сортировка/фильтры: соответствие параметрам запроса

• Позитивные и негативные сценарии.
• Проверка ограничений (пароль, email).
• Сессия, выход, безопасность.
• Срок действия ссылок восстановления.

• валидации полей, сообщения об ошибках, ограничения пароля (сложность)
• блокировки/лимиты: повторные попытки, rate limit, капча (если есть)
• восстановление: токен/ссылка, срок жизни, одноразовость, повторное использование
• сессии: logout, истечение, «запомнить меня», несколько устройств
• безопасность: прямые ссылки, доступ к чужим данным, корректные 401/403

Используем responsive mode, проверяем ключевые разрешения (мобильный/планшет/десктоп). Проверяем переносы, скрытые элементы, кликабельность.

• брейкпоинты: ключевые ширины (моб/планшет/десктоп)
• длинный контент и локализация → переполнение
• скролл: горизонтальный не должен появляться без причины
• фиксированные элементы (header/footer) не перекрывают контент
• модальные окна и попапы на маленьком экране

• Responsive — элементы гибко перестраиваются под ширину.
• Adaptive — несколько фиксированных макетов под брейкпоинты.

• плавное изменение размеров: нет ли «скачков», наложений, исчезающих кнопок
• проверка ключевых брейкпоинтов и типовых устройств
• удобство управления: кликабельные зоны, размер шрифтов, доступность меню

Можно изменить значения прямо в DOM, отправить форму, посмотреть Network. Для сложных запросов — использовать `fetch` в Console или Postman.

• повторить запрос (Replay XHR), сравнить payload и response
• изменить запрос и проверить реакцию (граничные значения/негатив)
• замедлить сеть/CPU, проверить устойчивость UI
• проверить, что на submit уходит то, что ввел пользователь (нет лишних преобразований)
• сохранить HAR для бага

Мобильное тестирование учитывает устройства, ориентацию, сеть, батарею, уведомления, store-процессы. Веб больше про браузеры и фронтенд.

• ориентация и разные размеры экранов, safe‑area/notch
• работа при слабой/падающей сети, офлайн‑режим
• permissions (камера, гео, уведомления), фоновые ограничения
• пуши, deep links, интеграции (Apple/Google login, платежи)
• производительность и потребление батареи

• Нативное — для конкретной ОС (Swift/Java/Kotlin).
• Гибридное — оболочка + web-контент.
• Веб-приложение — работает в браузере.

• натив: важны permissions, фоновые режимы, жизненный цикл приложения, store‑сборки
• веб: ближе к веб‑тестированию (DOM, кэш), но с мобильными особенностями (тач, клавиатура)
• гибрид: часто проблемы на стыке WebView и нативных экранов, deep links и навигация

Симулятор имитирует поведение ОС, эмулятор ближе к «железу». Эмулятор обычно медленнее, но точнее.

• камера/биометрия/сенсоры, реальные уведомления, производительность и нагрев
• поведение на слабом железе, специфические баги GPU/рендера
• интеграции с системой (share sheet, звонки, SMS), фоновые ограничения

Проверяем:

• Установка без ошибок.
• Обновление сохраняет данные.
• Удаление очищает данные или оставляет их по требованиям.

• чистая установка: первый запуск, онбординг, разрешения, дефолтные настройки
• обновление: сохранение пользовательских данных, миграции, отсутствие крашей
• откат (если релевантно): что будет при downgrade
• удаление: чистится ли кэш/данные (в рамках возможностей ОС)
• совместимость: минимальная версия ОС, размер, условия стора

Проверяем получение при разных состояниях (фон, закрыто, активное). Валидируем текст, переходы по тапу, уникальность и тайминг.

• получение push при разных состояниях приложения
• текст/локализация/иконка, группировка, звук, бейдж
• клик: открывается ли нужный экран (deeplink), корректны ли параметры
• повторная доставка, задержки, дедупликация
• отключение уведомлений и корректный фоллбек (in-app баннер)

Проверяем реальные устройства + эмуляторы, разные размеры экрана и плотности пикселей. Смотрим на отступы, читаемость, кликабельность.

• переполнение текста, локализация, динамический размер шрифта
• тач‑таргеты (кнопки не слишком маленькие), отступы, кликабельность
• safe area: элементы не под вырезом/индикатором жестов
• состояния: loading/empty/error, скелетоны
• модалки/клавиатура: перекрывает ли поля, скролл до активного поля

Отключаем сеть, проверяем кэш, очереди, корректные ошибки и восстановление при подключении.

• поведение при отсутствии сети: понятное сообщение, доступность кэшированных данных
• очередь действий: что происходит с операциями (повтор, отмена, сохранение черновика)
• синхронизация после онлайн: нет дублей, корректное разрешение конфликтов
• переключение Wi‑Fi↔LTE, режим «в самолете», потеря сети в момент запроса

Deep link — ссылка, открывающая конкретный экран в приложении. Проверяем корректные переходы и поведение при отсутствии приложения.

• открытие нужного экрана с параметрами
• поведение при закрытом приложении и при уже открытом
• если нужен логин: корректный переход через авторизацию и возврат на целевой экран
• валидность параметров и обработка невалидных (ошибка/фоллбек)
• универсальные ссылки (iOS Universal Links) / App Links (Android)

Проверяем запрос прав, поведение при отказе, повторный запрос, настройки системы.

• первый запрос: когда и зачем спрашиваем (не слишком рано)
• отказ: корректный фоллбек и подсказка, как включить в настройках
• разные уровни (например, гео: while‑in‑use vs always)
• повторный запрос, состояние «don’t ask again»
• поведение после смены разрешения в настройках без перезапуска

ADB — Android Debug Bridge. С его помощью можно устанавливать приложения, смотреть логи, выполнять команды. Примеры: `adb install`, `adb logcat`.

• снять логи (logcat) для бага/краша
• установить/удалить приложение, очистить данные/кэш
• проверить deeplink/intent, передать параметры
• снять информацию об устройстве, версии, разрешениях

Используем профайлеры Android Studio/Xcode, мониторим CPU, память, энергию. Проверяем длительные сценарии и фоновые процессы.

• нагрев/просадки FPS при скролле и анимациях
• частые запросы в фоне, бесконечные ретраи
• быстрый разряд при простое (wakelocks/фоновые сервисы)
• рост памяти со временем (утечки), падения на слабых устройствах
• работа в энергосберегающем режиме

Проверяем успешный вход, отмену, ошибки, повторный вход, корректную привязку аккаунта.

• успех: создается/привязывается аккаунт, корректная роль/профиль
• отмена пользователем, неверный пароль, блокировка аккаунта — корректные сообщения
• повторный вход, выход и повторная авторизация
• deeplink возврата в приложение, работа в разных браузерах/вебвью
• безопасность: нельзя «войти под другим» без подтверждения

Сохранение состояния, корректное отображение, отсутствие перерисовок/сбоев.

• сохранение введенных данных и позиции скролла
• корректная верстка и safe area в обеих ориентациях
• работа модалок, клавиатуры, медиаконтента
• поворот во время загрузки/запроса (race conditions)

Используем `logcat` (Android) или консоль Xcode (iOS). Фиксируем шаги, версию, устройство.

• шаги + данные, частота, состояние сети, состояние приложения (фон/передний план)
• логи: Android Logcat / iOS device logs, скрин/видео
• инфо: модель, ОС, версия приложения, свободная память/диск (если важно)
• если есть: crashlytics id/сессия, timestamp

Appium — автоматизация, Firebase Test Lab — облачные девайсы, BrowserStack — кросс-девайс, Charles — перехват трафика.

• Appium: кросс‑платформенная UI‑автоматизация
• Firebase Test Lab / BrowserStack: тест на парке устройств/версий
• Charles: просмотр/подмена HTTP(S) трафика, диагностика API
• Crashlytics: отчеты по крашам и стектрейсы

Клиент отправляет запросы, сервер обрабатывает и возвращает ответ. Архитектура разделяет UI и логику.

• разделять проблемы UI и API: один и тот же API может обслуживать разные клиенты
• понимать, где хранится состояние: клиент (storage) vs сервер (session)
• уметь читать запрос/ответ: метод, URL, headers, body, статус‑коды

REST — архитектурный стиль, обычно JSON, простые HTTP-методы. SOAP — протокол на XML с строгими стандартами и контрактом.

• REST: легче смотреть/тестировать, часто Swagger/OpenAPI, коды HTTP активно используются
• SOAP: XML‑структуры, строгие контракты, ошибки могут быть в SOAP Fault
• аутентификация/авторизация может отличаться (WS‑Security и т.п.)

• GET — получение данных
• POST — создание
• PUT — полное обновление
• PATCH — частичное обновление
• DELETE — удаление

• GET: получить данные (без побочных эффектов)
• POST: создать/запустить действие (часто не идемпотентен)
• PUT: заменить ресурс целиком (обычно идемпотентен)
• PATCH: частично обновить (часто идемпотентен по договоренности)
• DELETE: удалить (идемпотентен: повтор обычно не меняет результат)

Headers — метаданные запроса/ответа, body — данные, response — то, что вернул сервер (статус, заголовки, тело).

• обязательные headers (Authorization, Content-Type, Accept)
• корректность payload (типы, обязательные поля, null/пусто)
• коды ответа и структура ошибок (единый формат)
• пагинация/фильтры через query params, корректная кодировка

200 OK, 400 неверный запрос, 401 нет авторизации, 403 доступ запрещен, 404 не найдено, 500 ошибка сервера.

• 200/201/204 — успех (204 без тела)
• 400 — валидация/ошибка запроса, 401 — нет/невалидный токен, 403 — нет прав
• 404 — ресурс не найден, 409 — конфликт (если используется)
• 500/502/503 — серверные ошибки/недоступность

Форматы передачи данных. JSON проще и чаще используется, XML — более строгий и verbose.

• корректность типов (например, число не строкой), обязательность полей
• порядок в JSON обычно не важен, в XML может иметь значение по схеме
• кодировка/экранирование спецсимволов, большие числа/точность
• обработка null/отсутствия поля (это разные вещи)

Token — ключ доступа. JWT — токен с данными и подписью. Cookies — способ хранения данных в браузере.

• срок жизни токена, refresh‑механизм, корректные 401 при истечении
• logout: токен/сессия реально инвалидируется
• cookies: HttpOnly/Secure/SameSite, домен/путь, удаление
• права доступа (RBAC): 403 при запрете
• защита от повторного использования старых токенов (если требуется)

Проверяем:

• Статус код.
• Схему и типы данных.
• Бизнес-логику ответа.
• Ошибки при негативных запросах.

• status code + body (успех/ошибка) соответствуют контракту
• валидация входных данных (400), сообщения об ошибках, локализация (если есть)
• авторизация: 401/403, доступ к чужим данным, роли
• идемпотентность (повтор запроса), гонки и конкурентные изменения
• пагинация/сортировка/фильтры, ограничения и значения по умолчанию
• пограничные данные: null, пустые списки, большие числа, спецсимволы

Postman — клиент для API. Swagger — документация/контракт. Charles/Fiddler — перехват и анализ трафика.

• Postman: коллекции, окружения, переменные, автотесты простых проверок (scripts)
• Swagger/OpenAPI: сверка контрактов, генерация примеров, понимание обязательных полей
• Charles/Fiddler: ловить запросы мобильного/веб клиента, подменять ответы, искать причины 4xx/5xx

Отправляем логин/пароль, получаем токен, используем его в запросах. Проверяем истечение токена и ошибки при неверных данных.

• получение токена при валидных данных и ошибки при невалидных
• истечение токена и refresh (если есть), корректный 401
• доступ к защищенным эндпоинтам без токена/с чужим токеном
• роли и ограничения: 403, отсутствие доступа к чужим ресурсам
• logout/инвалидация токена (если реализовано)

БД — хранилище данных. SQL нужен для проверки данных после операций и анализа причин багов.

• проверяет, что сущность создалась/обновилась/удалилась (CRUD)
• валидирует бизнес‑правила в данных (статусы, суммы, связи)
• быстро готовит тестовые данные (если разрешено процессом)
• находит причины багов (дубликаты, неверные статусы, нарушения ограничений)

SELECT — выборка, INSERT — добавление, UPDATE — обновление, DELETE — удаление.

• после действия в UI/API — проверить запись через SELECT по ключу
• для UPDATE — убедиться, что изменились только нужные поля
• для DELETE — проверить «мягкое» удаление (soft delete) vs физическое
• учитывать транзакции: данные могут появиться не сразу (асинхронность)

JOIN соединяет таблицы по ключам. INNER — только совпадающие строки, LEFT — все из левой + совпадения, RIGHT — наоборот.

• INNER: только совпавшие строки
• LEFT: все слева + совпадения справа (если нет — null)
• RIGHT: аналогично, но «все справа» (реже используют)
• частая проверка QA: «не потерялись ли записи из основной таблицы» → LEFT JOIN

Выполнить SELECT по ключу и сверить значения с ожидаемыми.

• в таблице появилась новая строка/обновилась существующая (по ключу)
• значения полей корректные (суммы, округления, статусы)
• связи с другими таблицами корректны (FK), нет «висячих» ссылок
• аудитные поля (created_at/updated_at/created_by) корректны
• нет дублей при повторе операции (идемпотентность)

Проверяем уникальность, связи по foreign key, отсутствие «висячих» ссылок.

• FK: нет ссылок на несуществующие записи
• unique: нет дублей там, где их быть не должно
• not null: обязательные поля заполнены
• business constraints: статусы допустимы, суммы не отрицательные и т.д.

COUNT — количество, DISTINCT — уникальные, GROUP BY — группировка, ORDER BY — сортировка.

• COUNT: количество (в том числе после фильтра)
• DISTINCT: уникальные значения (например, уникальные пользователи)
• GROUP BY: агрегация по категориям/статусам
• ORDER BY: сортировка (важно проверять стабильность и вторичные поля)

Сравниваем данные до/после миграции, проверяем потерю/изменение данных, корректность связей.

• запуск миграции на копии данных/стенде без ошибок
• контрольные выборки: до/после (counts, sums, выборочные записи)
• обратная совместимость (если нужно): старая версия клиента не ломается
• индексы/ограничения на месте, производительность запросов не ухудшилась

Primary key — уникальный идентификатор строки. Foreign key — ссылка на primary key другой таблицы.

• PK обеспечивает уникальность и быстрый поиск записи
• FK предотвращает «сиротские» записи и задает правила удаления/обновления
• по FK удобно проверять: у заказа есть позиции, у платежа есть заказ и т.д.

Удаляем запись в родительской таблице и проверяем, что связанные записи удалены.

• удаление родителя удаляет/обнуляет ссылки у дочерних (по правилам)
• нет потери данных там, где должно быть soft delete
• аудит/логирование операций (если есть)
• поведение при частичных связях и при конкурентных операциях

Используем JOIN по ключам и фильтры по бизнес-правилам. Проверяем корректные суммы, статусы, связи.

• идентифицировать ключ сущности (order_id/user_id)
• собрать «основную» таблицу + связанные (позиции, платежи, доставки)
• проверить консистентность статусов и сумм между таблицами
• при необходимости — проверить историю/аудит/таблицу событий

Jira, YouTrack, Redmine, Bugzilla — инструменты для хранения задач и дефектов.

• оформлять баги и задачи с понятной структурой
• использовать связи и метки (релиз, компонент, версия, окружение)
• понимать workflow команды (triage, ready for qa, done)
• строить фильтры и простые отчеты (по приоритетам, утечкам в прод)

TMS — система управления тестами: тест-кейсы, прогоны, отчеты.

• разделить тесты на регресс/смоук/фича‑наборы
• вести актуальность (архивировать устаревшие, устранять дубли)
• использовать параметры/шаблоны, чтобы не плодить копии
• связывать тесты с требованиями и дефектами

Network — запросы и ответы, Console — ошибки JS, Storage — cookies/local/session storage.

• Network: статус‑коды, payload, тайминги, редиректы, HAR
• Console: ошибки, предупреждения, stacktrace
• Storage: cookies/localStorage/sessionStorage, токены, кеш
• Elements: верстка, CSS, размеры, скрытые элементы

Перехватывает и анализирует трафик. Можно смотреть запросы, подменять ответы, тестировать API.

• увидеть реальные запросы приложения, сравнить с контрактом
• поймать ошибки 4xx/5xx и понять причину (headers/body)
• эмулировать плохую сеть/таймауты и проверить устойчивость
• map local/remote: подменить ответ сервера для проверки UI

Создаем запросы, настраиваем параметры, отправляем, проверяем ответы. Можно писать коллекции и автотесты.

• коллекции по фичам, environments (dev/stage), переменные токенов
• негативные тесты (400/401/403) и проверка схемы ответа
• генерация данных (pre-request scripts), chained requests
• экспорт curl и прикладывание request/response к багам

Проверяем отправку, шаблон, корректность данных, тайминг. Можно использовать тестовые почтовые сервисы.

• триггер: при каком событии отправляется, нет ли дублей
• контент: тема/текст/локаль, персонализация, корректные данные
• ссылки: работают, ведут туда, куда нужно, корректно обрабатывают токены
• доставка: задержки, попадание в спам, ограничения провайдера (если известно)
• отмена/отписка (если есть), согласия на рассылку

Сбор логов, видео, точных условий, минимизация влияния. Создаем воспроизводимый сценарий в тестовом окружении.

• собрать максимум контекста (время, пользователь, запросы, логи, версии)
• сравнить конфиги prod vs stage, фича‑флаги, данные и права
• попробовать воспроизвести на stage с копией данных (если возможно)
• эскалировать как инцидент, если влияет на деньги/пользователей

Используем аналитические события и системные логи, фиксируем шаги, идентификаторы и таймстемпы.

• ключевые бизнес‑события (создан заказ, оплата успешна/неуспешна)
• ошибки и причины отказов (validation code, payment decline code)
• корреляционные идентификаторы (request id, session id)
• контекст: версия клиента, платформа, сеть, feature flags

Переменные окружения хранят конфигурацию (URL, токены), чтобы не менять код.

• понимать, почему поведение отличается на dev/stage/prod
• быстро переключать endpoints/фичи на стенде
• корректно настраивать Postman/автотесты через переменные
• не «хардкодить» секреты в документации и репозитории

Проверяем соответствие конфигураций, доступы, версии и данные. На проде тестируем аккуратно и минимально.

• данные (тестовые vs реальные), доступы и роли
• интеграции: песочницы платежей, тестовые SMS/email
• конфиги, фича‑флаги, версии сервисов
• нагрузка и кэш, расписания фоновых задач

Уточнять у аналитика/PO, фиксировать допущения и проверять рисковые зоны через exploratory testing.

• кто пользователь/роль и какая цель сценария
• что считается успехом/ошибкой, какие сообщения показываем
• границы: лимиты, форматы, исключения, права доступа
• интеграции и зависимости, требования к логированию/аудиту

Сравниваем с требованиями и ожиданиями пользователя. Если поведение не описано — уточняем у PO.

• проверить требования/AC/макеты/аналитику прошлых версий
• оценить влияние на пользователя/бизнес (risk)
• если не определено — поднять вопрос к PO/аналитику и зафиксировать решение
• после решения — обновить документацию/AC и тесты

Повторяем несколько раз, фиксируем окружение и шаги. Проверяем на разных данных/устройствах.

• повторить N раз и оценить частоту (100%/иногда)
• варьировать данные и окружение (браузер/устройство/сеть)
• собрать логи/Network/HAR и точные таймстемпы
• выделить минимальные шаги (reduce) и предположить причину

Привести требования, логи, доказательства. Обсудить и согласовать критерии.

• привести источник ожидания (AC/спека/макет) и фактические данные
• показать воспроизведение и артефакты (видео, request/response)
• если ожидание не определено — эскалировать к PO/аналитику
• предложить компромисс: изменить текст/поведение/логирование, завести техдолг

Использовать анализ системы, исторические данные, интервью с PO/Dev, exploratory testing.

• exploratory сессии + заметки и чек‑лист
• выделить основные сущности и правила (статусы, расчеты, права)
• сравнить UI↔API↔БД (если доступно)
• фиксировать найденные правила как «живую документацию» (wiki/AC)

Проверяем корректные выборки, порядок, стабильность при переходах страниц. Сравниваем результат с базой или заранее подготовленными данными.

• корректность фильтра по каждому условию + комбинации
• сортировка: направление, вторичные ключи, стабильность
• пагинация: размеры страниц, переходы, крайние страницы, пустые результаты
• сохранение состояния при обновлении/назад/перезагрузке
• соответствие запросам API (params) и данным в ответе

Проверяем формулы, округления, скидки, налоги, крайние значения.

• happy path + комбинации скидок/промокодов/доставки
• округления и точность (копейки), формат валюты
• границы: минимальная цена, 0, большие суммы, отрицательные значения
• повтор пересчета при изменении корзины, отмена промокода
• соответствие расчета на UI и в API/БД

Сначала критичные сценарии и новые изменения. Используем risk-based подход.

• определить критический путь и покрыть его первым
• добавить границы/негатив вокруг изменений
• проверить интеграции и деньги/данные/безопасность
• зафиксировать, что не протестировано, и риски

Используем негативные сценарии, стресс, boundary value, нестандартные данные.

• boundary + negative + error guessing
• смена контекста: другая роль, другой браузер/устройство/локаль
• прерывания: обновить страницу, уйти назад, закрыть вкладку, потерять сеть
• параллельные действия: два окна, два пользователя, гонки
• анализ логов и network: неочевидные ошибки

Определяем минимальные/максимальные значения, пустые поля, неправильные форматы.

• happy path + комбинации скидок/промокодов/доставки
• округления и точность (копейки), формат валюты
• границы: минимальная цена, 0, большие суммы, отрицательные значения
• повтор пересчета при изменении корзины, отмена промокода
• соответствие расчета на UI и в API/БД

QA участвует во всем цикле: уточняет требования, пишет тесты, проверяет качество, помогает улучшать процесс.

• участвует в refinement: уточняет AC, риски, тестируемость
• планирует тесты и данные заранее (shift-left)
• тестирует инкремент в течение спринта, а не в конце
• помогает с автоматизацией/контрактами/чек‑листами регресса
• участвует в демо и ретроспективе, улучшая процесс

Это процесс приоритизации багов: оценка критичности, влияния, сроков исправления.

• severity/priority и влияние на пользователей/бизнес
• воспроизводимость и необходимость доп.информации
• план фикса (в спринт/в хотфикс/в техдолг)
• дубликаты и связность с релизами/фичами

Planning — оценка тестовых задач, grooming — уточнение требований, retrospective — улучшение процесса.

• planning: оценка тест‑работ, зависимостей, рисков, критериев приемки
• grooming/refinement: уточнение AC, edge‑кейсов, данных, нефункциональных требований
• retro: анализ причин дефектов/утечек, предложения улучшений (логи, флаги, тестовые данные)

Оцениваем по объему функционала, рискам, наличию автотестов, сложности окружения.

• анализ требований + подготовка тестов/чек‑листов
• подготовка данных/окружения
• выполнение (смоук/функционал/негатив/границы)
• ретест и регресс вокруг изменений
• время на баг‑репорты и коммуникацию

Обсудить с PO/BA, зафиксировать недостающие данные, не начинать тестирование без DoR.

• собрать список вопросов/неопределенностей и договориться о решениях
• зафиксировать временные предположения (если нужно) и согласовать их
• предложить минимальный тестируемый объем + риски
• не начинать «полный регресс», пока не понятен expected

Автоматизация smoke/regression, четкие критерии DoD, быстрый feedback loop.

• shift-left: QA в refinement и ранних проверках
• smoke/regress наборы, приоритизация по рискам
• автоматизация стабильного регресса (где ROI высокий)
• feature flags, быстрый rollback, мониторинг после релиза

Пирамида тестов: больше unit, меньше интеграционных, еще меньше UI. Баланс скорости и надежности.

• unit быстро ловят ошибки логики, дешевы в поддержке
• интеграционные ловят проблемы стыков и контрактов
• E2E дают уверенность в пользовательском пути, но самые хрупкие

Находит узкие места, предлагает автоматизацию, улучшает требования и критерии качества.

• введение чек‑листов смоука и Definition of Done
• договоренности о логировании/корреляции запросов
• feature flags и тестовые стенды с реалистичными данными
• контрактные проверки API (schema), линтеры, статический анализ
• разбор дефектов (RCA) и профилактика

Регулярные короткие встречи: статус тестирования, блокеры, баги, планы.

• что сейчас тестируется и какие блокеры/риски
• какие дефекты критичны и что с ними
• готовность фиксов к ретесту, где нужны логи/инфо
• что пойдет в релиз и что откладывается

Фокус на требованиях и фактах, обсуждение влияния, привлечение PO при необходимости.

• показать воспроизведение и доказательства (логи/Network/видео)
• привести AC/макет или запросить решение у PO, если не определено
• обсудить варианты: фикс сейчас, хотфикс, workaround, фича‑флаг
• зафиксировать договоренность и обновить документацию

Сначала определяем основные сценарии (позитивные), затем негативные, затем крайние условия. Пример для банкомата: карта/пин/баланс/снятие/ошибки; для кофемашины: вода/зерна/режимы.

• уточнения: цель, пользователи, ограничения, окружение
• основные сценарии (happy path) + негатив + границы
• состояния и переходы (например, банкомат: вставил карту→ввел PIN→операция)
• нефункциональные: безопасность, отказоустойчивость, удобство
• приоритизация: критические риски сначала

Проверяем точные совпадения, частичные, регистр, язык, спецсимволы, пустой запрос, скорость.

• пустой запрос, пробелы, спецсимволы, регистр, раскладка
• частичные совпадения, опечатки (если поддерживается)
• релевантность: результаты соответствуют запросу, подсветка
• пагинация/фильтры/сортировка совместно с поиском
• нет результатов: корректное empty‑state
• производительность: время ответа, дебаунс, автокомплит

Добавление/удаление, количество, цена, скидки, доставка, сохранение корзины, границы по количеству.

• добавление/удаление, изменение количества, ограничения (макс/мин)
• пересчет суммы: скидки, промокод, доставка, налоги
• сохранение корзины (гость→логин), несколько устройств
• нетоварные случаи: товар закончился, цена изменилась, корзина устарела
• переход к чекауту: данные передаются корректно, идемпотентность

Проверяем поля, валидации, отправку, подтверждение, получение письма/заявки.

• валидации: обязательные поля, длина, формат email/телефона
• сообщения об ошибках, сохранение введенного при ошибке
• защита: rate limiting/капча (если есть), XSS в полях
• доставка: создается запись/тикет, приходит уведомление на почту
• приватность: нет утечки персональных данных в ответах/логах

Отправка/получение, статусы, офлайн, вложения, синхронизация, задержки.

• отправка/получение, порядок сообщений, повторная отправка
• статусы (sent/delivered/read), индикатор набора
• вложения: типы, размер, загрузка/скачивание
• офлайн: очередь сообщений, синхронизация после онлайна
• безопасность: доступ к чужим чатам, инъекции в сообщениях

Позитив/негатив, валидации, безопасность, подтверждение, восстановление пароля.

• регистрация: уникальность email/телефона, подтверждение (если есть)
• логин: неверные данные, блокировки, «запомнить меня»
• восстановление: токены/ссылки, срок жизни, одноразовость
• сессии: logout, истечение, несколько устройств
• безопасность: brute force, 2FA (если есть), корректные 401/403

Алгоритм — это четкая последовательность шагов, которая приводит к результату. Пример: «проверка логина» — ввести данные → отправить → проверить статус → показать результат. Для QA важно: алгоритмы лежат в основе бизнес-логики, и мы проверяем их корректность на входах/выходах.

• покрыть пустые/минимальные/максимальные входы
• проверить корректность на типовых и угловых случаях (дубликаты, отсортировано/обратно)
• проверить детерминизм: одинаковый ввод → одинаковый вывод
• проверить производительность на больших данных

• ошибки на границах (min/max, пусто)
• потери/дубли элементов
• зависания на больших данных

Это способ организации данных для хранения и быстрого доступа. Пример: список заказов может быть массивом, а поиск пользователя по id — через хэш-таблицу. Для QA важно понимать, как это влияет на скорость и поведение приложения.

• проверять корректность на пустых/малых/больших наборах
• проверять порядок элементов (если он важен)
• проверять уникальность/дубли (для Set‑подобных структур)
• проверять конкурентные сценарии (если структура используется параллельно)

• зависимость от порядка там, где порядок не гарантирован
• падения на пустых коллекциях

• Массив — элементы по индексам, быстрый доступ.
• Список — элементы связаны, удобно вставлять/удалять.
• Стек — LIFO, последний вошел — первый вышел.
• Очередь — FIFO, первый вошел — первый вышел.
• Дерево — иерархия (категории, меню).
• Граф — связи между объектами (соцсети, маршруты).
• Хэш-таблица — быстрый поиск по ключу.

• для коллекций — проверить пусто/1/много, дубликаты, границы
• для деревьев/графов — проверить циклы/глубину/невалидные ссылки
• для хэш‑таблиц — не полагаться на порядок

• IndexOutOfBounds на пустых списках
• неявная зависимость от порядка

• Стек: последний элемент обрабатывается первым (undo, история переходов).
• Очередь: первый элемент обрабатывается первым (очередь сообщений).

Пример: очередь задач в системе уведомлений обычно FIFO.

• проверить порядок обработки элементов
• проверить поведение при переполнении/большой очереди
• проверить повтор обработки и отсутствие потерь

• перепутан порядок
• потеря элементов при нагрузке

• HashMap хранит пары «ключ → значение».
• HashSet хранит уникальные значения.

Хэш-функция преобразует ключ в индекс. Быстрый доступ обычно O(1). Для QA: удобно понимать, почему поиск пользователя по id быстрый.

• проверить уникальность (для Set)
• не полагаться на порядок в ответах/коллекциях
• проверить поведение на коллизиях/похожих ключах (если проявляется как баг)

• фронт ожидает фиксированный порядок
• дубли из‑за неверной нормализации ключей

Бинарный поиск делит упорядоченный массив пополам и выбирает нужную часть. Эффективен только на отсортированных данных, сложность O(log n). Пример: поиск товара по id в отсортированном списке.

• проверить: пусто, 1 элемент, найдено/не найдено
• проверить дубликаты (какой индекс возвращаем?)
• проверить, что вход отсортирован (если это предпосылка)

• применяют к неотсортированным данным
• ошибки на границах диапазона

Big O описывает, как растет время работы при увеличении входных данных. QA это важно для оценки рисков производительности. Пример: если операция O(n²), то при росте данных в 10 раз время может вырасти в 100 раз.

• сравнить время ответа на 1k/10k/100k данных (тренд)
• найти порог, где начинается деградация
• проверить самые тяжелые операции (фильтры, сортировки, отчеты)

• тестируют только на маленьких данных
• смотрят только среднее, игнорируют p95/p99

• O(1): доступ к элементу массива по индексу.
• O(n): поиск элемента в списке линейным проходом.
• O(n²): сортировка пузырьком, двойные вложенные циклы.

• тестировать на росте данных (scale test)
• проверять крайние размеры списков/страниц/экспортов

• нет тестов на большие объемы
• таймауты не обрабатываются корректно

Это помогает предсказывать, где система «сломается» при росте нагрузки. Пример: фильтр работает быстро на 1 000 записей, но медленно на 100 000 из‑за O(n²). QA может рекомендовать нагрузочные тесты на больших объемах данных.

• замерять время на растущих объемах
• фиксировать p95/p99, ошибки, таймауты
• проверять “тяжелые” сценарии (поиск/сортировка/отчеты)

• проверяют только функциональность, не масштаб

Проверяем:

• Сортировка по возрастанию/убыванию.
• Поведение на пустом массиве и массиве из 1 элемента.
• Дубликаты и отрицательные значения.

Пример: вход [3, 1, 2, 2] → ожидаем [1, 2, 2, 3].

• проверить пусто/1 элемент/много
• проверить дубликаты и вторичную сортировку
• проверить числа как строки ("10" vs "2")
• проверить локаль/регистр/спецсимволы

• строковое сравнение чисел
• нет вторичного ключа → “скачет”

Клиент отправляет запросы, сервер их обрабатывает и возвращает ответы. Пример: браузер (клиент) отправляет запрос на сервер, сервер отвечает HTML/JSON.

• воспроизвести и посмотреть запрос/ответ
• проверить коды 4xx/5xx и тело ошибки
• проверить авторизацию и права

• делают вывод без анализа Network

• Frontend — интерфейс.
• Backend — бизнес-логика.
• API — интерфейс обмена данными.
• БД — хранение данных.

Пример: кнопка «Купить» (frontend) → запрос в API → запись в БД.

• сравнить UI и ответ API (Network/Postman)
• если API верный — проблема фронта/рендера
• если API неверный — проблема backend/данных

• несогласованность форматов
• нет обработки ошибок API

Запрос — сообщение от клиента серверу (метод, URL, параметры). Ответ — результат обработки (статус, данные, ошибки). Пример: GET /users/123 → 200 OK + JSON.

• проверить статус и тело
• проверить headers (Auth, Content‑Type)
• проверить структуру ошибок

• игнорируют тело ошибки

Коротко: DNS → IP → соединение → HTTP‑запрос → ответ → рендер страницы. Пример: при `example.com` браузер узнает IP через DNS, устанавливает HTTPS, получает HTML/CSS/JS.

• Network: статус‑коды, редиректы, ресурсы
• Console: JS‑ошибки, mixed content
• Storage: cookies/localStorage при проблемах авторизации

• битые ресурсы после деплоя
• кэш держит старые версии

DNS переводит имя домена в IP-адрес. IP-адрес — уникальный адрес сервера в сети (например, 93.184.216.34).

• проверить nslookup/dig
• проверить другую сеть/VPN
• учесть кэш DNS

• устаревший кэш
• неверный CNAME/A

Порт — «точка входа» на сервере для конкретного сервиса. Пример: HTTPS — порт 443, HTTP — 80.

• проверить правильный порт и протокол
• учесть firewall

• перепутали http/https

HTTP — протокол передачи данных. HTTPS — HTTP с шифрованием TLS. Для QA важно: HTTPS защищает данные, особенно логины и пароли.

• проверить сертификат (срок/домен)
• проверить редирект http→https
• проверить mixed content

• истёкший сертификат
• неверные часы

200 OK, 301 Redirect, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Server Error.

• для 401/403 проверить токен/права
• для 400 проверить валидацию
• для 500 собрать request/response + время

• сервер отвечает 500 вместо 400

GET — получить, POST — создать, PUT — обновить полностью, DELETE — удалить. Пример: POST /orders создаёт заказ, GET /orders/123 возвращает его.

• проверить повтор POST (двойной клик) → нет дублей
• проверить коды 201/204
• проверить валидации и права

• дубли при ретраях/повторах

Cookies — данные в браузере. Session — серверная сессия. Token — ключ доступа. JWT — токен с данными и подписью. Для QA важно: где хранится и как истекает.

• проверить истечение токена и 401
• проверить logout: токен/сессия реально инвалидируется
• проверить HttpOnly/Secure/SameSite

• logout только на UI

Клиент отправляет логин/пароль, сервер проверяет и выдает токен или сессию. Далее клиент передает токен в запросах, сервер проверяет доступ.

• воспроизвести и посмотреть запрос/ответ
• проверить коды 4xx/5xx и тело ошибки
• проверить авторизацию и права

• делают вывод без анализа Network

REST — архитектурный стиль, обычно JSON. SOAP — протокол на XML с жесткими контрактами.

• проверить соответствие контракту
• проверить ошибки
• проверить обратную совместимость

• ошибка скрыта под 200 OK

WebSocket — двустороннее соединение, сервер может отправлять данные без запроса. Пример: чаты, онлайн‑уведомления.

• проверить порядок и доставку
• проверить reconnect без дублей
• проверить авторизацию канала

• дубли при reconnect

Proxy перехватывает трафик между клиентом и сервером. QA использует его для анализа запросов, подмены ответов, проверки ошибок сети.

• перехватить запрос/ответ
• подменить ответ 500/таймаут

• кэш прокси скрывает проблему

IP — адрес устройства в сети. MAC — физический адрес сетевого адаптера. Порт — номер сервиса на устройстве.

• проверить доступность домена/порта
• учесть VPN/прокси

• путают домен и IP

TCP гарантирует доставку и порядок пакетов, UDP быстрее, но без гарантии. Пример: видео‑стримы часто используют UDP, веб‑страницы — TCP.

• симулировать потери/задержки
• проверить восстановление

• нет graceful degradation

DNS переводит домены в IP, чтобы людям не помнить цифры адресов.

• проверить nslookup/dig
• проверить другую сеть/VPN
• учесть кэш DNS

• устаревший кэш
• неверный CNAME/A

Браузер обращается к DNS → получает IP → устанавливает HTTPS → отправляет запрос → получает ответ.

• Network: статус‑коды, редиректы, ресурсы
• Console: JS‑ошибки, mixed content
• Storage: cookies/localStorage при проблемах авторизации

• битые ресурсы после деплоя
• кэш держит старые версии

• ping — проверка доступности узла.
• traceroute — путь пакета по сети.
• nslookup — проверка DNS‑записей.

• проверить DNS
• проверить маршрут
• сравнить сети

• ICMP может быть запрещен

VPN создает защищенное соединение и позволяет тестировать гео‑ограничения. Пример: проверить контент, доступный только для другой страны.

• сравнить с VPN/без
• учесть таймауты/скорость

• VPN меняет DNS

SSL/TLS — протоколы шифрования. HTTPS защищает данные от перехвата. QA проверяет, что пароли и токены передаются только по HTTPS.

• проверить сертификат (срок/домен)
• проверить редирект http→https
• проверить mixed content

• истёкший сертификат
• неверные часы

Это документ, подтверждающий подлинность сайта и используемый для шифрования. Неверный сертификат — риск безопасности и падение доверия пользователей.

• проверить срок и домен
• проверить цепочку доверия
• проверить дату/время на устройстве

• истёк сертификат
• сертификат на другой домен

Проверяем, что нет смешанного контента (HTTP внутри HTTPS), сертификат валиден, редиректы корректные, HSTS работает.

• проверить сертификат (срок/домен)
• проверить редирект http→https
• проверить mixed content

• истёкший сертификат
• неверные часы

Firewall фильтрует трафик. Он может блокировать запросы или ограничивать порты. QA должен учитывать это при тестах интеграции.

• сравнить разные сети
• проверить порты/домены

• таймаут трактуют как баг приложения

Процесс — отдельная программа в ОС. Поток — выполнение внутри процесса. Пример: браузер = процесс, вкладки могут быть потоками.

• воспроизводить параллельными действиями
• замедлять сеть/CPU для проявления гонок
• фиксировать тайминги и логи

• race condition
• deadlock

• Deadlock — взаимная блокировка (две операции ждут друг друга).
• Race condition — ошибка из‑за одновременного выполнения.

Пример: два пользователя одновременно оплачивают один и тот же товар.

• параллельные действия (2 вкладки/2 пользователя)
• повторы и стресс (двойные клики)
• сбор логов с таймстемпами

• нет логов/корреляции

Виртуальная память — расширение RAM за счет диска. Если ее не хватает, приложение может тормозить или падать.

• длинные сессии (утечки)
• тест на слабом железе
• сбор метрик/логов памяти

• тестируют только коротко

RAM — оперативная память (временная). ROM — постоянная (прошивки).

• проверять на слабых девайсах
• проверять большие объемы данных

• нет пагинации

Файловая система определяет, как данные хранятся на диске. NTFS (Windows), FAT32 (старые носители), ext4 (Linux).

• проверить большой файл
• проверить имена с юникодом/спецсимволами
• проверить права/ошибки записи

• необработанная ошибка записи

Permissions определяют, кто может читать/писать/исполнять файлы. Пример: пользователь не может удалить системный файл без прав.

• проверить 401/403
• проверить прямые ссылки (IDOR)
• проверить смену ролей

• права только на UI

Логи — записи о событиях приложения. Обычно находятся в папках logs, в системных журналах, в DevTools.

• собрать логи вокруг времени бага
• искать request/correlation id
• не включать PII/секреты

• логи без контекста

Ищем время, сообщение, стек ошибок, ID запроса. Сравниваем с шагами воспроизведения.

• сопоставить таймстемпы
• выделить stacktrace и причину
• приложить релевантный фрагмент

• нет request id

Переменные окружения — настройки, которые ОС передает приложению (URL, ключи).

• фиксировать окружение и флаги в баге
• проверить, что секреты не утекли в логи

• перепутанные окружения

Foreground — активный процесс с UI, background — выполняется в фоне. Пример: загрузка файла идет в фоне, пока пользователь смотрит страницу.

• свернуть/развернуть во время операций
• проверить фоновые задачи/уведомления

• потеря состояния

База данных, где данные хранятся в таблицах с отношениями. Пример: пользователи и заказы связаны по user_id.

• проверить CRUD в таблицах
• проверить связи PK/FK
• проверить ограничения unique/not null

• сиротские записи

Таблица — набор строк (rows). Поле (column) — тип данных, строка — конкретная запись. Пример: column «email», row — email конкретного пользователя.

• проверить, что изменена нужная строка по id
• сверить значения колонок

• UPDATE без WHERE меняет лишнее (в разработке)

Primary Key — уникальный идентификатор записи. Foreign Key — ссылка на запись в другой таблице.

• проверить наличие дочерних записей по FK
• проверить каскады/запреты при удалении

• сиротские записи

Индексы ускоряют поиск, но замедляют вставку/обновление. QA учитывает их при производительных тестах.

• тестировать на больших наборах
• замерять p95

• тестируют на маленькой БД

Выполнить SELECT по ключу и сравнить значения с ожидаемыми. Пример: после регистрации в БД появилась запись с корректным email.

• SELECT по ключу и сверка полей
• проверка статусов и связей
• проверка дублей при повторе

• UI показывает одно, БД хранит другое

SELECT — чтение, INSERT — вставка, UPDATE — обновление, DELETE — удаление.

• после действия в UI сверить через SELECT
• проверить soft delete vs hard delete

• физическое удаление там, где нужен soft delete

JOIN объединяет таблицы по ключам. INNER — только совпадения, LEFT — все из левой + совпадения, RIGHT — наоборот.

• LEFT JOIN для поиска “потерянных” связей
• сверка сумм/статусов

• неверное условие JOIN “размножает” строки

Проверяем, что нет «висячих» ссылок и все foreign key корректны.

• проверить FK (нет сирот)
• проверить уникальность
• проверить допустимые статусы

• сироты

WHERE — фильтр, ORDER BY — сортировка, GROUP BY — группировка, LIMIT — ограничение строк.

• сверить фильтры UI с WHERE
• сверить сортировку с ORDER BY
• проверить пагинацию (LIMIT/OFFSET)

• разная сортировка UI и DB

Сопоставляем данные в БД с расчетами и статусами. Пример: скидка 10% → цена в заказе соответствует формуле.

• сверить суммы: позиции − скидки + доставка
• проверить статусы и связи

• проверяют только UI

Переменная хранит значение, функция — блок кода, if — ветвление, цикл — повторение. Пример: если цена > 0 — показать «Купить».

• покрыть true/false ветки
• проверить границы условий
• проверить большие входы (цикл/списки)

• ошибка “>” vs “>=”

Это выражения, которые дают истина/ложь. Пример: isLoggedIn = true → показываем профиль.

• покрыть комбинации условий
• проверить приоритет AND/OR

• пропущенные комбинации

Операторы для сравнения значений: равно, не равно, больше, меньше. QA использует их при проверке условий и граничных значений.

• проверить min−1/min/min+1
• проверить числа vs строки

• строковое сравнение чисел

Массив — коллекция с доступом по индексу (начинается с 0). Пример: items[0] — первый элемент.

• проверить пусто/1/много
• проверить первый/последний

• IndexOutOfBounds

Null — отсутствие значения. Ошибки с null часто приводят к падениям. QA проверяет, что система корректно обрабатывает пустые значения.

• null vs отсутствие поля
• пустые значения и дефолты

• NPE/краш

Exception — ошибка во время выполнения кода. Проявляется как crash, ошибка 500, или сообщение в логах.

• негативные сценарии
• корректные коды 400/401/403
• без stacktrace пользователю

• 500 вместо 400

Ветвление — разные пути выполнения кода по условиям. QA тестирует все ветки: позитивную, негативную, граничные случаи.

• таблица условий (decision table)
• границы

• пропущенная ветка

Детерминированный код дает один и тот же результат при одинаковых входах. Недетерминированный зависит от времени, потоков, рандома — сложнее тестировать.

• зафиксировать время/таймзону/флаги
• повторить N раз и оценить частоту

• нет ORDER BY

RegExp — шаблоны для поиска/проверки строк. QA использует для валидации email, логов, форматов дат.

• проверить валидные/невалидные форматы
• поиск request id в логах

• слишком строгая/слабая валидация

Это подмены реальных сервисов для изоляции тестов. Пример: мок сервиса оплаты, чтобы тестировать без реальных транзакций.

• эмулировать ответы 200/400/500
• тестировать таймауты

• мок не соответствует контракту

SQL Injection — внедрение SQL‑кода через ввод пользователя. Пример: ввод в поле логина `' OR '1'='1` и проверка, что вход не выполняется.

• проверить поля ввода типовыми payload
• проверить, что ошибки не раскрывают SQL

• SQL‑ошибки в ответе

XSS — внедрение скриптов в страницу. QA проверяет, что ввод не исполняется как код (экранирование).

• вставить html/script и проверить, что не выполняется
• проверить вывод пользовательского контента

• выполнение HTML/JS

CSRF — атака, при которой пользователь выполняет нежелательное действие на сайте. Защита — токены и проверка источника запроса.

• наличие CSRF‑токена
• SameSite cookies

• нет CSRF защиты

Brute-force — перебор пароля. Защита: лимиты попыток, капча, блокировки.

• ограничение попыток
• задержка/капча

• нет лимитов

DoS — перегрузка сервиса одним источником, DDoS — множеством. QA проверяет устойчивость и rate limiting.

• проверить 429/503 и UI‑обработку
• проверить лимиты на логин/OTP

• клиент бесконечно ретраит

Ограничение количества запросов за период времени для защиты сервиса. Пример: не более 5 логинов в минуту.

• сверить фильтры UI с WHERE
• сверить сортировку с ORDER BY
• проверить пагинацию (LIMIT/OFFSET)

• разная сортировка UI и DB

Шифрование можно расшифровать ключом. Хеширование — одностороннее. Пароли обычно хешируются, а не шифруются.

• нет пароля/токена в ответах/логах
• HTTPS для чувствительных операций

• секреты в логах

JWT содержит данные пользователя и подпись для защиты от подмены. Подпись подтверждает, что токен выдал сервер.

• проверить истечение токена и 401
• проверить logout: токен/сессия реально инвалидируется
• проверить HttpOnly/Secure/SameSite

• logout только на UI

Проверяем авторизацию, валидации, доступ по ролям, защиту от инъекций, HTTPS.

• проверить доступ к чужим данным
• проверить 401/403
• проверить отсутствие stacktrace/секретов

• права только на UI

Нагрузочное тестирование проверяет устойчивость при большом количестве пользователей. Даже manual QA должен уметь оценить риски и инициировать такие тесты.

• выбрать критичные сценарии
• смотреть p95 и error rate

• смотрят только среднее

Автоматизированный процесс сборки, тестирования и доставки релиза. QA участвует, чтобы проверить тесты и стабильность сборок.

• build → tests → deploy
• читать логи и артефакты

• нет артефактов

Build — сборка приложения, deploy — размещение на сервере, release — выпуск пользователям.

• smoke после deploy
• версия/окружение

• нет smoke после деплоя

Dev — разработка, staging — предрелизная среда, production — рабочая среда пользователей.

• фиксировать окружение и версию
• учесть песочницы интеграций

• тестируют опасное на prod

Git — система контроля версий. QA полезно уметь получать ветки, смотреть изменения и понимать историю.

• знать checkout/branch/log
• фиксировать версию/коммит

• тестируют не ту версию

Commit — зафиксированное изменение кода. Pull request — запрос на вливание изменений в основную ветку с ревью.

• читать описание PR и тест‑план
• смотреть результаты CI

• PR без описания

Это параметры для запуска тестов/сборок (URL, ключи, флаги).

• фиксировать окружение и флаги в баге
• проверить, что секреты не утекли в логи

• перепутанные окружения

Это инструменты для запуска CI/CD: сборка, тесты, деплой.

• найти stage падения
• открыть отчет тестов

• нет артефактов

Docker упаковывает приложение и его зависимости в контейнер. QA использует, чтобы тесты были воспроизводимы в одинаковой среде.

• проверить env и порты
• смотреть логи контейнера

• не проброшен порт

Mock‑сервер имитирует ответы API. Полезно, когда реальный сервис недоступен или нестабилен.

• ответы 200/400/500
• таймауты

• мок не соответствует контракту

QA подтверждает качество, готовит отчет о рисках, участвует в go/no‑go решении.

• перед релизом: критический путь
• после деплоя: smoke
• фиксировать known issues/риски

• нет фиксации рисков

Используем минимальные наборы данных + граничные значения. Пример: одна запись в списке, затем две, затем пустой список.

• 0 записей, 1 запись
• агрегаты (суммы/средние)

• краш на пустом списке

Исследовательское тестирование, анализ UI, логов и сетевых запросов. Формируем гипотезы, проверяем входы/выходы.

• exploratory сессия + заметки
• критический путь + негатив + границы

• хаотичное тестирование без фиксации

Проверяем зависимости от времени, кэша, данных, параллельных процессов. Фиксируем условия и минимальный сценарий воспроизведения.

• повторить N раз и оценить частоту
• проверить кеш/состояние
• зафиксировать окружение и флаги

• нет ORDER BY

Подготовить известный набор данных и сравнить результат сортировки с ожидаемым порядком. Проверить стабильность сортировки на равных значениях.

• монотонность по ключу
• дубликаты и стабильность
• null/локаль/регистр

• строки вместо чисел

Разбить на области (UI, API, данные, интеграции) и оценить риски. Согласовать допущения с командой.

• разбить на UI/API/данные/интеграции
• дать диапазон и assumptions

• оценка “на глаз” без допущений

Проверяем формулы на простых и граничных значениях. Пример: цена 100, скидка 10% → 90; налог 20% → 108.

• таблица тестов
• границы и округления
• сверка с API/БД

• ошибка округления

Собираем логи, мониторим окружение, ищем зависимость от нагрузки, времени, данных. Пошагово исключаем гипотезы.

• частота и условия
• артефакты (Network/HAR/логи)
• минимальные шаги

• нет артефактов

Проверяем API напрямую, сравниваем с UI, смотрим состояние в БД. Если API корректен, ошибка в UI; если данные неверны в БД — проблема на сервере.

• Network/Postman: request/response
• SQL/админка: сверка данных

• делают вывод без проверки API

Проверяем задержку, порядок, повторную отправку. Используем логи/очереди, фиксируем таймстемпы.

• порог ожидания
• ретраи и дубли
• идемпотентность

• дубли уведомлений

Проверяем цепочку запросов, корректность данных на каждом шаге. Используем моки, чтобы изолировать сбойный компонент.

• контракт и схемы
• 4xx/5xx/таймаут
• идемпотентность

• дубли при повторах