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

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

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

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

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

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

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

Далі йтиметься саме про британського гравця сфери ритейлу, клієнта Дивувати 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-систем;
збільшено кількість варіантів доставки.

Паралельно з командою Дивувати 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, System 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 давали збій від схожих замовлень і потребували додаткового втручання у роботу.

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

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

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

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

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

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

Після випробувань «у реальному бою» ця техніка стала обов'язковою для використання. Ми змогли оптимізувати тестування і зменшити кількість тест-кейсів, а також ненависної рутинної роботи. Зменшився і час для знаходження інших, деколі більш важливих проблем, оскільки чек-лист став різноманітнішим, якщо порівнювати з попередньою версією. Раніше 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 та основну функціональність. Навіть такі мінімальні зміни частково пришвидшили регресійне Рге-р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 нових платіжних систем і кілька десятків інших інтеграцій.
Розроблено низку редизайнів і вдосконалень.

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

Опубліковано: 16/06/20 @ 10:00
Розділ Різне

SEO Блог