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

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

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

Друзья, подпишитесь на наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

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

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

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

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

статическое тестирование
+ статическое тестирование

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

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

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

Пирамида — Юниты и компоненты приложения
Пирамида — Юниты и компоненты приложения

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

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

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

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

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

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

Сота

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

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

Кубок

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

Пирамида тестирования — Кубок
Пирамида тестирования — Кубок

Даже так:

Пирамида тестирования — Кубок. Версия rededit
Версия на Реддите

Вулкан

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

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

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

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

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

Версия «вулкана»
Еще одна версия

Мороженое

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

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

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

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

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

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

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

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

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

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

Инструменты на разных уровнях
Инструменты на разных уровнях
ПриоритетЧто делаютКлассическое название операцийИнструменты
1Проверку качества кодаСтатическое тестированиеESLint, Prettier, SonarCube
2Тестируют взаимодействияИнтеграционное тестированиеCypress и Playwright
3Сценарное тестированиеСквозное тестированиеCypress и Playwright
4ПроизводительностьТестирование производительностиLighthouse (CI)
5Контроль логики приложенияЮнит-тестированиеJest
6Визуальное тестированиеUI-тестированиеStorybook
ВсегдаБезопасностьТестирование безопасностиSynk (SAST), OWASP (DAST)
Перед релизомНагрузочноеНагрузочное тестированиеJMeter

Источник: «Пирамида тестирования».

1 комментарий к “Пирамида тестирования”

  1. Пингбэк: Большой учебник по тестированию

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *