Что показали 15 лет работы с пирамидой тестирования

Перевод статьи «The Test Pyramid: Insights from 15 Years of Experience».

🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 16.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks 

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

Пирамида тестирования долгое время была краеугольным камнем QA-стратегий. Она способствует улучшению эффективности, скорости и рентабельности тестирования. Но за 15 лет работы в тестировании я пришел к выводу, что ее эффективность в значительной степени зависит от контекстаот контекста: команды, продукта и архитектуры системы. В этой статье продемонстрирую нюансы применения пирамиды в разных типах проектов — от современных до легаси.

Типичная модель пирамиды тестирования:

Идеал против реальности

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

• широкое основание из юнит-тестов;
• интеграционные тесты — слой чуть меньше;
• тонкий слой end-to-end тестов;
• редкие ручные проверки при необходимости.

Эта модель развилась как альтернатива антипаттерну «мороженое в рожке», где пирамида переворачивается и большую часть набора составляют end-to-end (E2E) тесты. Такая структура направлена на обеспечение быстрой обратной связи и снижение затрат. Однако реальность часто бывает совсем другой. Во многих организациях, особенно тех, которые работают с микрослужбами и бессерверной архитектурой, пирамида переворачивается или меняет свою форму, причем E2E-тестов становится больше, чем остальных. Почему так происходит?

Архитектура и ее влияние на тестирование

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

1. Микросервисы и фрагментация систем
   

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

2. Бессерверные архитектуры и их проблемы

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

3. Монолиты и обратная пирамида

• Монолитные архитектуры часто приводят к расширению базы E2E-тестов, формируя то, что некоторые называют «обратной пирамидой».
• Это происходит потому, что что рефакторинг монолита ради увеличения числа юнит- и интеграционных тестов требует больших усилий. В результате команды чаще опираются на E2E-тесты для проверки надежности системы.
  

4. Роль тестов E2E в укреплении доверия

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

Человеческий фактор: доверие и ответственность

То, как работает пирамида, зависит не только от архитектуры, но и от команды:

1. Доверие к нижним слоям

• Если разработчики и QA-специалисты не доверяют юнит- или интеграционным тестам, они будут в большей степени полагаться на E2E-тесты.
• Эта неуверенность может быть вызвана нестабильным окружением, плохо поддерживаемыми тестами или слабыми инструментами.
  

2. Совместная ответственность за качество

Это ключевой момент, но его очень сложно измерить.

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

Стратегии выравнивания пирамиды в соответствие с реальностью

1. Адаптируйтесь к своему контексту
   

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

2. Инвестируйте в стабильность тестов и инструменты

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

3. Формирование культуры качества

• Создавайте культуру, в которой качество является ответственностью каждого. Поощряйте разработчиков писать и поддерживать юнит- и интеграционные тесты.
• Объясняйте заинтересованным сторонам цели и ограничения каждого уровня тестирования.
  

Новая визуализация?

Вместо традиционной пирамиды можно визуализировать стратегию тестирования как динамическую форму — например, в виде «кривой тестирования» или «волны тестирования», которая адаптируется под потребности проекта. Вот как это сделать:

• В микросервисной архитектуре кривая может показывать большую долю интеграционных тестов, так как их можно запускать и поддерживать без чрезмерных усилий. Это представлено на модели Test Diamond ниже.
• Бессерверная и событийно-ориентированная архитектура часто включает в себя несколько слабо связанных между собой компонентов, которые должны реагировать на триггеры. Контрактные тесты обеспечивают корректное взаимодействие между сервисами, а интеграционные и E2E-тесты проверяют полный жизненный цикл события. Поэтому можно использовать либо Honeycomb, либо Test Diamond.
• В монолитной системе «волна» может иметь широкую базу E2E-тестов, напоминая обратную пирамиду.
• Рассматривая тестирование нативных мобильных приложений и/или фронтенд-фреймворков, таких как React Native, можно ориентироваться на Testing Trophy, добавляя при необходимости ручные проверки для конкретных случаев.

Разные подходы могут применяться в зависимости от контекста, но идеальный вариант — применять их как основу и адаптировать под зрелость команды и требования продукта.

Заключение

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