Home

Автор: Денис Федоров

Неприятная ситуация: продукт проходит тщательную проверку на всех этапах разработки, а после релиза всё равно возникают неожиданные ошибки… А ведь это происходит, потому что тестирования на ранних стадиях (shift-left testing, «влево») не всегда достаточно, чтобы гарантировать стабильность продукта. Поэтому важно учитывать и тестирование в продакшене (shift-right testing, «вправо»). 

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

Тестирование влево

Процесс разработки часто изображается в виде линии времени, где этапы проектирования и разработки находятся слева, а развёртывание и эксплуатация продукта — справа. 

Тестирование влево (Shift-left testing) — это подход, при котором тестирование ориентировано на начало процесса разработки. Главная цель — выявлять ошибки как можно раньше, ещё на стадии проектирования, анализа требований и написания кода. Ранние проверки обходятся дешевле, чем исправление багов после запуска продукта.

Вот как это выглядит, например, в водопадной модели:

Основные особенности тестирования влево

У такого тестирования есть четыре ключевые особенности.

1. Раннее выявление ошибок помогает идентифицировать дефекты до того, как они попадут в код или будут встроены в архитектуру.

   • Анализ требований перед началом разработки помогает избежать недопонимания между заказчиком и командой. Это снижает вероятность появления ошибок в коде, связанных с неправильным пониманием задач.

   • Проверка архитектурных и проектных решений позволяет убедиться, что требуемый функционал устойчив к возможным будущим изменениям.

2. Тестирование влево предполагает участие тестировщиков и QA-инженеров уже на этапе формулировки требований к продукту. Это позволяет избежать ошибок, связанных с нечёткими или неполными требованиями.

   • Ревью требований (рецензирование). Тестировщики участвуют в анализе и проверке требований к системе (Requirements Review). Это позволяет заранее выявить логические противоречия или неясности.

   • Сценарии тестирования (Test Scenarios). Уже на этапе анализа требований формируются сценарии тестирования, которые будут использоваться позже для проверки готового продукта. Это помогает заранее понять, а что мы будем тестировать и как.

3. Тестирование на уровне модулей. Разработчики активно пишут юнит-тесты для проверки отдельных функций или модулей кода, а также проводят интеграционное тестирование, чтобы убедиться, что отдельные модули корректно взаимодействуют между собой.

4. Использование методов автоматизации. Автоматические тесты позволяют запускать тесты автоматически при каждом изменении кода (например, при создании новых веток или коммитов), что значительно ускоряет процесс тестирования и позволяет оперативно выявлять ошибки.

Какие проблемы не решает тестирование влево?

Однако современные разработчики всё чаще понимают, что для гарантии стабильности продукта одних только ранних тестов недостаточно. И вот, что «не закрывает» тестирование влево.

1. Проблемы, связанные с эксплуатацией продукта (Production Issues)

Тестирование влево фокусируется на ранних этапах жизненного цикла разработки, но не охватывает проблемы, которые могут возникнуть в реальной среде эксплуатации ↓

• Непредвиденные ошибки и сбои в продакшене.

• Проблемы интеграции с реальной инфраструктурой или внешними системами.

• Нагрузочные проблемы и производительность при реальном количестве пользователей.

• Адаптация под реальные пользовательские данные и сценарии.

2. Проблемы, выявляемые только на поздних стадиях

Некоторые категории тестов требуют завершённого продукта или более позднего этапа реализации:

• интеграционное тестирование выявляет ошибки только при интеграции с внешними системами;

• конечное пользовательское тестирование (UAT) показывает, как продукт воспринимается конечными пользователями;

• полномасштабное нагрузочное тестирование требует готового продукта для корректного проведения.

3. Отсутствие обратной связи от реальных пользователей

Shift-left testing минимизирует риски на уровне требований и кода, но не всегда позволяет получить качественный фидбек от конечных пользователей:

• как продукт используется в реальных сценариях,

• насколько удобен интерфейс (UX/UI),

• какие функции пользователи считают приоритетными.

Ну а что же такое тестирование вправо?

Тестирование вправо (shift-right testing) — это подход, при котором программа проверяется уже после её развертывания на продакшн-серверах. Цель заключается в том, чтобы мониторить и анализировать поведение системы в реальных условиях при взаимодействии с пользователями. Такая проверка помогает убедиться в устойчивости работы продукта, его безопасности и производительности даже под непредсказуемыми нагрузками.

Shift-right testing даёт команде возможность быстро реагировать на проблемы, выявленные в боевых условиях, минимизируя риски для бизнеса и пользователей, что значительно уменьшает риски финансовых и репутационных последствий для компаний. Если представить процесс разработки и тестирования как линейный процесс от написания кода до его развёртывания в продакшн (на производство), то тестирование вправо фокусируется на последних этапах — «правее» на шкале жизненного цикла разработки ПО. 

Тестирование «вправо» предполагает, что после выпуска продукта важно продолжать его мониторинг, анализ и тестирование в реальной производственной среде.  

Это необходимо для обеспечения бесперебойной работы системы, её устойчивости к нагрузкам, безопасности, а также соответствия требованиям пользователей.

Чаще всего таким тестированием занимаются либо заказчики, либо саппорт, либо QA-инженеры.

Почему тестирование вправо необходимо и какие преимущества оно даёт?

Shift-right testing стало важным компонентом жизненного цикла разработки программного обеспечения. Его задачи выходят за рамки привычного лабораторного тестирования, сосредотачиваясь на проверке продукта под реальными условиями эксплуатации. Это позволяет не только выявлять проблемы, которые не проявляются в тестовой среде, но и использовать эти данные для постоянного улучшения продукта. Вот ключевые причины для его необходимости и преимущества, которые оно предоставляет:

1. Проверка в реальных условиях эксплуатации

Лабораторное тестирование, каким бы тщательным оно ни было, никогда не сможет полностью воспроизвести сценарии реальной жизни. Настоящие пользователи взаимодействуют с системой в неожиданных условиях: внезапные всплески трафика, уникальные комбинации действий или нештатные ситуации.

Shift-right testing позволяет протестировать продукт под боевой нагрузкой, увидеть его поведение под реальными пиками нагрузки и обнаружить скрытые проблемы.

В нашей команде есть контур, идентичный продакшену, на котором мы запускаем нагрузочные тесты с профилями нагрузки, соответствующими продакшену. Это позволяет нам убедиться, что после выпуска обновления не произошло деградации приложения.

2. Реальные данные для точного анализа

Типичные тестовые сценарии основываются на предположениях и симуляциях. Реальная же эксплуатация продукта предоставляет фактические данные: как система справляется с нагрузкой, какие баги возникают у пользователей, где происходит задержка процессов. Эти данные позволяют не гадать, а принимать точные, основанные на метриках и наблюдениях решения для улучшения системы.

3. Постоянный контроль при обновлениях

Современный подход к разработке диктует быстрые и частые релизы — новые версии продукта выходят почти ежедневно. Однако каждое обновление несёт в себе риски, особенно если изменения затрагивают критические части. Shift-right testing позволяет минимизировать эти риски, внедряя такие методики, как canary releases (обновление для ограниченного числа пользователей) и blue-green deployment (развёртывание новой версии параллельно со старой), UAT (user-acceptance testing), чтобы изменения проверялись на небольших группах пользователей в реальной среде перед их полным внедрением.

В нашей команде при выпуске новой фичи мы всегда отправляем её на продуктовое ревью. На этом этапе продакты, аналитики и другие заинтересованные лица проверяют работоспособность фичи, оценивают её интеграцию с другими функциями. Только после одобрения аналитиков и продактов мы передаём фичу в релиз.

В команде Online ребята проводят канареечные релизы на небольшую аудиторию, анализируют, как новая версия работает у пользователей, следят за графиками, собирают фидбек и занимаются мониторингом

4. Улучшение пользовательского опыта (UX)

Зачастую реальный пользовательский опыт сильно отличается от того, что предполагается при проектировании. Shift-right testing открывает возможности для изучения и улучшения взаимодействия пользователей с продуктом через методы вроде A/B-тестирования (сравнение различных версий продукта) или анализа пользовательского поведения. Статистика и данные из реального использования помогают понять, какая функциональность действительно удобна, а что требует доработки.

Почти все команды в нашей компании проводят A/B-тесты для проверки гипотез по улучшению UX. Такие тесты позволяют рассмотреть работу продукта с разных сторон и выявить оптимальное решение для большинства пользователей. Кроме того, многие команды используют инструменты, такие как Яндекс.Метрика, чтобы анализировать, какие функции востребованы, а какие — нет, а также определить, где необходимы доработки.

