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

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

Пирамида тестирования - это метафора которая представляет собой “грамотную” пропорцию между разными видами тестов, баланс между скоростью работы тестов, их достоверностью и стоимостью их разработки и поддержки.

Впервые пирамиду тестирования упомянул в 2009г Майк Кон в книге “Succeeding with Agile: Software Development Using Scrum”

Какой формы должна быть пирамида тестирования?

Правильной!

~ 5-10% end-2-end тестов. е2е-тесты это тесты, которые тестируют систему извне, чаще всего через интерфейс пользователя. Это самые “дорогие”, но наиболее исчерпывающие тесты. Писать их значительно дольше и когда они “падают” диагностика причины “падения” занимает гораздо большее времени, чем для других тестов. Cкорость их “прогона” самая низкая, однако они имеют наибольший охват и достоверность, т.к. проверяют всю систему от начала до конца. Чаще в таких тестах проверяют позитивный сценарий, остальные тесты проверяют негативные сценарии.

~ 15-20% интеграционных тестов. Эти тесты проверяют взаимодействие (интеграцию) модулей системы (М. Фаулер ещё называет их “подкожные”). Интеграционные тесты проверяют систему без пользовательского интерфейса. Чем более сфокусированы такие тесты, тем они быстрее и надёжнее. Охват таких тестов меньше, что влияет и на скорость их прогона.

~ 70-80% быстрых unit-тестов, которые проверяют логику в одном или и нескольких внутренних модулях системы. Скорость прогона одного такого теста занимает доли секунды, поэтому unit-тетстов должно быть большинство. Недостаточность охвата таких тестов компенсируется количеством тестов и более высокоуровневыми тестами.

Зачем нужна пирамида тестирования?

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

Анти-паттерн

Важно избегать анти-паттерна “рожок мороженого”, когда пирамида “переворачивается” и пропорция нарушается - пишется большое количество “дорогих” e2e-тестов и практически нет низкоуровневых unit-тестов. Часто это бывает когда в организационной структуре существует отдельная группа контроля качества и нет настроенной коммуникации с разработчиками, которые к тому же, практически не пишут автотесты.

Этот анти-паттерн приводит к длительный диагностике и правке дефектов и задержкам при поставке ПО.