Станіслав Підзолков Lead QA Engineer у PrivatBank, Викладач Комп'ютерної школи Hillel.

ЛІВОРУЧ ЧИ ПРАВОРУЧ?

Почну з історії…

Одного разу в компанії «BlackBox Inc.», у підрозділі тестування коробок, трапилася така історія. На перевірку поступила коробка з написом «Чарівна чорна коробка», а в супровідній документації до неї було зазначено: «Це чарівна коробка, яка робить щось чарівне». Команда не розгубилася — не маючи детального ТЗ, вони звісно спробували почати «дослідницьке тестування»: перевірити, що перед ними — щонайменше коробка, та чи вона дійсно чорна… Потім вони спробували її потрусити, виміряти, посвітити на неї ліхтариком, навіть поставили коробці музику… Але в підсумку зрозуміли, що втративши купу часу, так і не змогли з'ясувати, що ця коробка робить, а час та бюджет відведений на тестування — закінчились. Діватися було нікуди, і вони були вимушені віддати коробку замовнику, додавши до звіту висновок: «Коробка чорна, правильної форми — більш нічого не виявили».

Замовник, звісно, був незадоволений, бо він замовляв коробку, яка перетворювала капелюхи на білих кроликів, а ця коробка робила навпаки…

Подібні ситуації дуже часто трапляються й на реальних проєктах: програмне забезпечення передається на тестування вже коли стадії аналізу вимог, проєктування та розробки закінчені. Часто документація до продукту містить суттєві недоліки або не зовсім відповідає тому, що насправді має робити програма. Це може призводити до того, що замовники отримують не той продукт, на який розраховували.

Але що, як ми могли б запобігти цьому? Що, як тестувальник міг би включитись у процес набагато раніше — ще до того, як коробку зібрали? І що, якби ми не зупинялися на цьому, а продовжували перевіряти її навіть після того, як вона потрапила до замовника?

Саме про це — два підходи, які ми сьогодні розберемо: Shift-Left і Shift-Right. Або, якщо по-нашому, — «ліворуч» і «праворуч».

Як влаштований процес у «BlackBox Inc.»

Подивімося, як виглядав життєвий цикл розробки (SDLC) у нашій улюбленій «BlackBox Inc.». Класична схема — водоспад у чистому вигляді:

Аналіз вимог. Менеджер збирає побажання замовника і пише ТЗ. Тестувальників на цьому етапі ніхто не кличе — «вони ж ще не потрібні, коду ще немає».
Проєктування. Архітектор малює схеми, обирає технології. QA? «Зачекайте, ми ще нічого не зібрали».
Розробка. Команда кодить два-три місяці. Тестувальники сидять і чекають.
Тестування. Нарешті! Але часу мало, бюджет тане, а документація — «Це чарівна коробка, яка робить щось чарівне».
Передача замовнику. Після передачі — тиша. Ніхто не моніторить, як продукт поводиться в реальних умовах.

Бачите проблему? Тестування затиснуте в кінці — між завершенням розробки та дедлайном. А після передачі замовнику продукт стає «чорною скринькою» вже для самої команди.

Саме цю проблему й вирішують два підходи: Shift-Left зсуває тестування ліворуч — ближче до початку. Shift-Right — праворуч, у реальне середовище після деплою. Один без іншого — це як закрити двері, але залишити вікна навстіж.

ЩО ТАКЕ SHIFT-LEFT, І НАВІЩО ВІН ПОТРІБЕН

Тут читач, знайомий із класичним розподілом «спочатку пишуть — потім тестують», може запитати мене: «А навіщо тестувальник на етапі вимог? Ще коду немає!». Запитання слушне — тож розберімо на прикладі.

А якби тестувальник був із самого початку?

Повернімося до нашої «BlackBox Inc.». Пригадуємо: команда отримала коробку з документацією «робить щось чарівне» — і мусила тестувати наосліп. Результат ми знаємо — розгніваний замовник і звіт, від якого нікому не стало легше.

А тепер уявімо альтернативний сценарій. Тестувальника залучають ще на етапі аналізу вимог — до того, як хтось почав збирати коробку. Перше, що він запитав би: «Як саме ця коробка має працювати? Що мається на увазі під "чарівним"? Які функції вона повинна виконувати? І головне — як ми перевіримо, що вона працює належним чином?»

Ці запитання змусили б менеджера уточнити вимоги. Інженери отримали б конкретне ТЗ замість «щось чарівне». А тестувальники — зрозумілі критерії прийняття, за якими можна побудувати реальні перевірки.

Одне запитання на старті замість судового позову в кінці. Саме в цьому суть зсуву ліворуч.

ЩО ТАКЕ SHIFT-LEFT НА ПРАКТИЦІ

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

Аналіз вимог разом із QA. Тестувальники знаходять логічні суперечності в документації до початку розробки. Включіть QA у груминг user stories і технічні обговорення — зламайте силоси між командами.
Юніт-тестування — перший рубіж. Перевіряємо функціональність окремих модулів застосунку. Кожен модуль тестується ізольовано — взаємодія із зовнішніми процесами імітується або «мокується». Тісно пов'язане з TDD — це найближчий до коду рівень Shift-Left, і звісно QA мають контролювати і цю фазу тестування.
Інтеграційне тестування — другий рубіж. Далі, перевіряємо, як сервіси або компоненти застосунку працюють разом, включно з побічними ефектами. Важливо: цей підхід може перетворитися на антипатерн, якщо ним зловживати — але про це окремо.
API-тестування і контрактне тестування. Перевіряємо зовнішні точки входу (ендпоінти) сервісу. У контексті мікросервісної архітектури вони фактично виконують роль «нових юніт-тестів» — бо фокусуються на взаємодії між сервісами, а не всередині одного.
Автоматизація в CI/CD — «ворота якості». Тести запускаються автоматично на кожен коміт і миттєво сигналять про проблему, поки вона ще маленька. Використовуйте версіоновані набори тестів, що розвиваються разом із застосунком.
Ранні тестові середовища. Відтворюйте конфігурації продакшену на стейджингу — щоб виявляти специфічні для середовища дефекти ще до повної інтеграції.
Моніторинг ефективності тестів. Рефакторьте надлишкові тести, видаляйте малоцінні кейси. Відстежуйте «нестабільні» (flaky) тести і хибнопозитивні спрацювання.

АЛЕ SHIFT-LEFT НЕ ВСЕ СИЛЬНИЙ

І ось тут — найважливіше. Навіть найдосвідченіша команда, яка бездоганно впровадила Shift-Left, не може передбачити все.

Є цілий клас проблем, що існують лише в реальному бойовому середовищі:

Масштабування. Тест із 10 запитами проходить ідеально. А от 10 000 одночасних користувачів — зовсім інша історія.
Реальна поведінка користувачів. Люди клікають там, де не очікуєш. Вводять дані, які жоден тест-кейс не передбачав.
Взаємодія із зовнішніми системами. Платіжний шлюз, поштовий сервіс, стороннє API — вони поводяться непередбачувано саме тоді, коли це найбільш незручно.
Вразливості безпеки. Деякі з них проявляються лише під реальним навантаженням або цілеспрямованими атаками.

Навіть якби «BlackBox Inc.» отримала ідеальне ТЗ і протестувала коробку вздовж і впоперек у лабораторних умовах — вони б не виявили, що магія не працює кожну третю п'ятницю через фазу місяця. Таке можна з'ясувати тільки в умовах реального використання.

ЩО ТАКЕ SHIFT-RIGHT, І ЧИМ ВІН ВІДРІЗНЯЄТЬСЯ

Shift-Right — це тестування після деплою, у живому продакшн-середовищі. Не замість Shift-Left, а на доповнення до нього. Деякі проблеми можна побачити лише тоді, коли система реально працює під реальним навантаженням.

Основні інструменти Shift-Right

Моніторинг продуктивності через такі інструменти, як наприклад Grafana або New Relic. Ми бачимо систему в реальному часі: де виникають затримки, де падає продуктивність, де вузьке місце.

A/B-тестування. Порівнюємо дві версії на реальних користувачах — і дізнаємося, яка справді зручніша, а не яка здається такою в лабораторних умовах.

Canary releases та blue-green deployment. Нова версія спочатку потрапляє до невеликої частини користувачів. Якщо щось пішло не так — відкотитись легко, бо більшість клієнтів ще на старій версії.

Chaos Engineering. Ми самі свідомо «ламаємо» систему — вимикаємо сервіси, імітуємо збої мережі — і дивимося, чи вона відновлюється так, як ми очікуємо. Підхід, популяризований Netflix ще у 2011 році: краще самому знайти слабке місце, ніж дочекатися, доки це зробить аварія.

Безперервне сканування безпеки. Система в продакшні — мішень. Постійний моніторинг і відстеження аномалій дозволяють реагувати до того, як інцидент став катастрофою.