Як синхронізувати тестування функціоналу на бекенді та клієнтах. Досвід Wirex

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Всім привіт! Я — Євгенія Опанасенко, B2C QA Team Lead британської фінтех-компанії Wirex, продукт якої дозволяє використовувати цифрові та традиційні валюти в одному додатку та оплачувати криптовалютою будь-які покупки. Оскільки ми працюємо з грошима, нам вкрай важливо забезпечити стабільну роботу продукту, зокрема роботу мобільних додатків та веб-версії продукту в інтеграції з бекенд-сервісами. Тому якщо ви або ваша команда стикалися з проблемою синхронізації тестування функціоналу даних компонентів, то ця стаття саме для вас.

Глобально команда розробки Wirex розділена на юзер-аплікейшн та бекенд-частини. Юзер-аплікейшн переважно займається усім, що стосується візуальної частини розробки, а бекенд — розробкою логіки функціоналу. Наш продукт надає можливість користувачам працювати з різними типами застосунків — як з веб, так і з мобільними версіями (IOS та Android), тому команди розділені на веб та мобайл. На бекенді ми звикли називати їх загально — клієнтами.

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

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

Оскільки домен B2C (Business To Customer) — єдина точка входу для клієнтів, команда B2C QA повинна знати і базово орієнтуватися в інтеграції всіх доменів з B2C-доменом. Наша команда пов’язана з інтеграцією бекенд-функціоналу на клієнтах, і ми тісно взаємодіємо з відповідною командою тестування.

Проблема ізольованого тестування на бекенді та клієнтах

Коли ми працюємо над новим функціоналом продукту, наприклад, замовленням дебетових карт або Х-Accounts — накопичувальними акаунтами на базі децентралізованих фінансових додатків (DeFi), релізи бекенду, веб та мобільних застосунків часто відбуваються одночасно. Раніше ми тестували функціонал окремо на клієнтах та окремо на бекенді. При такому підході перевірка одного і того ж фінансового сервісу могла ніяк не збігатися у часі. І оскільки ми працюємо з фінтех-продуктом, ми повинні швидко реагувати на зміни, однак не завжди зміни на бекенді потребують того самого і на клієнтській стороні.

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

Наприклад, у нас є сервіс Send Money to Contacts, і один з клієнтів при реалізації доступності цього функціоналу користувачам отримував дані з двох різних джерел, що є надлишковим; інші ж клієнти взяли за «Source of True» одне джерело — дані, отримані з бекенд-сервісу, що керує доступними діями на акаунті користувача, що і було правильним рішенням.

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

Як синхронізувати тестування бекенду та клієнтів

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

Ми давно погодились з тим, що бекенд — «розумний», а клієнт — «красивий», що означає, вся логіка продукту закладена в рамках бекенд-мікросервісів, і відповідно, більшість тестування проводиться саме командою бекенд QA. У такому разі бекенд як сукупність команд повинен ініціювати порядок розробки та тестування функціоналу, тобто пропонувати рішення проблем і допомагати розібратися з деталями роботи фічі.

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

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

Щоб зібрати логіку поведінки клієнтів в один флоу для всіх і зробити процес тестування простішим та ефективнішим, ми вирішили розпочинати тестування з перевірки вимог до функціоналу. А також проводити Knowledge Transfer сесії (КТ) для бекенд та клієнт-команд QA.

Knowledge Transfer-сесії і як ми їх проводимо

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

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

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

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

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

Налаштування середовища

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

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

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

Процес тестування та аналіз помилок на клієнтах

У процесі активного тестування бекенд-QA виступають у ролі «щита» між клієнтами та бекенд-девелоперами, фільтруючи запитання та помилки, що виникають у клієнтів під час використання нового функціоналу. За допомогою логів та розуміння функціоналу можливо одразу відповісти на запитання як тестувальників, так і девелоперів, або дізнатись про деталі проблеми, якою була викликана та чи інша помилка.

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

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

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

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

Запуск функціоналу в продакшн

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

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

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

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

Що ми отримали

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

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

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

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

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

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

дякую, нарешті цікава стаття про QA

Підписатись на коментарі