Июнь 17

Зменшення часу релізів, розширення команди, автоматизація. Як тестувати проєкт, що масштабується

Я працюю Senior QA Engineer в компанії Astound Commerce та виконую функції ліда команди тестування протягом останнього року. Поділюся з вами досвідом тестування одного з найбільш глобальних і динамічних ecommerce-проєктів, результати якого забезпечили нам перемогу в номінації Best Overall Testing Project під час Retail на North American Software Testing Awards в Торонто та допомогли стати фіналістом у тій же номінації на European Testing Awards у Лондоні торік. Враховуючи трирічний досвід на цьому проєкті, у статті розповім про виклики, з якими довелося зіткнутися, і те, як змінювались підходи та процеси відповідно до глобального масштабування проєкту.

Ілюстрація Уляни Патоки

Специфіка ecommerce-ринку та проєкту

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

Щоб оцінити сферу електронної комерції, пропоную кілька важливих цифр минулого року, які демонструють масштаби цього напряму:

1/4 населення світу купує онлайн;
9,6 млн ecommerce-магазинів глобально;
340 млрд доларів становить щорічний обсяг онлайн-продажів;
51% британців здійснюють онлайн-покупки, і це найбільший показник серед країн ЄС.

Далі йтиметься саме про британського гравця сфери ритейлу, клієнта Astound Commerce — Boohoo Group. Наша співпраця розпочалась у 2016-му, і від початку це був складний проєкт. Клієнт звернувся з питанням щодо платформи, на якій побудований ecommerce-бізнес бренду. Старе рішення на Venda не давало змоги впоратись з навантаженням, що генерували клієнти Boohoo, і не могло забезпечити усі потрібні кастомізації. На базі аналізу всіх потреб замовника та технічних можливостей запропонованого рішення дійшли згоди реалізувати проєкт на Salesforce Commerce Cloud (SFCC), що має низку ключових переваг порівняно з іншими платформами:

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

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

Після пів року плідної роботи ми запустили ecommerce-рішення для бренду Boohoo, паралельно працюючи над його глобальним масштабуванням. Згодом в реліз пішло ще два проєкти для інших брендів Boohoo Group — boohooMAN та Nasty Gal. І все це під час збільшення обсягів замовлень зі 120 тис. до 400 тис. одиниць товару, і це лише в межах однієї локалі Boohoo.

На початку 2019-го у QA-команді проєкту було чотири інженери, а проєкт Boohoo Group мав три повноцінні бренд-сайти, 26 локалей, понад 12 млн активних користувачів та більш як 30 млн замовлень щорічно. Кількість інтеграцій та кастомізацій з кожним релізом теж зростала та налічувала близько 10 різних методів оплати та стільки ж способів доставки товарів, потрібних для забезпечення потреб користувачів з різних країн. Намагаючись підлаштуватись під постійні зміни клієнта, ми використовували гібридний підхід, що поєднував Kanban і Scrum, а також стабільні шеститижневі релізи.

Сьогодні ж у QA-команді вісім QA і три ТА-інженери, а проєкт розвинувся до 6 бренд-сайтів і 42 локалей. Обсяг продажів за минулий рік зріс щонайменше на 48% і сягнув більше ніж мільйона замовлень на місяць у межах однієї ключової локалі. Протягом нашої співпраці розвивалась і технічна складова проєкту:

кількість способів оплати зросла до 16 систем, включно з найбільш поширеними — оплата платіжними картками, PayPal, Apple Pay, Google Pay, Klarna тощо;
імплементовано низку нових antifraud-систем;
збільшено кількість варіантів доставки.

Паралельно з командою Astound Commerce над проєктом працюють кілька відокремлених команд з боку клієнта: Front-еnd, UX, SEO, Marketing, Application Integration. За цей час відбулись значні зміни у підходах до розробки. Крім того, команда почала працювати ще в інтенсивнішому режимі, використовуючи Scrum Framework та оптимізовуючи релізи до двотижневих спринтів.

Далі розповім про основні виклики, з якими зіштовхнулися тестувальники, та підходи до їх вирішення.

Ключові виклики QA-команди на проєкті

1. Перехід до Scrum Framework і двотижневих спринтів. Перший серйозний виклик ми зустріли, коли потрібно було виконувати більші обсяги робіт, але значно ефективніше та за коротший час. Можна сказати, що зі слів пісні гурту Daft Punk «Work it harder, Make it better, Do it faster» розпочався наш перехід до Scrum Framework зі стабільними двотижневими спринтами. Для всієї QA-команди це означало потребу в оптимізації всіх процесів, особливо регресійного Pre-production тестування. Наші звичні шеститижневі релізи змінились на двотижневі: часу на тестування та стабілізацію спринтів ставало все менше, а більші обсяги завдань виконували ті ж чотири QA-інженери.

Після невеликої адаптації команди до нового підходу наступним викликом став стрімкий запуск нового бренд-сайту, розробку та тестування якого паралельно проводила Scrum-команда. Проте розширення проєкту на цьому не закінчилось. Уже за деякий час після старту роботи з новим брендом Boohoo Group ми отримали запит від клієнта на розробку ще двох бренд-сайтів у стислі терміни (всього за півтора місяця), якими також мали займатися дві паралельні команди. В результаті у 2019-му на проєкті працювали чотири команди.

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

У межах цього етапу реалізували низку змін:

використали Scrum Framework для планування спринтів;
створили нову структуру команди з відповідними ролями та обов’язками;
визначили критерії для формування Sprint Backlog і залучення Business Analyst, Solution Architect на цьому етапі;
сформували підхід до естімації спринту та резервування буферу;
визначили підходи до розробки, тестування, в який момент починається Code Freeze та як проходить регресійне тестування;
розробили критерії здавання скоупа спринту та готовності до релізу.

2. Підтримка масштабування проєкту. Оскільки масштаби рішення зростали щодня, як і кількість брендів і локалей, час на тестування кожної наступної інтеграції, її підтримку теж збільшувався (прямо пропорційно до кількості нових локалей). Якщо говорити мовою цифр, то під час переходу команди до Scrum Framework з двотижневими релізами проєкт мав у своєму складі 3 бренди, 26 локалей та близько 10 платіжних систем.

Регресійне тестування проводили на release candidate впродовж неповних трьох днів, воно охоплювало близько 855 логічних тест-кейсів, що покривали критичну функціональність і основні user journeys для всіх платіжних систем, методів доставки тощо.

За рік на нас чекав ще один виклик. Часові рамки залишалися ті самі (навіть при збільшенні штату QA-команди вдвічі), однак обсяг тестування зріс у рази: кількість локалей збільшилась до 42, а платіжних систем — до 15 без врахування імплементацій інших інтеграцій. Саме в цій ситуації перед нами постало стратегічне питання: як підтримувати наявні підходи та вписуватись у відведений час, не втративши при цьому якість продукту? Адже кількість тест-кейсів, які команда мала покрити за неповні три дні, сягнула майже 2800!

3. Робота з live cases в умовах 13-мільйонної аудиторії покупців. Однією з реалій проєктів, які перебувають у live, є наявність live cases (дефектів або різноманітних запитів), що можуть надходити від Support-комади чи безпосередньо від команди клієнта. Зазвичай складність таких кейсів полягає у повній відсутності ключових даних, що свідчать про першопричину проблеми.

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

На проєкті Boohoo із 13-мільйонною аудиторією активних користувачів ми стикнулися не з одним еdge case. Для команди робота з такими live cases може вилитись у десятки годин пошуків причин проблеми та шляхів її вирішення. Одним із чинників, які ускладнюють процес тестування і виявлення схожих дефектів на ранніх стадіях, є глобальна діджиталізація користувачів і, як наслідок, одночасне використання різних гаджетів під час онлайн-шопінгу.

Також поширеним є Multi-Tab shopping — одночасне використання багатьох вкладок браузера під час онлайн-покупок. Для бізнесу це спричиняє недоотримані прибутки: при комбінації неочікуваних кроків клієнти можуть оформити замовлення, не оплативши його реально. Час від часу виникають проблеми й під час доставки товару. Певна інформація може бути втрачена або викривлена через непередбачуваний порядок дій користувача.

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

Наведу приклад кейсу, який стався на проєкті Boohoo. Одному із 360 тисяч користувачів вдавалось купувати онлайн-товар, що не потребував безпосередньої доставки. Однак людина здійснювала покупку таким чином, що адреса для доставки товару опинялася в замовленні. Це не могла заздалегідь передбачити ні наша система, ні складська система клієнта. В результаті такого незначного дефекту автоматизовані складські системи Boohoo давали збій від схожих замовлень і потребували додаткового втручання в роботу.

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

Зміни у підходах до тестування

Pairwise testing як простий шлях до оптимізації регресійного тестування

Однією із найнеобхідніших змін у процесі роботи виявилась оптимізація чек-листа, який ми використовували для регресійного Рre-рroduction тестування. Ми вирішили змінити Exhaustive-тестування під час фіналізації спринту на більш оптимальний підхід, що мінімізував би кількість тестових сценаріїв та зберіг би унікальність user journeys і покриття сценаріями всієї критичної функціональності.

