Треугольник Фаулера
Классическая пирамида тестирования, которую популяризировал Мартин Фаулер в 2012 году показывает, что базовых тестов (быстрых и дешевых) должно быть больше, а сложных и дорогих сквозных тестов - меньше. Идея до сих пор полезна и хорошо запоминается, но одной пирамиды недостаточно, чтобы описать весь процесс обеспечения качества.
Наверняка вы видели десятки вариаций пирамиды, отличающихся составом слоёв, и все они по-своему правильные. Из моего опыта собеседований, когда спрашивают «расскажи про пирамиду тестирования», интервьюеру часто важно услышать именно набор уровней и типов тестирования. Ответ по классическому Фаулеру может выглядеть неполным.
Это подтолкнуло меня к мысли, что в практических обсуждениях акцент часто смещается от стоимости тестов к набору и расположению различных видов тестирования – от unit до e2e.
Этап х окружение х проверки
Я намеренно сместился от термина тестирование к «quality checks», поскольку не каждая проверка является тестированием.
Поговорим о свойствах, проверки происходят на всех этапах жизненного цикла программного обеспечения, и у каждой есть как минимум три контекста: на каком этапе выполняется, в каком окружении и что именно проверяет.
Выделим шесть основных этапов
Возьмем стандартный флоу жизненного цикла DevOps Infinity Loop, посмотрим на это через призму QA & Dev и уберем лишнее. Получилось 6 этапов: Write → Commit → Build → Verify → Release → Operate
Write Код в процессе написания
Commit Код готов к коммиту и пушу
Build Сборка
Verify Основной этап тестирования
Release Деплой
Operate Код в продакшене, мониторинг
Добавим окружения
Каждый этап выполняется в определенном окружении, Local → CI → dev-branch / staging → pre-prod → production
Local | CI | Staging | Pre-prod | Prod | |
|---|---|---|---|---|---|
Write | ● | ||||
Commit | ● | ||||
Build | ● | ||||
Verify (testing) | ● | ● | |||
Release | ● | ● | |||
Operate | ● |
На каждом этапе могут проводиться проверки, даже в момент написания кода Write. Типы проверок для каждого шага на схеме. Результат предыдущего этапа определяет, имеет ли смысл переходить к следующему.
Что получилось
Стандартная пирамида тестирования говорит прежде всего о стоимости и количестве тестов каждого типа. Тесты — не единственный способ убедиться, что система работает корректно, - проверки появляются уже на этапе написания кода и продолжаются после выхода в production, поэтому я предлагаю смотреть на них в контексте этапа и окружения.
Каждый следующий этап зависит от успеха предыдущего, и чем раньше найдена ошибка, тем меньше шагов приходится проходить до её исправления. А вот отсутствие обязательных проверок и размытые зоны ответственности рано или поздно отражаются на качестве системы в целом.
На схеме показаны не все виды тестирования, свою пирамиду лучше собирать под свою систему совместно с командой разработки, и руководителем.