5. Оперативное реагирование на баги

В тестах, проведенных до выпуска продукта, невозможно учесть все нюансы. Shift-right testing включает постоянный мониторинг и анализ логов, что позволяет быстро обнаруживать и исправлять баги, проявляющиеся уже в продакшене.

В нашей команде есть алерты, которые помогают оперативно выявлять баги. Например, если на проде у нескольких пользователей возникает ошибка 500, мы сразу получаем уведомление. Дежурный оперативно анализирует ситуацию и выясняет, что в приложении что-то сломалось. Далее принимается решение: если проблема критичная или блокирующая, мы либо откатываем релиз, либо выпускаем хотфикс. Если же проблема незначительная, мы все равно устраняем ее оперативно, но выкатываем исправление вместе с плановым релизом.

6. Укрепление безопасности

После выхода продукта в продакшн он становится мишенью для злоумышленников. Shift-right testing поддерживает высокий уровень безопасности за счёт постоянного мониторинга, сканирования системы на уязвимости и имитации атак. Регулярная проверка помогает вовремя выявлять и устранять возможные угрозы.

Не обязательно проводить тестирование безопасности в проде, но среда, в которой оно выполняется, должна соответствовать проду — например, по конфигам, данным, правам пользователей и настройкам алертов. Если алерты не настроены, мы не сможем проверить, будут ли они срабатывать в случае реальной опасности на проде, что может привести к тому, что в критической ситуации мы попросту не успеем вовремя среагировать.

У нас достаточно часто безопасники приходят в продукт и просят предоставить, контур который не отличается от прода (может отличаться только ресурсами) для тестирования безопасности. В течении какого-то времени безопасники гоняют продукт и находят уязвимости, которые впоследствии мы закрываем.

7. Соответствие нормативам и стандартам

Для критических отраслей, таких как финансы или медицина, соблюдение нормативных требований — не просто рекомендация, а обязательное условие. Shift-right testing позволяет убедиться, что изменения в продукте, произошедшие после обновлений, не привели к нарушениям стандартов и сохраняют соответствие законодательным и отраслевым требованиям. Это особенно важно для предотвращения рисков штрафов или репутационных потерь.

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

Какие типы тестирования вправо существуют?

1. Мониторинг производительности

Когда приложение уже работает, нужно следить за тем, как оно ведёт себя под реальной нагрузкой. Это не просто нагрузочное тестирование на этапе разработки, а реальная проверка под боевыми условиями. Здесь мы смотрим:

• Как быстро приложение отвечает пользователям.

• Какие части системы тормозят под нагрузкой.

• Как оно справляется с пиковыми ситуациями (например, когда резко возрастает количество пользователей).

Мониторинг производительности с помощью инструментов вроде Datadog, New Relic или Grafana (мы как раз используем её) позволяет не только следить за отзывчивостью системы, но и отслеживать множество важных метрик, таких как время отклика сервера, загрузка процессора и использование памяти. Эти данные в реальном времени помогают выявлять узкие места системы, например, когда нагрузка возрастает, и быстро реагировать на возникающие проблемы.

В нашей команде мы постоянно следим за метриками производительности, временем ответа и RPS. Если после релиза мы замечаем, что время ответа увеличилось или количество запросов возросло в несколько раз, мы незамедлительно реагируем: разбираемся, почему такая нагрузка, оцениваем, справляется ли система, и, если нет, разрабатываем решения, которые сократят нагрузку (если это мы напортачили).

2. A/B-тестирование

Это тип тестирования, который позволяет понять, как пользователи реагируют на разные версии приложения или его отдельных функций. Например, показываем половине пользователей одну версию кнопки, а другой половине — другую, дальше смотрим, на какую кликают больше. Здесь тестируется не только производительность, но и пользовательский опыт (UX): какая версия работает лучше для реальных пользователей.

В команде Online ребята очень часто проверяют теории по улучшению UX путём A/B-тестов. Это помогает внести правки до релиза в прод, так же позволяет найти какие-нибудь неудобства или пути улучшения UX приложения. Для таких проверок у них есть отдельные контура, куда выкатываются эти «гипотезы» и там же проводится работа с ними. 

3. Canary releases

Представь себе: ты выпускаешь обновление, но вместо того, чтобы сразу распространить его на всех пользователей, сначала даёшь его маленькой группе. Это как отправить «канарейку в шахту» — так шахтёры проверяли, нет ли утечек газа. Если всё нормально, обновляешь для остальных. Если что-то пошло не так, то откатываешь обратно, минимизируя риски.

В команде Online эта практика используется на постоянной основе. Каждый релиз сначала раскатывается на 10% аудитории. Если по мониторингу и обращениям от юзеров всё отлично, то релиз идёт дальше. Такой подход помогает вовремя предотвратить ошибки и пофиксить их ещё до релиза на прод.

4. Тестирование на устойчивость (Chaos Engineering)

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

5. Непрерывный мониторинг безопасности

Даже после релиза приложения важно не забывать про его безопасность. Злоумышленники не дремлют, так что нужно постоянно проверять, нет ли новых уязвимостей. Сюда входят:

• Мониторинг подозрительной активности: отслеживаем странные запросы или поведение пользователей.

• Постоянное сканирование на уязвимости: с помощью инструментов вроде OWASP ZAP или Burp Suite проверяем, нет ли слабых мест в системе.

• Симуляция атак: иногда проводятся учебные атаки, чтобы убедиться, что система защищена от реальных угроз.

Периодически мы отдаём наше приложение безопасникам для проверки на уязвимости. Для данной проверки мы предоставляем наш предрелизный контур, на котором все конфиги, базы и ресурсы соответствуют проду. Данный подход помогал нам найти некоторые дыры в безопасности, которые не видны в коде и не нашлись при работе с приложением.

6. Логирование и мониторинг ошибок

Тут всё просто: следим за логами и отчётами об ошибках, которые происходят в реальной эксплуатации. Важно быстро реагировать на любые сбои и неполадки, которые происходят уже на продакшене. Инструменты вроде Sentry, Logstash и та же самая Grafana помогают отслеживать такие ошибки и уведомляют команду, если что-то пошло не так.

Если у нас что-то случается — например, падает доступность сервиса, замедляется время ответа или летят 500 на какой-то метод — мы получаем алерты от бота Grafana. Так мы можем быстро реагировать на них: бот дергает дежурного, который сразу же проверяет алерты. Ни один алерт не остаётся без реакции. 

7. Тестирование пользовательского поведения (Real User Monitoring)

Это тестирование фокусируется на том, как реальные пользователи взаимодействуют с системой. Оно помогает понять, где пользователи «застревают», какие функции вызывают у них затруднения и как можно улучшить интерфейс. Здесь используются инструменты аналитики (Google Analytics, Hotjar и Яндекс.Метрика).

Отличия тестирования влево от тестирования вправо

Хотя оба подхода нацелены на улучшение качества программного обеспечения, они различаются по времени проведения, задачам и инструментам. Вот основные различия между ними:

Таким образом, тестирование вправо дополняет тестирование влево, выводя процесс проверки качества на этап эксплуатации. Если shift-left помогает предотвратить потенциальные ошибки на этапе разработки, то shift-right помогает понять, как программное обеспечение работает под реальной нагрузкой и в боевых условиях.

Как мы видим, эти два подхода совершенно по-разному подходят к тестированию. У каждого из них есть свои преимущества и проблемы. 

Финал

Подводя итог, shift-right testing — важная часть разработки и тестирования ПО, которая помогает обеспечить стабильность, безопасность и эффективность программы даже после её выпуска. Когда требования постоянно меняются и нагрузки на системы растут, быстрая реакция на проблемы и их предотвращение не только упрощает работу разработчиков, но и защищает компании от финансовых и репутационных рисков.

Shift-right testing активно интегрируется с практиками DevOps и Site Reliability Engineering (SRE). Это помогает разработчикам и операционным командам работать вместе, обеспечивая мониторинг системы в реальном времени и оперативное устранение проблем. Это критический элемент современных CI/CD-процессов, поддерживающий быструю и стабильную работу систем в условиях высоких нагрузок.

Совет: если ваша команда ещё не начала внедрять практики shift-right тестирования, сделайте первый шаг. Настройте системы мониторинга, начните с canary releases для постепенного внедрения обновлений и используйте реальные данные для принятия обоснованных решений. 

Обсудить в форуме