Модель: этап × окружение × проверка

Классическая пирамида тестирования, которую популяризировал Мартин Фаулер в 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

На каждом этапе могут проводиться проверки, даже в момент написания кода Write. Типы проверок для каждого шага на схеме ниже. Результат предыдущего этапа определяет, имеет ли смысл переходить к следующему.

Что получилось

Стандартная пирамида тестирования говорит прежде всего о стоимости и количестве тестов в зависимости от их типа. Тесты – не единственный способ проверить, что система или сервис работает корректно, а сами проверки появляются уже на этапе написания кода и продолжаются после выхода в production. Я предложил смотреть на них в контексте этапа и окружения.

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

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку