Shift-left и shift-right — это не модные слова, а способы перераспределить работу по качеству во времени. Идея простая: часть рисков лучше обрабатывать раньше разработки, а часть становится видимой только после выхода в более реальный контекст использования.
Что такое shift-left
- →Раннее вовлечение QA в требования, UX, контракты, данные и архитектурные решения.
- →Смещение проверок на более низкие и дешёвые уровни: контракты, unit, service, схемы данных.
- →Выявление дефектов и неоднозначностей до того, как они превратятся в дорогое исправление.
Что такое shift-right
- →Использование post-release сигналов: monitoring, logs, alerts, product analytics, canary и feature flags.
- →Проверка системы в условиях, максимально близких к реальному пользовательскому поведению и продовой нагрузке.
- →Быстрое обнаружение деградаций, которые невозможно полностью смоделировать в тестовом окружении.
Почему нужен баланс
- →Только shift-left не спасает от рисков, которые проявляются на реальных данных и трафике.
- →Только shift-right означает, что слишком много проблем вы разрешаете уже после воздействия на пользователей.
- →Сильная стратегия качества сочетает раннее предупреждение и зрелую эксплуатационную обратную связь.
Как это применять QA
- →Сдвигай обсуждение рисков в refinement и design review.
- →Помогай команде строить quality gates до UI-проверок.
- →После релиза смотри на инциденты, логи и поведение пользователей как на продолжение тестирования.
⚖️
Shift-left уменьшает стоимость ошибок, shift-right уменьшает слепые зоны. Вместе они дают более честную картину качества.