Як і для чого ми запроваджували Continuous Testing

Привіт, мене звати Роман Мельник. Я QA Lead в американському InsurTech стартапі Matic з офісами у Сан-Франциско, Лос-Анджелесі, Колумбусі і Львові. Ми змінюємо традиційну галузь страхування — одну з найбільш консервативних і регульованих індустрій в США. За лічені хвилини ми допомагаємо клієнтам підібрати оптимальний варіант страхування їхнього майна.

У цій статті я хочу поділитися нашим досвідом, це більше story of our life, як ми запроваджували процес continuous testing. Хтось, можливо, вже чув про це, для когось це стане новинкою. Стаття може бути особливо корисною тим, хто думав про перехід на такий процес, але вагався (так як було в нашому випадку).

Як ми тестували раніше

Почнемо з передісторії і з того, як тестування відбувалося в нас раніше. Працювали ми за традиційним тест-процесом. У нас був двотижневий спринт, на пленінгу ми обговорювали і оцінювали user story, писали тестову документацію. Потім, коли фічі були готові, вони йшли в тестування. Якщо все було гаразд, то задачі далі йшли на acceptance testing до продакт-менеджера, якщо ні — поверталися на доопрацювання. Реліз здійснювався раз на два тижні в понеділок, а в п’ятницю у нас було реліз-тестування на UAT-середовищі.

В принципі, працювало все нормально, але з розвитком і ростом продукту почали виникати деякі проблеми. Як приклад, це були проблеми зі зворотним зв’язком. Були випадки, коли ми могли 2-3 місяці розробляти якийсь функціонал і після його випуску клієнти говорили, що це не те, чого вони очікували, або що це взагалі непотрібна функціональність, якою ніхто не буде користуватися. Також проблеми були із хотфіксами, бо в гілці репозиторію могла назбиратись велика кількість іншого функціоналу і разом з хотфіксом не перевірений код міг потрапити на Production. Ну і тестування здійснювалося на 95% мануально, ми тільки найняли AQA, який починав писати автоматичні тести.

Щодо деплоїв

Раніше Matic використовував класичний git flow, коли є головна гілка (master), feature гілка, develop, release і master. Коли розробник закінчував свою задачу, її об’єднували в develop-гілку, СІ система спрацьовувала, тестувала ці зміни і розгортала функціонал на Staging. Потім QA тестували, а розробники робили мердж в develop. У кінці спринта ми давали команду, що все протестовано і що ми готові релізити, тоді розробники об’єднували свої зміни в release-гілку, і вона автоматично розгорталась на UAT. Після того, як продукт менеджери (PdM’s) перевірили і сказали, що все гаразд із задачами на UAT, реліз заливався в master, і це був кінець процесу.

Після мерджу, за допомогою тестів в master, відбувалася перевірка, чи зміни валідні і робочі, і ми збирали фінальний docker-образ. Потім тімлід брав його і розгортав на Production в ручному режимі.

Неозброєним оком видно, що це був довгий і складний процес, який часто ламався, був не надто ефективним та не передбачав zero down time (тобто в момент деплою система не працювала, ми також могли спостерігати багато помилок і т. п). Тому у DevOps команди вже не було сили терпіти і вона пішла вперед та почала просувати і робити Continuous Delivery pipeline. Ми зі свого боку їм допомагали в плані визначення релевантних quality gates.

Як змінився процес деплою

Ми залишили master і перейшли від git flow до гібридного trunk based development, залишили Pull Requests (далі — PR) і вирішили, що використовуємо feature гілки для PR, але відкриваємо їх лише щодо master. Розробка відбувається у feature гілках щодо master. З master починається наш головний процес розгортання, який автоматично стягує нові зміни (також ми маємо окремі пайплайни на PR, де присутні quality gates, які мають різні типи перевірок). Коли зміни готові до релізу, PR перевірений, має в собі feature flags (якщо може бути сумісний з ними), ми мерджимо. Запускається пайплан, який ще раз перетестовує зміни в master і зміни йдуть на Staging. Потім запускаються автоматичні тести, і на деяких проєктах пайплайн зупиняється, тому що є присутній елемент мануального тестування, а на деяких йде далі. І якщо всі етапи пайплайну успішні, ми робимо розгортання на Production. Після успішного розгортання ми оновлюємо кілька платформ щодо релізів — Sentry, Datadog, Jira і постимо в GitHub новий реліз та виконуємо допоміжні пост-продакшн задачі.

Які зміни ми запровадили

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

Тоді ми зрозуміли, що якщо у нас CD, то має бути і Continuous testing. Що таке Continuous testing і чим воно відрізнялося від стандартного тестування? Це тестування на всіх етапах розробки, акцент на автоматизацію і тестування розробниками. Звичайно, що для нас як мануальних тестувальників це виглядало дуже ризиковано, і на початках не зрозуміло, як воно має працювати. Після кількох брейнштормів ми визначили собі такі основні зміни, які треба зробити і запровадити в тест-процесі:

• Якість стає основною філософією для інженерної команди. Тестування стосується тепер не лише QA, а й девопс-команди і розробників — участь у ньому беруть всі.
• Ми відходимо від тестування user story під час спринта. Більша увага тепер приділялася тестуванню вимог до їх потрапляння в спринт, exploratory testing і моніторингу.
• Тестування стає для розробників частиною їхньої роботи. Хоча вони і до того писали unit та integration тести, але тепер цей процес розширюється на automation та manual тестування (в межах здорового глузду, звісно).
• Фокус мануального тестування рухається більше в сторону end-to-end i integration testing, автоматизоване тестування стає обов’язковим для всіх QA. Тепер кожен тестувальник підтримує автоматизовані тести на своєму проєкті.

Звичайно, процес для нас був новий. Багато чого потрібно було змінювати, тому склали план дій і кроків, щоб впевнитися в якості роботи.

Pilot run with single team

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

Ми вибрали проєкт, на якому було найбільше покриття автоматичними тестами, і де розробники давно вже проводили тестування. Узгодили процес: тестувальник почав більше працювати із продакт-менеджером і долучився до написання use cases, в яких описував всі можливі варіанти поведінки системи чи користувачів; складали тест-нотатки (це свого роду checklists) для розробників, і user stories тестували самі розробники з мінімальною допомогою тестувальників.

Local testing with developers

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

Sessions with Product Managers

Через те, що ми рухаємося до проактивного процесу, нам було дуже важливо, щоб QA володіли знаннями на проєкті. Ми проводили сесії, під час яких QA з PdM’s розглядають вимоги до функціоналу, який буде робитися в найближчому майбутньому. Це дає нам змогу економити час на плануванні, QA вже знають різні варіанти, які важливо буде протестувати, автоматизувати і описати в тест-нотатках.

Automation sessions

У нашій QA-команді було четверо Manual QA і один AQA, і як таких знань автоматизованого тестування ні в кого не було, а в continuous testing процесі значний акцент якраз на автоматизацію. Тому ми вирішили зробити курси, на яких AQA нас навчав. Це дало свої результати, тепер кожен QA покриває автоматизацію на своєму проєкті.

Developer testing

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

Testing notes

Ми використовуємо нотатки для тестування в задачах, де описуємо різні кейси, які потрібно перевірити. Це допомагає у дев-тестуванні. Наприклад, є опис задачі і в кінці тестувальники створюють секцію «Testing notes», де описують, що потрібно перевірити, а також на що варто звертати увагу.

Datadog monitoring (non-functional testing)

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

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

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