Пирамида тестирования: где искать баги дешевле

Пирамиду просят нарисовать даже junior-кандидатам — но ценится не картинка, а объяснение, откуда берётся такая форма.

Пирамида тестирования — модель распределения автотестов по уровням: много быстрых и дешёвых unit-тестов внизу, меньше интеграционных посередине, совсем немного медленных end-to-end наверху.

Вопрос 1: «Нарисуйте пирамиду тестирования и объясните, почему она такой формы»

Что на самом деле проверяет интервьюер

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

Развёрнутый ответ

Снизу вверх: unit → integration / API → end-to-end (UI). Чем выше уровень, тем тест реалистичнее — и тем он медленнее, дороже в поддержке и нестабильнее. Чем ниже — тем быстрее и точнее локализация дефекта: упавший unit-тест указывает на конкретную функцию, упавший e2e говорит лишь «где-то в цепочке из десяти шагов сломалось».

Посчитаем на цифрах, почему форму нельзя перевернуть:

unit, integration, e2e = 1200, 150, 40
sec = unit * 0.02 + integration * 0.5 + e2e * 35

print("Всего тестов:", unit + integration + e2e)
print("Прогон, минут:", round(sec / 60, 1))
print("Доля времени на e2e, %:", round(e2e * 35 / sec * 100))

Вывод:

Всего тестов: 1390
Прогон, минут: 25.0
Доля времени на e2e, %: 93

Сорок e2e-тестов — это 3% набора и 93% времени прогона. Добавьте ещё двести таких — и обратная связь превратится из «через 25 минут» в «завтра утром», а команда перестанет запускать тесты на каждый коммит. Именно скорость обратной связи, а не эстетика, задаёт форму пирамиды.

Вопрос 2: «Что такое антипаттерн „рожок мороженого“?»

Что на самом деле проверяет интервьюер

Видели ли вы, во что превращается автоматизация без стратегии.

Развёрнутый ответ

Перевёрнутая пирамида: гора ручных и UI-тестов сверху, тонкий слой unit-тестов снизу. Так получается естественным путём — UI-тесты пишутся «по тест-кейсам», их легко объяснить бизнесу, для них не нужен доступ к коду.

Последствия предсказуемы:

• прогон занимает часы, поэтому тесты запускают раз в сутки — обратная связь опаздывает;
• тесты нестабильны: любая правка вёрстки или сетевая задержка красит билд, команда привыкает к красному и перестаёт смотреть отчёты;
• дефект локализуется долго: падение на шаге «оформить заказ» может означать что угодно;
• стоимость поддержки съедает больше времени, чем ручная проверка тех же сценариев.

Хороший ответ добавляет: помимо пирамиды есть модель «трофей» (Testing Trophy), где основной вес приходится на интеграционные тесты — она популярна во фронтенде, потому что там unit-тест компонента без DOM мало о чём говорит. Знание альтернативы показывает, что вы не заучили одну схему.

Вопрос 3: «Как распределить проверки между уровнями на практике?»

Что на самом деле проверяет интервьюер

Умеете ли вы принимать решение «этот случай — на каком уровне», а не проверять всё через UI.

Развёрнутый ответ

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

Двадцать вариантов промокода не нужно кликать в браузере — достаточно одного e2e-сценария «промокод применяется», а остальные девятнадцать проверить на уровне API или unit.

Типичные ошибки кандидатов

• Рисуют пирамиду, но на вопрос «почему не наоборот?» отвечают «так принято» вместо аргументов о скорости и стоимости.
• Считают, что пирамида запрещает ручное тестирование. Она про автотесты; исследовательское тестирование живёт рядом и никуда не девается.
• Путают уровни с видами: называют «нагрузочное» уровнем пирамиды.
• Утверждают, что e2e-тесты не нужны совсем. Нужны — но как тонкий слой на критичных бизнес-путях.

Как ответить кратко

Пирамида — про распределение автотестов по уровням: широкое основание из быстрых unit-тестов, слой API и интеграционных посередине, тонкая верхушка из e2e. Форма задана стоимостью и скоростью обратной связи: чем выше уровень, тем тест медленнее, нестабильнее и хуже локализует дефект. Перевёрнутая пирамида — антипаттерн «рожок мороженого»: прогон длится часами, тесты «плавают», команда перестаёт им доверять. Практическое правило — проверять на самом низком уровне, где проверка ещё осмысленна, а через UI гонять только ключевые бизнес-сценарии.