Shift-left і Shift-right тестування: що це означає на практиці

Якщо ви бачили ці терміни в описах вакансій або на конференціях, але так і не зрозуміли що за ними стоїть у реальній роботі — ця стаття для вас.

Shift-left і shift-right — це не нові інструменти і не методології. Це зміна того, коли і де відбувається тестування в процесі розробки.

Традиційний підхід: тестування наприкінці

Класична модель розробки виглядала так:

1Вимоги → Дизайн → Розробка → Тестування → Реліз

QA приходили в гру вже після того, як код написаний. Якщо знаходили серйозний баг — доводилось повертатись на кілька кроків назад, переписувати код, заново тестувати. Це дорого і повільно.

Shift-left: тестуємо якомога раніше

"Зсув вліво" означає перемістити активності тестування якомога раніше в SDLC.

1[QA тут↓]                              [раніше тут↓]
2Вимоги → Дизайн → Розробка → Тестування → Реліз

Як це виглядає на практиці

QA на етапі вимог. Замість того, щоб отримати готову специфікацію і тестувати по ній, QA інженер бере участь в її написанні.

Питання, які QA задає на цьому етапі:

• "А що повинно статись якщо користувач введе від'ємне число в поле кількості?"
• "Яка поведінка якщо сесія закінчилась під час заповнення форми?"
• "Чи потрібні ролі доступу для цієї функції?"

Ці питання виявляють прогалини в специфікації до того, як розробник написав хоч рядок коду.

BDD (Behaviour-Driven Development). Тест-сценарії пишуться спільно з розробниками і бізнесом ще до розробки:

1Feature: Авторизація користувача
2
3  Scenario: Успішний вхід
4    Given користувач на сторінці логіну
5    When він вводить правильний email і пароль
6    Then він переходить на dashboard
7    And бачить своє ім'я в хедері
8
9  Scenario: Невірний пароль
10    Given користувач на сторінці логіну
11    When він вводить правильний email і НЕПРАВИЛЬНИЙ пароль
12    Then він бачить повідомлення "Невірний email або пароль"
13    And залишається на сторінці логіну

Code review участь QA. QA може переглядати pull requests з точки зору тестабельності — чи легко буде написати тест для цього коду?

Unit та integration тести. Розробники пишуть тести разом з кодом, а не після.

Чому це важливо

Виправлення бага на етапі вимог коштує умовно $1. На етапі розробки — $10. Після релізу в production — $100-1000.

Shift-left значно знижує вартість якості.

Shift-right: тестуємо в production

"Зсув вправо" — це зворотній рух. Тестування після релізу, в реальному production середовищі з реальними користувачами.

Звучить контрінтуїтивно, але логіка проста: неможливо повністю відтворити production в тестовому середовищі.

Реальні обсяги даних, реальні патерни використання, реальні мережеві умови — це те, чого немає в staging.

Інструменти shift-right

Feature flags (feature toggles). Новий функціонал спочатку видно тільки 1-5% користувачів або внутрішній команді. Якщо проблем немає — поступово розкочується на всіх.

1// Приклад з LaunchDarkly
2if (featureFlags.isEnabled('new-checkout-flow', user)) {
3  return <NewCheckout />;
4} else {
5  return <OldCheckout />;
6}

Canary releases. Новий код деплоїться на малу частку серверів. Якщо метрики гарні — розкочується далі.

A/B тестування. Дві версії фічі тестуються одночасно на різних групах користувачів. Перемагає краща.

Production monitoring. Інструменти як Datadog, Sentry, Dynatrace стежать за помилками, performance і аномаліями в реальному часі.

Real User Monitoring (RUM). Збираємо реальні performance дані від браузерів користувачів — час завантаження, Core Web Vitals, помилки JS.

Chaos Engineering. Навмисно вводимо відмови в production (Netflix Chaos Monkey) щоб переконатись що система стійка. Це вже advanced shift-right.

Як поєднати обидва підходи

Shift-left і shift-right не конкурують — вони доповнюють одне одного:

1[Shift-left зона]              [Shift-right зона]
2     ↓                               ↓
3Вимоги → Dev → Build → Test → Stage → Prod → Моніторинг
4  ↑BDD  ↑Unit  ↑SAST  ↑E2E   ↑Smoke  ↑Canary ↑RUM

Shift-left ловить більшість багів дешево і швидко. Shift-right ловить те, що пропустив staging: production-специфічні проблеми, edge cases реальних користувачів.

Що це змінює для QA інженера

Нові активності

• Участь в refinement та planning сесіях
• Написання acceptance criteria разом з продуктом
• Аналіз production логів і метрик
• Налаштування alerting і dashboards
• Аналіз сесійних записів (Hotjar, FullStory) для пошуку UX проблем

Нові інструменти що варто знати

З чого почати якщо ви новачок

Якщо ваша команда ще не практикує shift-left/right — не потрібно міняти все одразу.

Крок 1 (shift-left): Почніть ставити питання на refinement. Просто задавайте питання "а що якщо..." — це вже shift-left.

Крок 2 (shift-left): Домовтесь з командою писати acceptance criteria у форматі Given/When/Then.

Крок 3 (shift-right): Підключіть Sentry або інший error tracker якщо ще немає. Це безкоштовно для початку.

Крок 4 (shift-right): Дивіться на production метрики після кожного релізу — хоча б перші 30 хвилин.

Навіть ці маленькі кроки суттєво покращують якість і знижують кількість production інцидентів.

Підсумок

Shift-left — тестуємо якомога раніше, виявляємо проблеми до написання коду. Shift-right — не зупиняємось на релізі, продовжуємо тестувати і моніторити в production.

Разом вони перетворюють QA з "воротаря наприкінці" на активного учасника всього процесу доставки цінності користувачу. Саме це означає сучасне Quality Engineering.