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

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

Что такое пирамида тестирования

Пирамида тестирования выглядит следующим образом:

Как видите, пирамида состоит из трех уровней:

• Юнит-тесты — нижний и самый широкий уровень пирамиды
• Интеграционные тесты — средний уровень
• Системные тесты — самый высокий и узкий уровень пирамиды

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

Такая структура помогает эффективно организовать тестирование и обнаруживать дефекты на ранних этапах разработки.

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

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

Юнит-тесты самые простые в поддержке:

• Они быстрые. Чтобы выполнить юнит-тесты, программист просто запускает их на своем компьютере. Ему не нужно тратить время на сборку дистрибутива и развертывание на тестовом стенде
• Их редко нужно переписывать. Они проверяют короткие фрагменты кода, которые редко меняются от изменений в других частях системы

В этом-то и состоит одно из главных преимуществ пирамиды тестирования — она подталкивает к более активному использованию юнит-тестов, которые удобны в поддержке.

Намного сложнее поддержка системных тестов:

• Они изменяются вместе с функциональностью. Часто они завязаны на конкретные элементы страницы, поэтому изменение требований может вести к полной переработке тестов
• Они медленные. Системные тесты часто требуют больше времени на подготовку и выполнение
• В них сложнее разобраться. Представим такую ситуацию — утром программист вносит изменения и отправляет код. На следующий день тестировщик берет код и проверяет его до вечера. В итоге программист получит обратную связь только через два дня. Это растягивает рабочий процесс, потому что за время ожидания программист уже забыл контекст задачи

Из-за всех причин выше, важно, чтобы команда придерживалась принципов пирамиды тестирования. Другими словами, тесты более высокого уровня должны проверять только то, что невозможно проверить на предыдущих уровнях. С таким подходом пирамида будет устроена правильно: на вершине — системные тесты, затем интеграционные, а на нижнем уровне — множество юнит-тестов.

Иногда тестировщики повторно тестируют то, что разработчики уже проверили юнит-тестами — это приводит к двойной работе и лишним ошибкам. Так происходит, потому что тестировщики и разработчики не обмениваются информацией.

Есть еще одна сложность, которая возникает из-за недостатка коммуникации — неочевидная зона ответственности за интеграционное тестирование. В одних командах оно автоматизированное, поэтому им занимаются разработчики, другие команды проводят ручное тестирование силами тестировщиков.

Пирамида считается самым эффективным подходом к тестированию. Но кроме нее, существуют и другие системы, например:

• Перевернутая пирамида — мало юнит-тестов, среднее количество интеграционных тестов, много системных тестов
• Песочные часы — много юнит-тестов, мало интеграционных тестов, много системных тестов
• Стек — равное количество тестов всех трех уровней

Эти схемы могут подходить для каких-то специфичных проектов, но чаще они указывают на неэффективный подход к тестированию.

---

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты