Повний цикл якості: чому ваша команда потребує і Shift-Left, і Shift-Right підходів

Чи знаєте ви, що підхід Shift-Left у тестуванні дозволяє виявляти та усувати проблеми до того, як вони стануть помилками? У сучасному світі розробки програмного забезпечення ми постійно шукаємо способи підвищення якості продукту без збільшення термінів розробки.

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

Проте лише раннього тестування недостатньо. Shift-Right – зміщення тестування після деплою на продакшн, дозволяє перевірити систему в реальних умовах. У цій статті ми розглянемо, як поєднання обох підходів створює повний цикл якості, та чому сучасним командам необхідно впроваджувати безперервне DevOps тестування, що передбачає більш раннє й часте тестування, повсюдне тестування та автоматизацію.

Підхід Shift-Left у тестуванні знаменує собою фундаментальну зміну в процесі забезпечення якості програмного забезпечення. На відміну від традиційного підходу, де тестування починається після завершення розробки, Shift-Left зміщує процеси тестування до самого початку життєвого циклу розробки. Головна мета такого підходу − запобігання помилкам замість їх подальшого виявлення.

Насамперед підхід Shift-Left у тестуванні передбачає залучення тестувальників ще на етапі формулювання вимог до продукту. Це дозволяє заздалегідь виявити логічні суперечності або неясності в документації. Фактично, тестувальники допомагають відповісти на важливе запитання: «Чи можна це протестувати?» ще до початку написання коду.

Під час аналізу вимог тестувальники виконують такі завдання:

• ревізія та рецензування вимог для виявлення логічних суперечностей;
• формування сценаріїв тестування на ранніх етапах розробки;
• визначення критеріїв прийняття для функціоналу;
• аналіз можливих ризиків.

Багато інженерів мають проблему сприйняття вимог, яку влучно описують виразом «за деревами не бачу лісу». Вони настільки захоплюються ідеями програмування чи тестування вимог, що не звертають уваги на їхню кінцеву мету — розв’язування проблем користувачів. За такого підходу тестувальники можуть виявити проблеми ще до того, як буде написано код.

Наступний етап реалізації Shift-Left − це впровадження тестування на рівні модулів. Розробники активно пишуть юніт-тести для перевірки окремих функцій або модулів коду. Юніт-тести характеризуються низькою вартістю та високою швидкістю запуску, вони не вимагають окремого тестового середовища.

Після цього проводиться інтеграційне тестування, яке перевіряє взаємодію між різними модулями програми. Інтеграційне тестування виконується після модульного тестування та перед верифікацією і валідацією ПЗ. Метою інтеграційного тестування є верифікація вимог з функціональності, продуктивності та надійності основних компонентів програми.

Важливо, що до інтеграційного тестування приступають тільки після модульного. Це дозволяє реалізувати стратегію «будівельних блоків», коли до верифікованої системи інтегруються верифіковані модулі. Таким чином, дефекти виявляються на ранніх стадіях розробки, коли їх виправлення коштує значно менше.

Автоматизація тестування є ключовим елементом підходу Shift-Left. Для цього використовуються системи безперервної інтеграції (Continuous Integration System, CIS), які значно пришвидшують процес тестування.

Принцип дії таких систем включає:

• моніторинг системи контролю версій;
• оновлення локальної версії при змінах коду в репозиторії;
• запуск модульних тестів;
• збирання програмних модулів;
• виконання інтеграційних тестів;
• генерація звіту.

Автоматичні тести запускаються відразу після внесення змін, що дозволяє виявити та усунути помилки за короткий проміжок часу. Такий підхід суттєво скорочує витрати на розробку і тестування, адже вартість і наслідки виправлення помилок збільшуються пропорційно до того, як пізно виявляється проблема.

Впровадження підходу Shift-Left має значні переваги для команд розробки:

• скорочення витрат на розробку та тестування;
• створення якісного та чистого коду;
• краща координація між розробниками й тестувальниками;
• економія часу коштом раннього виявлення дефектів;
• підвищення задоволеності клієнтів завдяки стабільнішому продукту.

Однак, навіть за всіх переваг раннього тестування, підхід Shift-Left має певні обмеження, які важливо враховувати при побудові ефективної стратегії забезпечення якості.

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

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

• комбінації дій, які здаються нелогічними для розробників, але є природними для користувачів;
• використання системи не за призначенням або неочікуваним чином;
• одночасний доступ великої кількості користувачів з різними пристроями.

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

Ще однією вагомою проблемою раннього тестування є відсутність зворотного зв’язку від реальних користувачів. Тестувальники можуть оцінити функціональність, але не можуть повністю відтворити суб’єктивний досвід користувача.

Зокрема, вони не мають змоги оцінити:

• інтуїтивність інтерфейсу для людей з різним рівнем технічної підготовки;
• зручність використання функцій у повсякденних сценаріях;
• емоційну реакцію на дизайн і взаємодію.

Фактично, без відгуків користувачів, команда розробки може створити технічно досконалий продукт, який, однак, не відповідатиме очікуванням аудиторії або не вирішуватиме їхніх реальних проблем. Відсутність такого зворотного зв’язку унеможливлює вдосконалення користувацького досвіду.

Існує цілий клас проблем, які практично неможливо виявити до запуску продукту в експлуатацію.

До них належать:

• проблеми масштабування при великому навантаженні;
• затримки та вузькі місця, які виникають лише при взаємодії з іншими системами в реальному часі;
• складні помилки, що проявляються лише за певних умов або після тривалого використання;
• вразливості безпеки, які можуть бути виявлені тільки в реальному середовищі.

Саме тому важливим є підхід Shift-Right − тестування вже після розгортання програми на продакшн-серверах. Цей метод дозволяє перевірити програмне забезпечення під бойовим навантаженням, побачити його поведінку на реальних даних та виявити приховані проблеми.

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

Shift-Right підхід переносить тестування на етап після розгортання системи в бойовому середовищі. Цей метод ґрунтується на принципі, що незалежно від того, наскільки ретельно ви тестуєте продукт перед релізом, деякі проблеми проявляються лише в реальних умовах експлуатації. Фактично, тестування в реальному середовищі використовує справжні розгортання для перевірки поведінки та продуктивності додатка.

Основою підходу Shift-Right є постійний моніторинг системи. Для цього використовуються спеціалізовані інструменти, найпопулярнішими з яких є Grafana та New Relic.

Grafana − це відкрита платформа для аналізу та візуалізації даних. Вона дозволяє створювати гнучкі інформаційні панелі та може обробляти, візуалізувати й аналізувати метрики незалежно від того, де вони зберігаються. Grafana відрізняється високим рівнем налаштування та підтримує понад 100 офіційних плагінів для джерел даних.

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

A/B тестування − це метод порівняння двох версій вебсторінки для визначення, яка з них працює краще. Цей підхід дає можливість поступово вдосконалювати користувацький досвід на основі реальних даних, а не припущень.

Існує кілька типів A/B-тестування:

• спліт тестування − порівняння двох абсолютно різних версій сторінки;
• багатоваріативне тестування (A/B/n) − одночасне тестування кількох елементів;
• тестування воронки продажів − оцінка кожного кроку шляху користувача.

Canary releases (канаркове розгортання) − це стратегія, при якій нова версія програмного забезпечення поступово надається невеликій підгрупі користувачів. Цей підхід дозволяє рано виявити проблеми, мінімізуючи їх вплив на всю базу користувачів.

Blue-green deployment (синьо-зелене розгортання) − це стратегія, яка використовує два ідентичних виробничих середовища: «синє» (поточне) та «зелене» (нове). Після повного тестування в «зеленому» середовищі, трафік швидко перемикається з «синього» на «зелене».

Основні відмінності між цими підходами:

• стратегія впровадження − повне перемикання проти поступового;
• час простою − майже нульовий при blue-green проти мінімального при canary;
• вимоги до ресурсів − вищі для blue-green, оскільки потрібно підтримувати два повноцінних середовища.

Chaos Engineering − це підхід, популяризований компанією Netflix у 2011 році, який дозволяє проактивно виявляти вразливості систем через контрольоване введення відмов. Цей метод особливо важливий, враховуючи, що значна кількість компаній стикається з відмовами систем.

Особливо критичним цей підхід є для фінансових систем, медичних платформ та електронної комерції, де навіть кілька хвилин простою можуть коштувати значні збитки.

Ключові компоненти Chaos Engineering:

• формулювання гіпотези про очікувану поведінку системи під час збою;
• автоматизація механізмів відновлення;
• ретельний моніторинг ключових метрик системи.

До речі, рекомендуємо до перегляду вебінар про Chaos Engineering на каналі EPAM Career.

Безпека − це область, де підхід Shift-Right особливо цінний. Після виходу продукту в продакшн він стає мішенню для зловмисників. Безперервне сканування системи на вразливості та імітація атак дозволяють підтримувати високий рівень захисту.

Ключові аспекти безпеки Shift-Right включають:

• безперервний моніторинг і ведення журналу для відстеження поведінки додатків;
• тестування в реальних умовах (Chaos Engineering);
• проактивне реагування на інциденти з чітким планом дій.

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

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

Життєвий цикл розробки програмного забезпечення можна уявити як своєрідний континуум з лівою та правою сторонами. Ліворуч розташовані етапи проєктування, розробки та підготовки до випуску, праворуч – розгортання та експлуатація.

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

Обидва методи ефективно виявляють різні типи помилок:

• Shift-Left найкраще підходить для виявлення логічних помилок, дефектів у коді, помилок у проєктуванні та порушень вимог;
• Shift-Right незамінний для виявлення проблем продуктивності, уразливостей безпеки та збоїв при реальних сценаріях використання.

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

Різні підходи до тестування передбачають різний розподіл відповідальності між командами:

• при Shift-Left тестуванні активно залучаються QA-інженери та розробники, які тісно взаємодіють на етапі розробки;
• у Shift-Right підході ключову роль відіграють SRE-інженери, операційні команди та спеціалісти з моніторингу, які часом працюють спільно з тестувальниками.

Важливо зазначити, що підхід DevSecOps (поєднання розробки, безпеки та операцій) є ключовим для ефективної інтеграції обох стратегій. Він заохочує співпрацю між командами безпеки та розробки, створюючи культуру спільної відповідальності.

Отже, вибір між Shift-Left і Shift-Right не є питанням «або/або» – сучасні команди розробки програмного забезпечення потребують збалансованого підходу, де Shift-Left забезпечує раннє виявлення дефектів, а Shift-Right доповнює процес перевіркою в реальних умовах.

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

Для успішної інтеграції Shift-Left і Shift-Right підходів у DevOps-процеси командам варто застосовувати прагматичний підхід та зосередитися на створенні імпульсу. Фактично, команди можуть самостійно визначати, на якому етапі процесу DevOps виконувати кожен тест, використовуючи стратегії shift-left або shift-right для переміщення виконання різних типів тестів на більш ранні або пізні етапи процесу.

Інтеграція Shift-Left і Shift-Right у DevOps вимагає:

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

Розгортання в робочому середовищі має відбуватися прогресивно та контрольовано за допомогою розгортань на основі рівнів і прапорців функцій. Наприклад, краще виявити помилку, яка заважає покупцю завершити купівлю, коли менш ніж 1% клієнтів перебувають на цьому рівні розгортання, ніж після перемикання всіх клієнтів одночасно.

Зворотний зв’язок є життєво важливим компонентом безперервного тестування. Він має бути миттєвим на кожному етапі конвеєра доставки. Дієвий зворотний зв’язок дозволяє командам швидко реагувати на виявлені проблеми.

Однак справа не завершується на повному розгортанні. Відстеження телеметрії критично важливе для тестування в робочому середовищі. Команди часто використовують впровадження помилок і інженерію хаосу, щоб дізнатися, як система працює в умовах збоїв.

Такий підхід допомагає:

• перевіряти працездатність і якість заданого робочого розгортання;
• контролювати постійно змінне робоче середовище;
• виявляти аномалії за допомогою даних телеметрії тестів.

Тестові дані з робочого середовища – це буквально результати тесту з реального робочого навантаження клієнта. Отримавши результати на одному етапі, команда покращує наступний, що забезпечує стабільне підвищення якості. Завдяки цьому підходу команди з налагодженими CI/CD-процесами досягають вищої швидкості розробки без компромісів щодо якості.

Щоб ефективно використовувати реальні дані для покращення тест-кейсів, рекомендується:

• планувати час на покращення тест-кейсів;
• автоматизувати експерименти з впровадження помилок, оскільки вони є дорогими тестами, які мають виконуватися в системах, що постійно змінюються;
• відстежувати систему показників на високому рівні (здоров’я або борг, а також швидкість).

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

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

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

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

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

Ефективна інтеграція обох підходів у DevOps вимагає від команд:

• чіткого розподілу відповідальності між розробниками, тестувальниками та операційними інженерами;
• автоматизації процесів тестування на всіх етапах розробки та експлуатації;
• налагодження безперервного зворотного зв’язку між розробкою та експлуатацією;
• використання реальних даних для вдосконалення тестових сценаріїв та процесів.

Зрештою, якість програмного забезпечення − це безперервний процес, а не одноразова дія. Команди, які успішно поєднують Shift-Left і Shift-Right, здатні швидше випускати якісний продукт, який відповідає потребам користувачів. Такий підхід забезпечує не лише функціональну відповідність, але й продуктивність, безпеку та зручність використання в реальних умовах.

Повний цикл якості − це не просто модний тренд, а необхідність у сучасному світі розробки програмного забезпечення. Фактично, вміння балансувати між раннім тестуванням і перевіркою в продакшн-середовищі визначає конкурентоспроможність команд розробки у швидкозмінному технологічному ландшафті.