Уровни тестирования

Draft

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

Содержание

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

Основные уровни

  • Unit testing проверяет отдельные функции, методы или классы в изоляции.
  • Integration testing проверяет взаимодействие модулей, сервисов, БД, очередей и внешних зависимостей.
  • System testing оценивает систему целиком как продукт с её бизнес-логикой и окружением.
  • Acceptance testing проверяет, что решение соответствует ожиданиям пользователя или бизнеса и готово к принятию.

Что даёт каждый уровень

  • Unit: быстрый и дешёвый сигнал о поломке логики на низком уровне.
  • Integration: защита от проблем в контрактах, данных и взаимодействии компонентов.
  • System: проверка целостных пользовательских сценариев и end-to-end поведения.
  • Acceptance: подтверждение, что команда решает правильную задачу, а не просто технически корректную.

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

  • Unit tests не покажут сбой в интеграции между сервисами.
  • Системные тесты слишком дорогие и хрупкие, чтобы закрывать ими всю логику.
  • Acceptance без технических уровней часто даёт обратную связь слишком поздно.
  • Отсутствие баланса приводит либо к слепым зонам, либо к слишком дорогому regression suite.

Как мыслить как QA

  • Для каждого риска спрашивай: на каком уровне он обнаружится раньше, дешевле и надёжнее.
  • Продумывай проверки не только для UI, но и для контрактов, данных, правил и интеграций.
  • Используй уровни как стратегию, а не как обязательный чек-лист “проверить всё везде”.
📐

Чем раньше риск можно поймать на более низком уровне, тем меньше смысла ждать, пока он проявится на UI или в полном end-to-end сценарии.