Оптимальним варіантом для нас став перехід на Pairwise testing (про нього розповім нижче). Він давав можливість зменшити кількість тестових сценаріїв та оптимізувати чек-лист з 2800 тест-кейсів до 800. Однак залишались побоювання, що не все протестовано і є велика ймовірність того, що реліз буде невдалим, а певні проблеми з’являться вже на Production.

Аналізуючи всі переваги та ризики, ми вирішили все-таки використати Pairwise для формування регресійних Рre-production чек-листів, але для мінімізації ризиків неповного покриття функціональності тестами спочатку застосували 3-wise покриття з подальшим переходом до 2-wise (3-wise тестування є деталізованішою формою 2-wise (Pairwise) тестування). Так змогли оцінити й реальний вплив на якість релізів.

Після випробувань «у реальному бою» ця техніка стала обов’язковою для використання. Ми змогли оптимізувати тестування і зменшити кількість тест-кейсів, а також ненависної рутинної роботи. Зменшився і час для знаходження інших, деколи більш важливих проблем, оскільки чек-лист став різноманітнішим, якщо порівнювати з попередньою версією. Раніше QA-інженеру доводилось фокусуватись на детальному тестуванні однієї функціональності, перш ніж перейти до іншої. А ще це звільнило час на ad-hoc тестування як на допоміжний інструмент під час фіналізації спринту.

Тестування еdge cases як окрема культура тестування на проєкті

Як уже було сказано, еdge case — це проблема, що виникає тільки в крайніх випадках. Думаю, кожен QA-інженер був у ситуації, коли після репорту чергового цікавого багу, над яким так довго «шаманив і фантазував», чув висновок розробників, що це еdge case і ніхто це фіксити не буде. Та everything is possible, особливо при мільйонах замовлень щомісяця. Тоді, хоч і жартома, але розумієш: що більш шалена твоя команда, то більш ефективно і на ранніх стадіях вона спроможна відловлювати дефекти.

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

Multi-Tab shopping — тестування цієї групи проблем зводиться до генерації різноманітних сценаріїв, в яких людина купує товари, використовуючи кілька вкладок у своєму браузері. Як приклад можемо розглянути ситуацію, коли користувач в одній вкладці браузеру перебуває безпосередньо на сторінці оплати замовлення, а в іншій — продовжує обирати товари. Змінивши вміст своєї корзини, клієнт повертається до першої вкладки, бачить там ще старий вміст і вирішує оплатити саме його. У вас виникає питання: що ж буде далі? А це вже доведеться дізнатись самостійно. Кожна система унікальна і буде реагувати на однакові сценарії по-різному. Та можу сказати з впевненістю: якщо добре пропрацювати такі ситуації, ви точно знайдете дефекти. Пам’ятайте: сценарії завжди можна ускладнювати, додаючи промокоди, подарункові сертифікати та інші фічі. І що їх більше, то більше місця для вашої фантазії та вища ймовірність знайти дефект.

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

Розглянемо поширений сценарій. Зареєстрований користувач увійшов у систему та перебуває на сторінці оплати замовлення, обирає спосіб оплати, що потребує його реєстрації на окремій сторінці банку або платіжного сервісу. Ця процедура може займати багато часу або при реєстрації користувач може відволіктись. Для системи такий користувач є неактивним, адже в цей момент перебуває на сторінці стороннього сервісу. З міркувань безпеки система інтернет-магазину змусить його примусово вийти з профілю за 30 хвилин. Найімовірніше авторизація таких замовлень викликатиме критичні проблеми в їх опрацюванні, адже відбудеться конфлікт логіки дій. У результаті користувач здійснить оплату, але на сайті замовлення не опрацюється.

Єдиної техніки тест-дизайну для еdge cases немає. Все залежить від того, наскільки досвідчена команда та наскільки ви сфокусовані на схожих проблемах, бо це важливо далеко не для кожного проєкту. Для себе ми обрали кілька підходів, які допомагають краще аналізувати систему, знаходити вразливі місця та еdge cases:

Brainstorming — підхід, за якого команда генерує максимальну кількість нестандартних сценаріїв і ситуацій, в яких система теоретично може поводитися неочікувано. Ще один плюс — обмін знаннями та досвідом у команді.
Defect clustering — один із базових принципів тестування, який показує вразливі місця системи. Створені вами метрики показуватимуть дефекти та їхню кількість у кожному компоненті системи. Це дасть змогу динамічно та ефективно відстежувати, які компоненти є найуразливішими, потребують детального тестування та використання додаткових технік тест-дизайну.
Defect Based + Experience Based Techniques. Використовуйте Defect Taxonomy та свій досвід для створення оптимальних чек-листів. Цей підхід є одним з основних на нашому проєкті. Він є ефективним, дає видимі результати та полегшує роботу. Тому далі розповім детальніше про нього.

