Как ответить на вопрос «Что такое пирамида тестирования» на собеседовании QA

Зачем это спрашивают

Пирамида тестирования — способ договориться, сколько и каких автотестов писать. Интервьюер проверяет, понимаете ли вы, что автотесты бывают разных уровней и что у каждого уровня своя цена. Кандидат, который хочет «покрыть всё UI-тестами», через полгода получит медленный и нестабильный набор, которому никто не доверяет.

Вопрос задают не только автоматизаторам. Тестировщик, который проверяет вручную, тоже участвует в решении, какие проверки отдать автотестам, и должен понимать, на каком уровне ошибку поймают быстрее и дешевле. Обычно следом спрашивают, что вообще стоит автоматизировать. Это тот же разговор о цене и пользе, поэтому его удобно разобрать вместе.

Как построить сильный ответ

Назовите уровни снизу вверх, объясните форму через четыре свойства тестов и закончите тем, как это влияет на ваши решения.

Уровни

Модель популяризировал Майк Кон в книге «Succeeding with Agile». Слои называют по-разному, но смысл один:

Почему именно такая форма

Чем выше уровень, тем хуже тесты по четырём свойствам:

• Скорость. Модульный тест выполняется за миллисекунды, UI-тест поднимает браузер, ждёт загрузки страниц и сетевых запросов.
• Стоимость поддержки. UI-тест ломается при изменении вёрстки или текста кнопки, даже если логика не менялась.
• Стабильность. Чем больше движущихся частей — браузер, сеть, данные, асинхронная отрисовка, — тем чаще тест падает без реальной ошибки. Об этом подробнее в статье про flaky-тесты.
• Диагностика. Упавший модульный тест указывает на конкретную функцию. Упавший UI-тест говорит только «сценарий не прошёл» — причину ещё нужно искать.

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

Что автоматизировать, а что нет

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

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

Пример ответа

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

Частые ошибки

• Назвать уровни и не объяснить, почему пирамида сужается кверху.
• Считать, что UI-тесты «плохие» и их не нужно писать. Они нужны, просто их должно быть немного.
• Говорить «автоматизировать надо всё» — без расчёта окупаемости.
• Дублировать одну и ту же проверку на всех уровнях без причины.
• Путать модульные тесты с API-тестами: модульный проверяет код в изоляции, без сети и базы.
• Подавать пирамиду как строгий закон с точными пропорциями.

Пример на MarketCove

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

• Модульный уровень — у разработчиков: функция, которая решает, в какой статус можно перевести заказ из текущего, и форматирование цены.
• API-уровень — основная часть ваших проверок: каталог отдаёт товары по контракту, несуществующий товар даёт 404, созданный заказ появляется в GET /api/orders, /api/users/me без токена отвечает 401, неверные данные отклоняются. Пример простого теста на pytest:

import requests

BASE_URL = "https://shop.tomiddle.com"


def test_products_list_is_not_empty():
    response = requests.get(f"{BASE_URL}/api/products", timeout=10)

    assert response.status_code == 200
    assert len(response.json()) > 0

Тест выполняется быстро, не зависит от вёрстки и при падении сразу показывает код ответа. Точную структуру ответа стоит сверить со Swagger на /api/docs — например, список может лежать внутри объекта.

• UI-уровень — один-два сквозных теста: гость добавляет товар, оформляет заказ и видит номер заказа; покупатель после входа находит свой заказ в истории.

Десятки комбинаций полей формы и ответов API через UI проверять незачем — это та же логика, которую дешевле покрыть через API.

Задание для практики

Выпишите 15 проверок для оформления заказа и профиля в MarketCove: карточка товара, оформление гостем и под аккаунтом, вход и выход, история заказов, смена статуса. Для каждой решите:

1. На каком самом низком уровне её можно проверить?
2. Стоит ли её автоматизировать, и почему?

Затем откройте Swagger магазина на /api/docs, выберите две проверки уровня API и выполните их вручную в API-песочнице. Напоследок пройдите вопросы про Playwright и автотесты — там встречаются смежные формулировки про уровни и стабильность тестов.