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

• Стандартная
• Расширенная 
• Песочные часы (DevOps)
• Сота
• Кубок
• Вулкан
• Мороженко!
• Перевернутая пирамида
• Пример тестовой пирамиды на реальном проекте — действия и инструменты

Пирамида тестирования — понятие, обозначающее уменьшение количества динамических тестов по мере продвижения проекта.

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

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

Самая старая, и все еще самая широко применяемая, как бы эталонная тестовая стратегия, впервые подробно описанная в книге Майкла Кона “Succeeding with Agile”. Стандартная пирамида в самом «олдовом» варианте состоит всего из 3 уровней: юнит-тесты, сервисные тесты, и тесты интерфейса.

• Юнит-тесты, или модульные, самые «дешевые и быстрые». Под «юнитом» имеется в виду не только, собственно, модуль кода, а вообще любая небольшая и логически ограниченная часть кода, которая может быть и классом, и функцией, или даже одним методом в классе. Юнит-тестирование проверяет, что отдельно взятый модуль работает как положено, выполняет свою функцию. Юнит-тестов больше чем всех остальных [вместе взятых], потому что в приложении как правило много модулей, соответственно модульных тестов требуется много, и они простые.
• Сервисные тесты, под этим здесь имеются в виду интеграционные тесты, проверяющие коммуникацию, взаимодействия между юнитами и более крупными чем юнит сущностями — компонентами. В стандартной пирамиде интеграционных тестов намного меньше чем модульных. 
• ТестыЕ2Е / UI, верхнего уровня, проверяющие соблюдение требований к интерфейсу и общих требований к продукту. Из-за сложности, трудоемкости, и большой себестоимости таких тестов, их количество по возможности стараются ограничить, и в стандартной пирамиде тестирования интерфейсных тестов намного меньше чем модульных и сервисных.

Иногда указывают еще «фундамент пирамиды» — статические проверки:

Расширенная пирамида тестирования

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

Компонентные тесты выделяются в отдельную категорию — как бы «промежуточная стадия» между модульными и приемочными; это тестирование компонентов более крупных чем модули.

Также в расширенной пирамиде появляются ручные исследовательские тесты. 

При этом сохраняется закономерность «чем выше, тем меньше тестов»; чем ближе к концу цикла, тем сложнее тесты и меньше их количество.

Песочные часы (DevOps)

В DevOps делают упор на тщательный мониторинг процессов. DevOps рассчитан на разработку с частыми деплоями. Поэтому к стандартной тестовой пирамиде «присоединяются» последующие процессы Logging-Monitoring-Alerting.

• Журналирование (Logging) — налаженное протоколирование (фиксация) информации о происходящем в приложении
• Мониторинг (Monitoring) — автоматизированное наблюдение за состоянием приложения и его серверной части
• Оповещения (Alerting) — налаженный процесс автоматических оповещений о проблемных точках приложения, чтобы их по возможности немедленно устранить

Сота

Специфическую тестовую пирамиду представили в компании Spotify 3 года назад. Такая стратегия заточена под микросервисную архитектуру, в которой самая большая сложность часто состоит не так в самом сервисе, как в его взаимодействиях с другими сервисами. Тестовая пирамида, точнее уже сота, состоит из 3 слоев: тестирование имплементации, интеграционные тесты, и интегрированные тесты.

• Интегрированные (integrated) тесты — тесты, которые проходят или падают в зависимости от правильности взаимодействий с другой (внешней) системой.
• Интеграционные (integration) тесты проверяют правильность работы основного сервиса в более изолированном виде чем предыдущие, фокусируясь на точках взаимодействия и совершенствуя их работу.
• Тесты имплементации сфокусированы на изолированных частях кода, как бы специфический аналог юнит-тестирования.

О важнейших отличиях между юнит-тестами и интеграционными почитать здесь.

Кубок

Концепция представлена тоже в 2018 году, признанным экспертом в QA Кеннетом Доддсом. Предполагается, что первичная цель тестирования состоит в достижении как можно большего «освобождения от багов». Но автор модели не стремится к 100% тестовому покрытию, наоборот подчеркивая что это плохая идея сама по себе, ухудшающая качество продукта, когда тестовое покрытие превысило примерно 70%. Автор концепции, исходя из своего опыта, полагает, что по мере продвижения проекта к верхушке тестовой пирамиды, уверенность в качестве тестов (а значит и количество их) должна быть максимальной на среднем уровне пирамиды — на ее интеграционном уровне. Но также большое внимание должно уделяться предварительному уровню пирамиды — статическому тестированию, которое проводится перед модульным. Именно такой вид тестовой пирамиды, такой баланс количества тестов и затрат на их создание/выполнение автор считает оптимальным.