Практичне використання Defect Based та Experience Based технік і їхні переваги в межах long-term проєктів

На схожих масштабних проєктах ефективним є використання та поєднання Defect Taxonomy та Experience Based технік, про які більшість QA-інженерів часто забуває або ж ігнорує. Формування Defect Taxonomy та Experience Based чек-листа базується на створенні унікального списку сценаріїв, притаманних для певних компонентів і системи загалом.

У межах завдань на нашому проєкті, а це понад 15 тисяч тікетів, баг-репортів і різноманітних change requests, команда інтегрувала та протестувала не одну функціональність. Саме правильний аналіз результатів тестування полегшив і пришвидшив роботу в майбутньому. Аналізуючи дефекти, які були зареєстровані в Bug Tracking System, ми змогли виділити певні їх групи та сценарії, які викликають проблеми в роботі з конкретною функціональністю. Таким чином створили чек-лист, що враховує наш досвід та історію системи. Постійно доповнюємо його, беручи до уваги аналіз нових дефектів і тестування нових інтеграцій.

Створення оптимального чек-листа, що враховуватиме особливості та вразливі місця системи, дає QA-команді такі переваги:

Зменшення часу на тест-дизайн та загальну естімацію, оскільки такі чек-листи можна легко повторно використати та адаптувати під час інтеграції функціональності (особливо актуально, коли відбувається інтеграція вже 16-ї платіжної системи).
Можливість знайти більшу частину дефектів на ранніх стадіях тестування, адже більшість буде враховано в чек-листі.
Самоперевірка команди розробки за допомогою чек-листа.
Доповнюваність і підтримка за умови постійного використання.
Можливість адаптації таких чек-листів під інші проєкти.
Зручний інструмент для того, щоб ділитись знаннями з новими членами команди та для загального підвищення рівня експертизи.

Автоматизація тестування та її переваги

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

Phase 1

Мета першої фази — створити MVP-версію, яка б уже на цьому етапі допомогла команді Manual testing зменшити обсяг роботи та швидко отримувати результати автотестів. У межах першої фази ми покрили головні user journeys та основну функціональність. Навіть такі мінімальні зміни частково пришвидшили регресійне Рre-рroduction тестування.

Phase 2

На цьому етапі розширили наявний фреймворк. Крім того, збільшили покриття автотестами основної функціональності (платіжні системи та способи доставки товарів), а також функціональності брендів і локалей. Manual QA-команда отримала реальну допомогу в Pre-рroduction тестуванні: 80% платіжних систем і 4 бренди було покрито автотестами. Це дало змогу більше сфокусуватись на складніших сценаріях і функціональності, яка не була автоматизована.

Phase 3

Етап створення test suites та окремих user journeys для покриття Build acceptance. Крім того, ми виконали автоматизацію досі не покритої та зовсім нової функціональності. Імплементація цієї фази дала змогу оптимізувати процес Build acceptance тестів для Manual QA-команди та зменшити час на їх проведення. Також автоматизований test suite для Build acceptance був значно ширшим, ніж при Manual testing, що дало змогу отримати швидкі результати з більшої кількості перевірок.

Phase 4

Запланували збільшення покриття функціональності та автоматизацію тестів на другорядних браузерах — Internet Explorer 11, Firefox.

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

час, який витрачала Manual QA-команда на Regression та Smoke testing, зменшився на 35%;
збільшилось загальне покриття тестами всієї функціональності;
ми заощадили понад 1500 годин роботи Manual QA-команди за рік, які раніше витрачали на Regression testing та Build acceptance, тільки через покриття автоматизованими тестами функціональності чотирьох з шести брендів.

Висновок

Підсумовуючи результати роботи над проєктом Boohoo Group за минулий рік, QA-команда:

зменшила час релізів з шести до двох тижнів;
збільшила команду з 4 QA-інженерів до 8 QA- та 3 TA-інженерів;
імплементувала три фази автоматизації;
оптимізувала Regression та Build acceptance тестування;
розгорнула 40 код-версій (як мажорних, так і мінорних).

Загалом клієнт залишився задоволений роботою, адже всього за рік нам вдалося реалізувати для Boohoo Group такий список рішень:

Розроблено три нових бренд-сайти.
Запущено 16 нових локалей.
Локалізовано 10 локалей.
Запущено 6 нових платіжних систем і кілька десятків інших інтеграцій.
Розроблено низку редизайнів і вдосконалень.

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