Пирамида тестирования

Пирамида тестирования

Введение

Как распределить тесты по уровням, чтобы они были эффективными и не превращались в дорогое удовольствие? В 2009 году Майк Кон предложил простую визуальную модель — пирамиду тестирования. Она стала стандартом де-факто в индустрии и помогает командам принимать решения о том, сколько тестов какого вида писать.

Три уровня пирамиды

        /\
       /  \
      / E2E \       ← Мало, медленно, дорого
     /--------\
    / Integration\  ← Средне
   /--------------\
  /   Unit Tests   \← Много, быстро, дёшево
 /------------------\

Уровень 1: Unit-тесты (основание пирамиды)

Unit-тесты проверяют отдельные функции, методы или классы в изоляции от остальной системы.

• Кто пишет: Разработчики
• Скорость: Миллисекунды (тысячи тестов за секунды)
• Стоимость: Дёшево писать и запускать
• Что находят: Ошибки в логике отдельных функций
• Количество: Должно быть больше всего — 70-80% от всех тестов

Пример: Функция calculateDiscount(price, percent) — unit-тест проверяет, что для 100 и 10% возвращается 90.

Уровень 2: Интеграционные тесты (средина пирамиды)

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

• Кто пишет: Разработчики и тестировщики
• Скорость: Секунды
• Стоимость: Дороже unit-тестов
• Что находят: Ошибки в стыках между компонентами
• Количество: Меньше, чем unit-тестов — около 20%

Пример: Тест API-эндпоинта /api/orders — проверяет, что сервис заказов корректно взаимодействует с базой данных.

Уровень 3: E2E / UI-тесты (вершина пирамиды)

End-to-End (E2E) тесты имитируют действия реального пользователя в браузере от начала до конца.

• Кто пишет: QA-инженеры по автоматизации
• Скорость: Минуты
• Стоимость: Дорого писать, запускать и поддерживать
• Что находят: Ошибки в полных пользовательских сценариях
• Количество: Минимум — 5-10% от всех тестов

Пример: Тест «Пользователь регистрируется → входит → создаёт заказ → оплачивает».

Почему форма пирамиды важна

Чем выше в пирамиде — тем:

• Медленнее выполняется тест
• Дороже его написать и поддерживать
• Сложнее найти причину падения (слишком много компонентов)
• Ненадёжнее (flaky tests — тесты, которые иногда падают без причины)

Поэтому большинство тестов должны быть внизу пирамиды.

Антипаттерн: Перевёрнутая пирамида (Мороженое)

 /------------------\  ← Много E2E тестов (дорого, медленно)
/  Integration Tests \
\--------------------/
        \/
       Unit         ← Мало (почти нет)

Если у тебя много E2E тестов и мало unit-тестов — это «антипаттерн мороженого». Такая пирамида:

• Медленно запускается (часы вместо минут)
• Часто даёт ложные падения
• Дорого поддерживается при изменении UI
• Не даёт быстрой обратной связи разработчикам

Где находится ручное тестирование в пирамиде

Ручное тестирование дополняет пирамиду, но не является её частью. Ручной тестировщик работает преимущественно:

• На уровне E2E — проверяет полные пользовательские сценарии
• За пределами пирамиды — исследовательское тестирование, UX, edge cases

Исследовательское тестирование — это то, что автоматика никогда не заменит: тестировщик исследует систему без заранее написанных сценариев, пытается её «сломать» творческим способом.

Распространённые ошибки

• Слишком много E2E тестов. «Раз они проверяют всю систему — давайте их и писать». Это дорого и медленно.
• «Unit-тесты — дело разработчиков, не наше». QA должен понимать пирамиду и влиять на стратегию тестирования команды.
• Игнорировать исследовательское тестирование. Автотесты не заменяют человеческий взгляд на систему.

Что запомнить

• Пирамида Кона: Unit (много) → Integration (средне) → E2E (мало)
• Основание пирамиды: быстро, дёшево, много тестов
• Вершина пирамиды: медленно, дорого, мало тестов
• Антипаттерн «мороженое» — когда перевёрнутая пирамида
• Ручной тестировщик работает на уровне E2E и исследовательского тестирования