Shift left security что это
Shift left security что это
Сейчас уже многие говорят о переносе процесса тестирования на ранние стадии разработки. Как же так? Ведь всего лишь несколько недель назад тестирование двигалось вправо, ближе к концу жизненного цикла. Где вы сейчас? Не стоит размышлять о переносе тестирования на ранние либо поздние этапы, без осознания его текущей позиции.
Впрочем, вначале давайте рассмотрим преимущества раннего и позднего тестирования, с учетом того, какие потребности будут покрыты или, что будет улучшено за счет такого смещения.
Чтоб последующая информация воспринималась легче, давайте-ка добавим немного визуализации. Поскольку мы уже упоминали автомобильную коробку переключения передач, представьте ее в виде набора из пяти шестерен с разным количеством зубьев на каждой.
Классика жанра: третья передача
Увы, но это текущее положение вещей в большинстве компаний. На этапе разработки проводятся только основные и технические проверки. Есть специальная система тестирования, в которой и выполняется проверки качества продукта. Все как обычно: разработчики пишут код, а тестировщики проверяют функциональность продукта, в том числе в связке с другим софтом.
Тестируемые приложения «упакованы» таким образом, что общаются друг с другом только посредством специально разработанного функционала, как правило, с ограниченными возможностями. Несмотря на то, что подобная конфигурация довольно-таки статична, для ее поддержки и обслуживания требуется «тонна» усилий, глубокое понимание принципов работы каждого отдельного продукта, знание применяемых технологий и общих принципов рабочего процесса. Поскольку каждое приложение связано с определенной командой разработчиков (иногда даже находящихся в разных компаниях), то в случае появления «багов» вы сильно зависите от того парня, который непосредственно написал проблемный код. А что если сейчас он недоступен? Тогда у вас проблема! Выход продукта на рынок снова откладывается, поскольку нужная вам информация пока недоступна.
Однажды мы сотрудничали с банком, который использовал специальную систему, сконфигурированную таким образом, чтобы тестирование выполнялось на каждом этапе разработки. Тестовые случаи включали ситуации с воссозданными проблемами, раннее выявленными в процессе работы приложения.
Проблемные кейсы включали несогласованность тестовых данных в системах, различия между рабочими средами систем или этапов, а также некоторые ошибки, появляющиеся только при определенных конфигурациях. Большая часть времени, отведенного для тестирования, приходилось на настройку систем и выстраивания их в нужной последовательности, которая, как предполагалось, отвечала бы реальной ситуации.
Базу тестовых данных можно было просто импортировать. Она была полезной еще и потому, что позволяла легко создавать пользователей и учетные записи, подставляя «на лету» любые даты, иначе тестирование заняло бы годы. Есть ли способ получше?
Сдвиг влево: Первая передача
Почему мы привыкли к тому, что в жизненном цикле разработки тестирование проходит на поздних этапах? Ведь это же очевидный факт – чем раньше найдена ошибка, тем проще и дешевле обходится ее исправление. Давайте-ка сдвинем этап тестирование влево по временной оси жизненного цикла разработки программного обеспечения, и переместим его в среду разработки.
Благо, что из-за существенных изменений в конфигурациях, провернуть это дельце сейчас уже не так хлопотно, как раньше. Системы мигрировали в облачные сервисы, а тестировщики перешли к использованию API. Работая в среде, контролируемой на уровне API, каждое приложение может вызвать функцию (универсальную или выделенную) в обход службы, чтобы выполнить более раннее тестирование. После окончания проверки данные передаются через запрос для формирования ответа. Если требуемая система недоступна, этот вопрос решает служба виртуализации (service virtualization).
Служба виртуализации — это простой, но действенный способ для проведения всесторонних испытаний любой подключенной системы, позволяющий тестировщикам «играть» с ней по своим правилам. Виртуализация также помогает создавать сложное окружение, чтобы обучение проходило в обстановке, «приближенной к боевой», а полученная практика уменьшала риски возникновения непредвиденных ситуаций. Тем более, что для последующего воспроизведения требуемых ситуаций, все потоки данных записываются. Вызовы служб выполняются на уровне API и служба виртуализации ведет себя так же, как вел бы себя готовый продукт (система).
Модульный подход к тестированию также вносит свои изменения в правила игры. Разработчики создают модули, которые после используются тестировщиками. Просто представьте перспективы тестируемой системы, в которой разработчик видит только ее часть, а тестировщики видят картину системного «ландшафта» целиком и со всеми возможными конфигурациями. Повторное использование некоторых артефактов создаст новые цепочки процессов либо добавит новые возможности в процесс моделирования. Разработчики могут определить обязательные параметры подключения, такие как логины, пароли, конечные точки и минимально необходимые меры безопасности, а тестировщики просто берут все это и используют в тестовой среде (да-да, именно среде, а не выделенной области тестирования, в которой системы реально взаимодействуют друг с другом без виртуализации.)
Тестовые данные и варианты всех тестов могут быть доступны и для dev- и для test-команд поэтому в зависимости от важности конкретного теста, он может быть запущен уже на этапе разработки, с последующей записью входящих/исходящих данных. Вызов службы можно осуществить типичным способом, но это зависит от данных, которыми оперирует команда. Поиск ошибок на ранних стадиях жизненного цикла приводит к уменьшению ресурсов, выделяемых для последующего тестирования, и ускоряет время выхода продукта на рынок.
Однажды мы участвовали в переносе тестирования на ранние стадии в компании, занимающейся обслуживанием кредитных карт. Хотя в то время им уже удалось избавиться от статической конфигурации тестов и перейти к API, но, несмотря на всю специфичность софта и функционала, на ранней стадии тестирования было выявлено очень много ошибок. Компания располагала отдельной командой тестировщиков, которая просто фокусировалась на уровне API и проверяла связь между ним и приложениями. Тестировщики вместе с разработчиками создавали модули, предоставляющие запросы и ответы. Одни и те же модули использовались повторно при тестировании системы с разными параметрами соединений. Это экономило огромное количество времени, так как команда разработчиков знала, что будет нужно тестировщикам в случае внесения определенных изменений в параметры соединений. Критичные ошибки и нестыковки данных были выявлены еще на этапе разработки и были решены поэтапно, во время развернутого тестирования.
Когда они еще только начали «истязать» приложение с помощью служб виртуализации, разработчики уже успели рассказать нам, как далеко смогут зайти их проверки, чем существенно сэкономили время дальнейшего тестирования и обслуживания.
Сдвиг вправо: пятая передача
Этот особенный метод, потому что мы попытаемся получить лучшее из обоих техник, рассмотренных выше. На этом этапе существенно увеличивается количество тестировщиков, но время выхода на рынок должно сократиться, потому что тестирование происходит в продакшене.
Одним из лучших примеров смещения тестирования вправо (shifting right) является Amazon, так как его заказчики и потребители также выступают в качестве тестировщиков. Все операции глубоко интегрированы. Оптимальный результат достигается в том случае, когда стадия раннего тестирования уже пройдена и на выходе у вас остается только финальный продукт, который проходит автоматическую сборку.
Для того чтобы провести надлежащее тестирование в продакшене, придется потратить больше усилий, чем на предыдущих этапах, потому что все процессы должны быть настроены идеально, а работа – автоматизирована в пользу уровня API. Все, что вы забыли проверить, будет присутствовать в производстве, поэтому функциональность, которая не была покрыта тестами, может привести к реальным проблемам. Ваш продукт должен уже быть сверхстабильным и, возможно, работать с ограниченным числом подключений. По крайней мере, позаботьтесь о том, чтобы все было протестировано с не менее чем 90 % покрытием рисков, иначе некоторые операции не смогут развернуться.
Каждый модуль должен обрабатываться независимо. Полное развертывание в рабочей среде должно состоять из множества фрагментов, так как это обеспечит лучшее покрытие тестами. Большинство фич могут вызвать побочные эффекты. Их может быть даже больше ожидаемого, поэтому их нужно включить в ваши тесты как можно раньше. Конечно, финальное тестирование выполнят непосредственно пользователи, а их отзывы приведут вас к оставшимся ошибкам.
Несмотря на вышесказанное, необходимо не забыть о готовом рабочем конвейере непрерывной интеграции QA, который будет запускаться во время сборки. Большинство тестов запускаются автоматически, во время работы, выбранной CI-тулзы, поэтому сборка выполнится только в случае их успешного прохождения. Тестировщикам нужно позаботиться только о создании тестов, их поддержке и проверке результатов. Идеально, если тестировщики еще и умеют распознавать ложные срабатывания, а также оценивать необходимость вовлечения в процессы тестирования или разработки.
Если вам удалось пройти через все «передачи» воображаемой коробки передач, то вы должны использовать преимущества первой. Здесь модули API могут использоваться повторно, а обслуживание на техническом уровне выполняется только один раз. Качество конечного продукта будет оценено клиентами на основании их отзывов (речь идет о сообщениях-разочарованиях).
Этот способ подходит для увеличения лояльности пользователей и для создания функционала, отвечающего их требованиям, но, чтобы воспользоваться им, нужно, чтобы ваш продукт уже находился на определенном уровне. Если новые «фишки» не слишком сильно повлияют на ваш бизнес, в том смысле, что частота их использования, как и возможный ущерб, несущественны, можно смело экспериментировать в этом направлении. В противном случае постарайтесь убедиться, что тесты покрывают как можно больше функциональности, а все побочные эффекты обнаружены. Чем выше плотность тестового покрытия, тем выше доверие к продукту.
Ранее мы настраивали этот процесс для одного из крупных ритейлеров. Их продукт был уже почти готов и как раз проходил стадию наполнения фичами. Каждое приложение, созданное сторонней командой, виртуализировать и подключалось через API. Каждая сборка проходила через конвейер CI и проверялась на стороне разработчика с помощью автоматизированных API-тестов и JUnit.
Если все «Ok», сборка автоматически перемещалась в специальное тестовое окружение. Там с помощью CI-тулзы в сборку включались тестовая среда и инструменты тестирования, после чего она пересобиралась. Потом запускались автоматизированные функциональные тесты, во время которых использовались UI, API и реальные устройства. Если результаты прохождения тестов «зеленые», сборка передавалась в продакшен и собиралась автоматически. С одной стороны, вы сильно сэкономите время и деньги, с другой — должны быть уверены в используемых системах и приложениях.
В случае необходимости внесения изменений в тесты вам нужно будет работать всего лишь с одним продуктом, что также сильно снимает «головную боль». Благодаря заранее встроенным модулям, не придется создавать одни и те же тесты для разных окружающих сред, но главная проблема – это «ровная» работа виртуализации на различных этапах. При создании тестового набора мы даже ввели принцип “четырех глаз”, чтобы убедиться в том, что все проверено и покрыто тестами.
Не бойтесь использовать передачи
Каждое тестовое окружение зависит от многих факторов, включающих команду, само приложение и конфигурацию инфраструктуры. На разных этапах могут использоваться различные тестовые стратегии и подходы. Если в процессе тестирования вы думаете, что переход вправо либо влево мог бы быть полезнее, либо сам ход процесса «толкает» вас в определенном направлении — сделайте это.
Каждый сдвиг — это целый процесс, а не одно мгновение. Не бойтесь переносить тестирование на разные стадии жизненного цикла программного обеспечения, если считаете, что это принесет больше пользы для общего дела. И, да, мысли о создании совершенно нового плана тестирования всегда будут останавливать вас. Не позволяйте им делать это. Возможность повторного использования теста очень высока, поэтому однажды применив что-то на «третьей передаче», вы можете сэкономить много времени и денег на пятой.
Пусть ваши тестовые циклы сами наталкивают вас на верный путь, подобно тому, как звук мотора автомобиля, с механической коробкой, наталкивает водителя на мысль о необходимости переключить передачу.
Сдвиг тестирования вправо. Возникновение TestOps
Понятие shift-left на протяжении некоторого времени является популярной тенденцией в практиках непрерывного тестирования. Неожиданно, в последнее время мы начинаем видеть в тестировании новый тренд: «shift right».
Сдвиг вправо влечет за собой проведение дополнительного тестирования на этапах пререлизной и пострелизной версий (т.е. тестирование в продуктивной среде) жизненного цикла приложения. К ним относятся такие практики как: валидация релиза, деструктивное/хаос-тестирование, A/B и канареечное тестирование, CX-тестирование (например, корреляция поведения пользователя с тестовыми требованиями), публичное массовое тестирование, мониторинг сред эксплуатации, извлечение тестовых представлений и сценариев из данных продуктивных сред. Shift-right не только вводит такие методы тестирования, но также требует, чтобы тестировщики приобретали новые навыки, активно использовали данные продуктивных сред для разработки стратегий тестирования, сотрудничали с новыми заинтересованными сторонами такими, как SRE-инженеры и инженеры по эксплуатации. В тенденции к сдвигу вправо и расширении сотрудничества с эксплуатацией, мы видим эволюцию новой дисциплины в DevOps, которую называем TestOps.
Новые тенденции по смещению тестирования вправо
В недавнем опросе о непрерывном тестировании, проведенном Capgemini и Broadcom, тестирование на продуктивных средах было отмечено как наиболее широко применяемая практика (с 45% респондентов), либо уже внедренная, либо планируемая в настоящее время (см. Рисунок 1). Кроме того, 39% респондентов упомянули использование аналитики данных эксплуатации продуктивных сред для определения или оптимизации охвата тестированием.
В ответах на вопрос о том, как клиенты измеряют эффективность процессов непрерывного тестирования, первое и второе место заняли производственные данные и отзывы пользователей, а также принятие пользователями нового функционала (см. Рисунок 2).
Наконец, на вопросы о том, как клиенты тестируют свои цифровые приложения, чтобы убедиться, что они соответствуют требованиям реального мира, почти все ответы были связаны с данными продуктивной эксплуатации (см. Рисунок 3).
Использование этих данных для разработки стратегии тестирования стало новой реальностью по сравнению с аналогичным опросом, проведенным год назад.
Данные опроса явно указывают на то, что клиенты активно практикуют (или рассматривают эту возможность) методы сдвига вправо для тестирования.
Что заставляет тестирование сдвигаться вправо?
Целью смещения вправо является обеспечение правильного поведения, производительности и доступности в процессе разработки, поставки и эксплуатации приложения. Есть несколько драйверов, которые заставляют сдвигаться в сторону эксплуатации.
Customer Experience (CX) — ключевой показатель качества для цифровых приложений
В отличие от классического тестирования, здесь учитываются реальные пользователи и их опыт. Приложение с идеальными показателями традиционного качества (например, FURPS) может по-прежнему страдать от плохого CX, если оно не может удивить и порадовать пользователя. CX измеряется с использованием различных показателей, таких как Customer Effort Score (CES), Net Promoter Score (NPS), Customer Satisfaction Score (CSAT), и т.д. Хотя некоторые из этих измерений можно сдвинуть влево в некоторой степени, большинство измерений CX могут быть получены только из продуктивных сред (или расположенных близко к ним). Примеры CX-тестирования включают в себя:
В мире гибкой доставки может оказаться невозможным протестировать все перед выпуском в экcплуатацию
Время выхода на рынок (или время для внесения изменений) является главным бизнес-требованием для цифровых приложений, поэтому QA / тестирование считается основным узким местом в непрерывной доставке. Хотя можно оптимизировать усилия по тестированию и время цикла, используя практики сдвига влево (такие как тестирование на основе моделей, оценки влияния изменений, автоматизации тестирования), эти подходы могут все еще занимать слишком много времени (или требовать значительных усилий) в то время как команда пытается сократить время цикла выпусков продукта. В некоторых случаях истинные паттерны и способы эксплуатации могут даже не быть полностью поняты/осознаны до выпуска приложения на реальных пользователей. Идея состоит в том, чтобы изучить шаблоны использования (и работы) продуктивной среды и использовать их для улучшения стратегии тестирования в пределах сдвига влево.
Следовательно, компании тестируют, стремясь обеспечить «достаточно хорошее», а не «максимальное» качество (для обеспечения своевременного выпуска). Полагаются на быстрое восстановление (или откат) для устранения неизбежно возникающих дефектов или проблем.
Кроме того, измерения CX (как описано выше) часто обеспечивают реальную пользовательскую обратную связь во всем наборе оттенков, в отличие от черно-белого теста «пройдено / не пройдено» классического тестирования. Это дополнительно подтверждает то, что невозможно опираться только на усовершенствование тестовых наборов для подготовки к производству, чтобы обеспечить полное покрытие CX.
Стопроцентная надежность (или качество) часто является нереальной целью
В связи с вышеизложенным, один из ключевых принципов, которые мы изучаем из дисциплины DevOps SRE, заключается в том, что 100% надежность не только нереальна, но и слишком дорога. SRE определяет концепцию уровней обслуживания (SLO) и бюджетов ошибок для количественной оценки приемлемого допустимого уровня риска в продуктивных системах. Тот же принцип применим к тестированию и общему качеству.
Некоторые проверки сложно выполнить в тестовых средах
К таковым относятся крупномасштабные тесты производительности, когда тестовые среды не имеют размеров (мощностей и/или конфигураций), сравнимых с продуктивными средами.
Другой пример — деструктивное или хаос-тестирование. Хотя можно проводить изолированное хаос-тестирование в тестовых средах, используя такие методы, как виртуализация служб (для имитации сбоя в зависимых компонентах), его трудно выполнить для крупномасштабных деструктивных тестов. Например, Netflix проводит значительную часть своих испытаний на продуктивных средах.
Аналогично, корпоративный мониторинг для сбора информации о реальной эксплуатации, потреблении и о сбоях возможен только на продуктиве. Хотя мы выступаем за использование мониторинга в тестовых средах (как часть сдвига влево), такой мониторинг помогает только осуществлять локальные измерения (например, конкретного тестируемого приложения или системы). Тем не менее, сценарии тестирования производительности, разработанные тестировщиками, могут быть повторно использованы в продуктивных средах (двигаясь по оси и вправо и влево) в качестве синтетических метрик для измерения производительности, оценки регресса приложения.
Наконец, тестирование некоторых приложений с использованием ИИ может быть затруднено без доступа к данным продуктивных сред. Например, некоторые алгоритмы машинного обучения должны постоянно совершенствоваться на основе данных реального мира. Хотя эти алгоритмы разрабатываются с использованием ограниченного набора данных для обучения и тестирования, их необходимо адаптировать и дообучать на данных от реального использования продуктивных сред измеряемых приложений.
Разработчикам и тестировщикам нужна более простая и короткая связь с продуктивной эксплуатацией
Более короткая связь с продуктивной эксплуатацией в замкнутом контуре позволяет разработчикам и тестировщикам лучше понимать поведение приложения, прогнозировать успех / неудачу выпусков, реагировать на инциденты (например, сокращать MTTR).
Интерпретация и использование объемных данных часто трудны и утомительны для команд разработчиков и тестировщиков. Использование методов сдвига вправо позволяет разработчикам и тестировщикам более легко получать доступ к данным продуктивных сред в форме, которая легко потребляема и эффективна благодаря использованию правильных знаний из дисциплин AIOps. Такое использование данных является ключевым принципом парадигмы DevOps. Например, синтетические измерения/мониторинги, которые обычно создаются разработчиками и тестировщиками на этапах разработки / тестирования, предоставляют разработчикам средства для получения обратной связи по мониторингу в форме, с которой они знакомы.
Кроме того, автоматический анализ первопричин дефектов / инцидентов в продуктиве может дать разработчикам и тестировщикам понимание моделей и тенденций отказов, их источников, когда производственные данные соотносятся с данными разработки, причин которые их вызывают.
Аналогично, сценарии использования данных (например, из журналов базы данных, журналов транзакций) могут использоваться для генерации соответствующих тестовых данных.
В сущности, практика тестирования со смещением вправо необходима для создания непрерывного цикла обратной связи от реального взаимодействия пользователя с реальным приложением в сторону процесса разработки и тестирования.
Эволюция дисциплины TestOps
Из данных опроса клиентов и факторов, обсуждаемых выше, ясно, что существует эволюция в сторону сдвигающихся вправо практик.
Точно так же, как мы это делали со сдвигом тестированием влево, для того, чтобы сделать эти методы устойчивыми и реализовать заложенные в них преимущества, нам нужно также развивать варианты использования тестов, навыки, инструменты и шаблоны сотрудничества с людьми и дисциплинами правой области жизненного цикла приложения, т.е. эксплуатации. Другими словами, необходимо установить новую дисциплину TestOps, как субдисциплину в более широком контексте DevOps.
Хотя термин TestOps (как и все другие дисциплины x-Ops в DevOps) подразумевает сотрудничество между тестированием и эксплуатацией, речь идет не просто о сдвиге вправо. Почему? Потому что с DevOps эксплуатационные дисциплины сами сдвинулись влево (например, сдвиг влево в чати мониторинга, управления конфигурациями, SRE и т. д.). Следовательно, TestOps стремится к лучшему сотрудничеству с дисциплинами эксплуатации на протяжении жизненного цикла непрерывного тестирования в DevOps.
Давайте рассмотрим некоторые из ключевых практик в TestOps shift-left (см. Рисунок 4).
Раннее тестирование надежности: статический анализ масштабируемости архитектуры системы, а также тестирование производительности и стресс-тестирование.
Контроль качество конфигурации: тестирование среды «as-code» (все, что «as-code» может и должно быть протестировано как таковое, как и код приложения) и конфигурации развертывания, а также тестирование развертывания и тестирование отката.
Ранний мониторинг: мониторинг систем на ранних этапах жизненного цикла (например, в средах разработки и тестирования), а также разработка и тестирование синтетических метрик перед их развертыванием на продуктивных средах.
Раннее применение AIOps: раннее использование методов AIOps (в средах разработки и тестирования) для сбора результатов тестирования и анализа качества, например, для прогнозирования риска дефектов и выпусков.
Ниже приведены некоторые из ключевых практик TestOps, посвященных смещению вправо (см. Рисунок 5).
Инженерия хаоса: проверка надежности системы путем внедрения сценариев контролируемого отказа.
A / B-тестирование: рандомизированный эксперимент с двумя (или более) вариантами изучения, которые более наилучшим обрабом принимаются пользователемя.
Канареечные релизы: методы, используемых для снижения риска внедрения новой версии программного обеспечения путем постепенного развертывания изменения на небольшой подгруппе пользователей, прежде чем распространять его на всю платформу / инфраструктуру и делать его доступным для всех.
Синтетический мониторинг: методы мониторинга с использованием эмуляции или записи транзакций по сценарию (которые отражают типичное поведение пользователя).
Тестирование и аналитика CX: извлечение данных CX, чтобы понять опыт клиентов, а также извлечь из них информацию (например, проблемы клиентов, требования к новым функциям и т. д.).
Тестирование данных на основе данных AIOps: как описано выше, из данных операций можно почерпнуть множество различных идей для тестирования.
Ключевые навыки и инструменты TestOps
Давайте рассмотрим новые навыки, необходимые для ключевых практик TestOps.
Ключевые коллаборации TestOps практик
В дополнение к новым навыкам тестеры теперь должны научиться лучше сотрудничать с дополнительными заинтересованными сторонами. Это включает:
Автор Шамим Ахмед (Shamim Ahmed), оригинал публикации Shift-Right Testing: The Emergence of TestOps