Команды, которые работают с микросервисной архитектурой и сложными распределенными системами, сталкиваются с известными вызовами: работа над новыми продуктами замедляется, растут трудозатраты на тестирование и обеспечение отказоустойчивости. Классическая водопадная модель разработки становится долгой и дорогой. Сократить время от идеи до реализации помогает подход Shift Left.
Shift Left («сдвиг влево») — это стратегия, направленная на максимально быстрое выявление и устранение дефектов в жизненном цикле продукта. Суть подхода заключается в переносе основной нагрузки тестирования на ранние этапы разработки, где формулируются требования и создаются первые прототипы.
В статье расскажем, почему баги дешевле находить до продакшена, как работает Shift Left на практике и почему высокая культура качества в команде помогает успешно внедрять эту стратегию.
Тестирование на более ранних этапах: что сдвигать влево?
Как работает классическая модель разработки? Все начинается с идеи, затем идут этапы сбора требований, проектирования, реализации, тестирования, и наконец, релиза. На каждом из этих этапов появляются новые риски, и чем позже выявляется проблема, тем дороже и сложнее ее исправлять.В Shift Left разработчики стараются проверять все процессы как можно раньше:.
1. Тестирование требований
Начать тестирование можно еще до того, как будет написан код. На этапе сбора требований важно сразу проверять их на логические несоответствия и реалистичность. Это позволит избежать ситуаций, когда в процессе разработки выяснится, что требования были плохо сформулированы или неверно поняты. Такие недочеты могут стать причиной значительных переделок и роста трудозатрат.2. Проектирование системы
На стадии проектирования можно заранее заложить основы для тестирования. Если привлекать на этот этап инженеров-тестировщиков, то они лучше поймут, как будет устроена архитектура, как она будет влиять на функциональность системы. Специалисты смогут заранее увидеть риски возникновения фундаментальных дефектов проектирования.3. Подготовка инфраструктуры под автотесты
Чем раньше инфраструктура будет настроена для автоматических тестов, тем быстрее можно будет начать тестирование. Это касается и интеграций с CI/CD, и настройки окружений для тестирования. Если тестовая среда и инструменты под автотесты настроены с самого начала, в дальнейшем это ускорит процесс разработки.4. Компоненты системы
Компонентные тесты проверяют, корректно ли работают отдельные части системы. Их можно запускать на ранних этапах, когда компоненты разрабатываются — не дожидаясь полной сборки всей системы.5. Интеграции
Интеграционные тесты проверяют, как различные компоненты одной системы взаимодействуют друг с другом. Как и компонентные тесты, их можно начинать до полной сборки системы и выполнять в изолированном окружении. Также к интеграционным тестам можно отнести контрактные тесты — хотя обычно их выделяют отдельно. Отличие этих тестов в том, что они проверяют взаимодействие не между компонентами внутри системы, а между несколькими системами — например, двумя микросервисами. Их задача — убедиться, что это взаимодействие соответствует заранее оговоренными правилам, или «контрактам».Чем раньше, тем дешевле
Чем раньше дефекты обнаруживаются в процессе разработки, тем дешевле их исправление, как в плане времени, так и ресурсов.Когда тестировщики находят баги на поздних этапах разработки, например, в stage-окружении или вообще в продакшене, исправление требует дополнительных усилий. Нужно потратить много времени на анализ, поиск причин проблемы, настройку окружения для тестирования. Это замедляет процесс выпуска продукта и увеличивает затраты времени и ресурсов.
Допустим, баг, который можно было выявить и устранить на этапе разработки компонента, показал себя только в продакшене. Работа над ним потребует тесты всей системы, возможно, доработки инфраструктуры. Это — изменения бизнес-логики, ухудшение пользовательского опыта, затраты в часах работы специалистов.
С другой стороны, если тестирование и проверка качества происходят на более ранних этапах, как только сформулированы требования и началась разработка компонентов, ошибки выявляются быстрее. Тестирование требований помогает избежать серьезных переделок в будущем, а раннее покрытие кода тестами уменьшает вероятность дефектов на поздних стадиях.
Shift Left на практике: quality gates и pre-commit хуки
Расскажем о конкретных инструментах, которые помогают выстроить Shift Lift. Рассмотрим два важных механизма: pre-commit хуки и quality gates (QG).Pre-commit хуки: автоматизация тестирования до внесения изменений в репозиторий
Pre-commit хуки — это механизм, который запускается автоматически перед каждым коммитом в систему контроля версий, например, Git.Как это работает: разработчик вносит изменения в код и хочет их зафиксировать. Прежде чем они сохранятся в репозитории, срабатывает pre-commit хук, который выполняет быстрые проверки: линтеры, форматирование, статический анализ, и не дает закоммитить код, если что-то не так. Это первый фильтр, который отсекает самые простые ошибки еще до того, как код попадет в репозиторий.
Pre-commit хуки не заменяют полноценное тестирование, но работают как «гигиенический минимум»: они не пропустят в репозиторий код с нарушениями стиля, очевидными синтаксическими ошибками или забытыми отладочными конструкциями. Основная нагрузка по тестированию ложится на следующий этап — quality gates.
Quality gates: централизованные проверки на ранних этапах
Quality gates — это система автоматических проверок, которые выполняются перед внесением кода в основную ветку. В отличие от pre-commit хуков, которые срабатывают при локальном коммите, quality gates действуют на более высоком уровне — на этапе интеграции, когда код готов к объединению с основной веткой.Как это работает: когда разработчик коммитит код или создает пулреквест, его изменения не попадут в основную ветку, пока не пройдут серию обязательных проверок в CI/CD-пайплайне. Это юнит-тесты, статический анализ кода, проверка покрытия тестами и другие критерии качества. Те же проверки повторяются после простановки тега на коммит --- перед тем, как код уйдет дальше по пайплайну.
В Газпромбанке мы выстроили централизованные QG именно на этом уровне: юнит-тесты прогоняются при каждом коммите и создании пулреквеста, а процент покрытия кода тестами мы постепенно увеличивали. Такой подход позволил снизить количество дефектов в два раза --- за счет того, что основная нагрузка тестирования сместилась на ранние этапы интеграции, а не откладывалась до stage-окружения.
Что меняется для тестировщика
В классической модели тестировщик получает готовую сборку и ищет в ней дефекты. В Shift Left его работа начинается гораздо раньше.Участие в ревью требований. Тестировщик подключается еще на этапе, когда требования только формулируются. Его задача — находить противоречия, неоднозначности и пропущенные сценарии до того, как по этим требованиям начнут писать код. Вопрос «а что произойдет, если пользователь сделает вот так?» дешевле всего задать именно здесь, а не после релиза.
Проектирование тестовой модели параллельно с архитектурой. Когда тестировщик присутствует на design review, он видит, как устроена система, где ее слабые места и какие интеграции несут наибольший риск. Это позволяет проектировать тест-кейсы и тестовые сценарии не по готовому продукту, а вместе с ним и закладывать проверки на те участки, которые с наибольшей вероятностью сломаются.
Ранняя подготовка автотестов. Вместо того чтобы писать автотесты после разработки фичи, тестировщик готовит их параллельно с разработкой или даже до нее. На основе спроектированных контрактов и спецификаций API. К моменту, когда код готов к ревью, автотесты уже могут ждать его в пайплайне.
Смена фокуса. Shift Left меняет саму роль тестировщика. Вместо человека, который ищет ошибки в готовом продукте, он становится тем, кто помогает команде не допускать их. Это более проактивный тип работы, требующий понимания продукта и взаимодействия с разработчиками и аналитиками.
Почему Shift Left не работает без культуры качества
Если воспринимать Shift Left только как набор инструментов, подход, скорее всего, не сработает. Его успех во многом зависит от культуры качества в команде — без нее даже самые лучшие практики не дадут должного эффекта.Внедрение Shift Left требует осознания важности этого подхода каждым участником команды. Можно настроить автоматические тесты, начать использовать pre-commit хуки и quality gates, но если разработчики не понимают, зачем это нужно, или не следуют процессам последовательно, все усилия могут быть напрасными.
Когда команда осознает, что тестирование на ранних этапах будет отнимать меньше времени в будущем и ускорит разработку, это становится частью ее ежедневной практики.
Например, видя слишком большой мердж-реквест, кто-то из разработчиков может предложить разбить его на более мелкие, чтобы улучшить тестируемость и уменьшить риски. Он может этого и не делать, но в том-то и есть вся соль культуры качества — с ней люди становятся более проактивными и беспокоятся не только за свой участок работы, но и за весь результат в целом.
Важно, чтобы подход Shift Left не воспринимался как нечто дополнительное, некий «прицеп в конце» процесса. Он должен быть естественной частью разработки — только тогда можно ожидать ускорения работы.
Вызовы при внедрении Shift Left
Shift Left сложно внедрять с наскока, по щелчку пальцев. Командам, которые начинают его использовать, приходится вносить изменения в процесс разработки — а еще они сталкиваются с рядом вызовов.1. Разработчикам, возможно, придется перенимать роль тестировщиков
При Shift Left процесс работы можно выстроить таким образом, что разработчик и тестировщики будут работать вместе уже на стадии проектирования. Однако проще может быть обучить разработчиков тестированию: если они сами умеют искать ошибки, то практически сразу после внесения изменений в код поймут, стало хуже или нет. Это не значит, что инженеры-тестировщики больше будут не нужны, просто разработчики возьмут на себя больше ответственность за качество кода.2. Тестировщикам придется быть ближе к разработке
Движение работает в обе стороны. Если разработчики осваивают тестирование, то и тестировщикам приходится глубже погружаться в техническую сторону продукта. Раннее тестирование требует понимания архитектуры приложения, умения читать код и разбираться в интеграциях между сервисами. Тестировщик, который подключается на этапе проектирования, не сможет приносить пользу, если для него архитектурная схема не понятна. Shift Left повышает планку технических компетенций для всей команды, не только для разработчиков.3. Интеграция автотестов на ранних этапах разработки
Shift Left требует пересмотра подходов к качеству, сборке и тестированию. Один из вызовов — интеграция автоматических тестов на ранние стадии разработке, особенно если раньше они проводились только в конце.4. Увеличение нагрузки на команду
Раннее тестирование увеличивает количество проверок и тестов, что, по крайней мере на первых порах, может привести к росту нагрузки на команду разработки. Однако затраченное время окупается на поздних этапах.
Рациональный выбор подхода: Shift Left или традиционная модель
Подход Shift Left не означает, что традиционная модель разработки должна быть забыта. Просто там, где это рационально, можно использовать Shift Left. Например, когда изменения в коде ограничены узкой функциональностью. Или при непрерывной интеграции, где важно быстро тестировать небольшие изменения — а не дожидаться, пока тестировщики все проверят.Для более сложных систем, где требуется комплексная проверка или фокус на системных тестах, водопадная модель все еще может быть полезна. Комбинация подходов может позволить выстроить более эффективную и гибкую модель разработки.
.png)
