🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 18.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
На протяжении большей части истории разработки программного обеспечения тестирование даже не выделялось в отдельную дисциплину. Разработчики создавали программное обеспечение, самостоятельно его тестировали и выпускали. Со временем, по мере того как системы становились сложнее, а дефекты в продакшене начали обходиться командам в значительные затраты времени и средств, появился отдельный этап тестирования. Однако он по-прежнему располагался в самом конце процесса разработки — непосредственно перед развертыванием.
Теперь представьте жизненный цикл разработки программного обеспечения как временную шкалу, которая идет слева направо: слева находятся требования и планирование, справа — релиз и эксплуатация. Традиционно тестирование выполнялось только в самом конце этой шкалы, непосредственно перед выпуском продукта. Это приводило к серьезным проблемам: ошибки, обнаруженные слишком поздно, требуют больших затрат времени и средств на исправление, релизы откладываются, а команды вынуждены постоянно устранять возникающие проблемы.
Исследование Ponemon Institute наглядно подтверждает это: уязвимости, обнаруженные на ранних этапах разработки, в среднем обходятся примерно в 80 долларов, тогда как исправление тех же самых уязвимостей после их попадания в продакшен может стоить около 7600 долларов.
Shift Left буквально означает перенос тестирования на более ранние этапы жизненного цикла разработки — «влево» по этой временной шкале. Вместо того чтобы быть заключительной проверкой перед релизом, тестирование становится непрерывной деятельностью, встроенной в каждый этап разработки, начиная уже со сбора требований.
Что такое Shift Left Testing
Shift Left Testing — это подход к обеспечению качества программного обеспечения, при котором тестирование переносится из роли финального этапа перед релизом в непрерывную совместную практику, интегрированную во все стадии жизненного цикла разработки. Вместо того чтобы рассматривать качество как контрольную точку, этот подход воспринимает его как общую ответственность, которая начинается с момента формирования требований и продолжается на этапах проектирования, разработки и развертывания.
Такая модель позднего тестирования была формализована в рамках методологии Waterfall, где требования, проектирование, разработка и тестирование выполнялись последовательно, линейно переходя от одного этапа к другому.
Почему подход Shift Left важен для DevOps?
Shift Left переносит обеспечение качества на более ранние этапы жизненного цикла разработки, позволяя выявлять проблемы тогда, когда их исправление обходится дешевле и требует меньше усилий, чем после того, как они стали частью готового продукта.
Ниже приведены основные преимущества подхода Shift Left.
Более низкая стоимость исправления дефектов
Ошибки, обнаруженные и устраненные на ранних этапах, обходятся значительно дешевле, чем дефекты, найденные уже после развертывания приложения. Стоимость исправления растет практически экспоненциально по мере продвижения дефекта по жизненному циклу разработки. Ошибка, обнаруженная на этапе проектирования, требует лишь небольшой части тех затрат, которые потребуются для ее устранения в продакшене.
Более быстрые циклы обратной связи
Интеграция тестирования непосредственно в конвейер CI/CD позволяет разработчикам практически мгновенно получать обратную связь о качестве кода. Благодаря такому короткому циклу проблемы выявляются спустя несколько минут после внесения изменений, а не через дни или недели, когда контекст уже утрачен и определить причину ошибки значительно сложнее.
Более высокое качество программного обеспечения
Поскольку ошибки устраняются до того, как они начинают влиять на пользователей, приложение становится более надежным и стабильным. Чем меньше дефектов попадает в продакшен, тем реже командам приходится устранять инциденты, выпускать срочные исправления (Hot Fix) и тем выше качество пользовательского опыта.
Более быстрый вывод продукта на рынок
Благодаря уменьшению количества дефектов и оптимизации процесса разработки команды могут быстрее выпускать новые версии программного обеспечения. Когда тестирование не откладывается на самый конец цикла разработки, релизы становятся более регулярными и предсказуемыми, а не стрессовыми и постоянно задерживающимися.
Более тесное взаимодействие между командами
Shift Left разрушает традиционную границу между разработчиками и QA. Когда тестирование становится общей ответственностью с первого дня работы над продуктом, команды начинают совместно отвечать за качество, а разработчики естественным образом пишут более структурированный и удобный для тестирования код.
Лучшие практики Shift Left Testing
В традиционной инженерии данных проверки качества выполняются поздно — после того, как конвейеры уже построены, а пользователи данных уже столкнулись с последствиями некачественных данных.
Это отражает классическую проблему Shift Right в разработке программного обеспечения, когда тестирование становится второстепенным этапом, а не фундаментальной частью процесса.
По мере внедрения платформ разработки данных (Data Developer Platforms) и платформ продуктов данных (Data Product Platforms) появляется возможность реализовать структурное решение, внедряя принципы Shift Left непосредственно в процессы создания, управления и доставки данных.
Ниже приведены лучшие практики реализации подхода Shift Left в DevOps с использованием платформ разработки данных.
Определяйте ожидания по качеству заранее, а не после разработки
Shift Left Testing требует, чтобы критерии приемки были сформулированы до начала разработки кода. Команды работы с данными и DevOps-команды должны определить требования к качеству еще до создания конвейеров.
Платформы разработки данных позволяют реализовать это с помощью контрактов данных (Data Contracts) и мониторинга SLO (Service Level Objective), обеспечивая согласованное понимание того, что означает «качественные данные», еще на этапе проектирования, а не после того, как пользователи столкнулись с проблемами.
Следуйте структурированному жизненному циклу продукта
Разработка конвейеров без четкого процесса приводит к ловушке «сначала создадим, потом исправим». Вместо этого следует рассматривать данные как продукт с формальным жизненным циклом.
Платформа разработки данных структурирует этот процесс в четыре этапа:
- Design — проектирование;
- Develop — разработка;
- Deploy — развертывание;
- Iterate — итерационное улучшение.
Процесс начинается с преобразования бизнес-целей в архитектуру еще до написания первой трансформации данных.
Качество и тестирование становятся частью каждого этапа, а не добавляются в самом конце.
Применяйте лучшие практики программной инженерии к данным
Конвейеры данных должны рассматриваться с такой же строгостью, как и программный код приложений.
Платформа разработки данных использует подход, основанный на артефактах, с полной интеграцией Git, что позволяет делать продукты данных:
- версионируемыми;
- доступными для проверки;
- пригодными для аудита.
Это позволяет применять такие практики, как:
- взаимное ревью кода;
- автоматическая проверка каждого коммита;
- безопасный откат изменений.
Это те же дисциплины, которые команды разработки программного обеспечения используют уже много лет для раннего обнаружения проблем.
Создавайте возможность обнаружения и повторного использования, чтобы предотвратить накопление проблем качества
Когда каждая команда создает собственную версию одного и того же набора данных, качество становится непоследовательным, а количество непроверенных вариантов увеличивается.
Платформы разработки данных делают продукты данных доступными для обнаружения и повторного использования различными командами.
Таким образом, один и тот же проверенный и валидированный набор данных может использоваться для:
- аналитики;
- маркетинга;
- финансовых задач;
- сценариев искусственного интеллекта.
Это позволяет устранить избыточность и технический долг качества, который возникает вместе с ней.
Встроенное управление (Embedded Governance)
Встроенное управление позволяет легко масштабировать процессы контроля качества для продуктов данных, обеспечивая согласованность и доверие от источника данных до момента их использования.
Вместо того чтобы управление качеством представляло собой последующий аудит, оно становится частью самой структуры продукта. Это является классическим примером применения принципов Shift Left.
Единый взгляд на Shift Left и Shift Right
Эти два подхода к тестированию не являются полными противоположностями. Скорее, Shift Left и Shift Right — это две стороны одной медали, две части единого непрерывного цикла обратной связи.
По мере того как организации модернизируют свои технологические стеки, переходя к облачным архитектурам, микросервисам и контейнерам, лучшей практикой становится использование одновременно двух стратегий: Shift Left и Shift Right.
Shift Left Testing снижает количество дефектов в программном обеспечении и ускоряет вывод продукта на рынок, тогда как Shift Right Testing помогает повысить надежность системы в продакшене, проверяя ее работу в условиях реального использования.
Кратко о главном
Shift Left Testing сегодня требует изменения мышления. Основная идея проста: чем раньше обнаружена проблема, тем дешевле и быстрее ее исправить.
То, что могло бы стоить около 60 долларов при исправлении на ранних этапах разработки, может увеличиться до 6000 долларов после попадания проблемы в продакшен (гипотетические значения). Уже сама эта разница демонстрирует важность такого подхода.
Стратегия Shift Left переводит качество из роли финальной контрольной точки в область непрерывной общей ответственности. Она:
- устраняет разделение между разработчиками, тестировщиками и заинтересованными сторонами;
- интегрирует тестирование на всех этапах жизненного цикла — от формирования требований до релиза;
- превращает CI/CD-конвейеры в системы постоянного контроля качества, а не просто инструменты доставки.
Со временем преимущества усиливаются.
Команды, которые последовательно внедряют практики Shift Left, выпускают продукты быстрее, тратят меньше ресурсов на повторную работу и создают программное обеспечение, которое лучше работает для конечных пользователей.
По мере того как команды работы с данными внедряют принципы платформ разработки, контракты, версионирование и управление качеством на этапе проектирования (governance-by-design), та же культура качества, которая изменила разработку приложений, будет менять подход к созданию и использованию продуктов данных.
Цикл Shift Left + Shift Right станет стандартом.
Ведущие организации не будут выбирать между этими двумя подходами. Они будут использовать:
- Shift Left — для предотвращения дефектов;
- Shift Right — для проверки устойчивости системы в реальных условиях эксплуатации.
Это позволит создать замкнутую систему обеспечения качества на протяжении всего жизненного цикла продукта.
FAQ
Q1. Какие существуют типы Shift Left Testing?
Существует четыре основных типа:
- Unit Testing — модульное тестирование;
- Integration Testing — интеграционное тестирование;
- API/Contract Testing — тестирование API и контрактов;
- UI Testing — тестирование пользовательского интерфейса.
Каждый из этих видов направлен на проверку определенного уровня приложения и применяется постепенно по мере продвижения разработки.
Q2. Как измерить успешность Shift Left Testing?
Существует пять основных метрик, которые помогают оценить эффективность:
- Defect Escape Rate: Количество дефектов, которые достигают продакшена. Со временем успешное внедрение Shift Left должно приводить к уменьшению количества таких ошибок.
- Defect Detection Distribution: Распределение обнаружения дефектов. Больше ошибок должно выявляться на ранних этапах жизненного цикла разработки и меньше — уже в продакшене.
- Mean Time to Detect (MTTD): Среднее время обнаружения проблемы. Цель — выявлять проблемы за минуты, а не за дни.
- Early-Stage Test Coverage: Покрытие тестами ранних этапов разработки. Рост покрытия модульными и интеграционными тестами показывает, что тестирование встроено в процесс разработки, а не добавлено поверх него.
- Cost Per Defect: Стоимость исправления дефекта. Снижение средней стоимости устранения ошибок показывает, что проблемы обнаруживаются и исправляются на наиболее выгодном этапе.
Q3. Что такое качество кода в рамках Shift Left?
Качество кода в подходе Shift Left означает внедрение проверок качества кода, таких как статический анализ, линтинг, ревью кода, на ранних этапах процесса разработки — до слияния кода или начала тестирования.
Вместо того чтобы обнаруживать проблемы качества поздно, на этапе QA или уже в продакшене, разработчики получают немедленную обратную связь относительно:
- поддерживаемости кода;
- уязвимостей безопасности;
- соблюдения стандартов разработки.
Эта обратная связь может поступать непосредственно в IDE разработчика или в момент создания коммита.
Главная цель проста: сделать качество привычной частью процесса разработки, а не последующей проверкой после завершения работы.
Перевод статьи «What is Shift Left Testing and Why is It Critical for DevOps Success?».