Даже так:

Вулкан

Еще один вариант тестовой пирамиды — «извергающийся вулкан». Это, по ощущениям, часто встречающийся вариант уровней тестирования в современной разработке (2023). Пирамида, точнее «гора» начинается со стандартных и всегда необходимых юнит- и интеграционных тестов; с добавлением, после юнит-, также и компонентных тестов; далее, после тестов интеграции — тестов API, которые уже являются необходимыми в 99% современных проектов; и тестов интерфейса и юзабилити, которые сейчас тоже незаменимы. 

Над горой парит «облако», то ли дым извержения, это у нас исследовательские тесты, и ручные тесты, проводимые опытными тестировщиками в крупных QA-командах. Количество таких тестов может быть достаточно большим, а вообще неопределенно и непредсказуемо, как и длительность ручного тестирования.

Поклонники стратегии «вулкана» полагают, что классическая пирамида уровней тестирования уже отжила свое, плохо учитывает рыночные риски проектов, что нужно больше опираться на риск-тестирование, и что старое-доброе ручное тестирование (включая исследовательское), и в отдаленном будущем нельзя заменить никогда и ничем [прим.ред. — у нас есть статья об этом].

Версия «вулкана»:

Мороженое

Некоторые считают эту концепцию «антипаттерном» тестирования, в то время как другие так не считают, относятся вполне серьезно и применяют на практике, и проблем не испытывают. «Мороженым» насмешливо назвал один из создателей изначальной концепции пирамиды уровней тестирования, Алистер Скотт, говоря о «переворачивании» пирамиды как об очень-очень плохой практике; только в этом варианте ситуация (якобы) усугубляется еще и избыточным количеством ручных тестов; с точки зрения этого QA-гуру в корне неправильно и вообще губительно.

Скотт и его последователи полагают, что GUI-тестов, не говоря уж о ручных, должно быть минимум-миниморум в любом проекте; также с подозрением относятся к любым практикам «расширенного интеграционного», и указывают на недостаточное внимание к фундаментальному уровню юнит-тестов, что якобы гарантированно провоцирует проблемы. 

Перевернутая пирамида

Тем не менее, перевернутая пирамида на практике встречается весьма часто. Так происходит видимо потому, что очень легко ИТ-компании «впасть в подобное искушение»; или по недостатку опыта в QA-отделе или вообще в компании, или из соображений экономии, или просто в компании не принято стимулировать разработчиков писать юнит-тесты в достаточном объеме, во всем полагаясь на QA-отдел. Скотт называет это «недостаточной культурой тестирования», и восхваляет TDD-разработку (разработка через тестирование, когда тесты пишутся одновременно или лучше перед написанием кода). 

Есть и другие мнения: ему возражают, что даже сейчас, с повсеместным внедрением Agile/Scrum/DevOps и прочих полезных методологий, разделение труда между Dev- и QA-отделами все еще очень отчетливое, тестировщики не имеют доступа к кодовой базе, и если разработчиков не заставляют писать юнит-тесты, то «фундаментные тесты», будь то юнит-, компонентные или интеграционные, просто некому писать, и все возможное (и невозможное) с QA продукта делают тестировщики. Вследствие чего количество «тестов верхнего уровня» закономерно увеличивается, и с этим ничего нельзя поделать. Также критики Скотта указывают, что в современных проектах стейкхолдеры и вообще менеджмент склонны требовать «релиз к сроку любой ценой», не особо вникая в перипетии взаимоотношений между отделами. Команды вынуждены регулярно демонстрировать стейкхолдерам «то что есть», и быстрые е2е-тесты от QA-отдела — единственный разумный выход. 

В большинстве проектов это работает и неплохо, но другой авторитет, Джон Стивенсон, предупреждает, что «ваше мороженое обязательно потечет», то есть избыточное количество ручных тестов способно разрушить любой проект. С другой стороны, QA-гуру Мартин Фаулер считает, что если высокоуровневые тесты быстрые, достаточно надежные, и экономные (если писать их и поддерживать получается легко и быстро), то так вполне можно делать без ущерба для качества (то есть полагаться в основном на е2е). Тем более, что мелкие некритичные дефекты на уровне юнитов, даже будучи незамеченными/сознательно пропущенными, не факт что обязательно спровоцируют глобальные проблемы на высших уровнях. 

Пример пирамиды тестов на практике — действия и инструменты

В реальных проектах уровни и применяемые инструменты могут выглядеть так:

Здесь множество вариантов тестовых пирамид (42!), с объяснениями и со ссылками на статьи и книги.

Источники: 1,2,3,4