Що таке QAOps і чому це важливо для вашого веб-додатка

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

QAOps належить до сфери підтримки програмного забезпечення, підхід до якого — з позиції DevOps. Публікуємо переклад матеріалу з Dev.to.

Як ви вважаєте, чи дійсно QAOps — «революційний» підхід до забезпечення якості? Чи лише «модне» слово?

Вступ до QAOps Framework

Простіше кажучи, QAOps спрямований на покращення поставки програмного забезпечення, роблячи його швидшим і стабільним без шкоди для якості вашого веб-сайту чи веб-додатка. Структура QAOps інтегрує процеси QA в роботу програмного забезпечення, щоб зробити безперебійну та інтегровану операційну модель програмного забезпечення. Платформа QAOps інтегрує процеси QA, автоматизацію та інформаційну панель звітів QA з процесом життєвого циклу розробки програмного забезпечення (SDLC). Коротше кажучи, QAOps бере основні ідеї з безперервного тестування в DevOps, таких як CI/CD, і об’єднання окремих команд для роботи над пайплайном, і застосовує те ж саме до процесу QA.

Визначення QAOps

Хоча офіційного визначення QAOps немає, ми можемо визначити методику на основі цих двох принципів.

Основна ідея впровадження фреймворка QAOps полягає в тому, щоб інтегрувати безперервне тестування в DevOps з пайплайном безперервної інтеграції (CI) та безперервного розгортання (CD), а не виконувати тестування програмного забезпечення через невизначені проміжки часу.

Фреймворк QAOps покращує співпрацю між інженерами QA та розробниками. Тому інженери QA повинні тісно співпрацювати з розробниками програмного забезпечення і всіма, хто бере участь у CI/CD.

Основні методи роботи з QAOps Frameworks

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

1. Автоматизоване тестування

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

Найочевиднішими типами тестування для автоматизації будуть регресійні тест-кейси. Їх можна ефективно використовувати для створення автоматизованих тест-кейсів. Аналогічно, часто використовувані функції продукту також мають бути автоматизовані. Чому? Оскільки функціональність і функції вашого продукту збільшуються, ви не хочете, щоб ваші найпопулярніші функції вийшли з ладу.

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

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

Саме тут йому на допомогу може прийти автоматизоване крос-браузерне тестування. Завдяки платформам з відкритим вихідним кодом, таким як Selenium, автоматизоване тестування може стати рятівним кругом для Андрія, щоб завершити цикли тестування за розкладом. Однак йому все одно потрібно буде з’ясувати, які тест-кейси автоматизувати, оскільки він не може автоматизувати все.

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

2. Паралельне тестування

Як частина QAOps, тестування повинно проходити швидко (паралельно з папйлайном поставки). Уповільнення тестування безпосередньо вплине на цей процес. Виконання автоматизованих тестів прискорить процес тестування, але не тоді, коли вони виконуються послідовно. Щоб подолати цю проблему, інженерам-тестувальникам важливо виконувати кілька тестів одночасно (разом), а не виконувати їх один за одним.

Давайте продовжимо історію Андрія, яку ми розглянули на прикладі автоматизованого крос-браузерного тестування.

Усвідомлюючи переваги автоматизованого тестування перед ручним крос-браузерним тестуванням, він придумав кілька сценаріїв автоматизованого тестування, щоб охопити різні модулі свого веб-додатка. Однак виникла інша проблема, до якої він був не готовий! Андрій використовував Selenium WebDriver для автоматизації своїх тестових сценаріїв на сумісність браузера. Selenium WebDriver буде виконувати лише один тест за раз, а інші ставити в чергу. Як наслідок, Ендрю помітив, що цикли тестування все ще будуть затримуватись через послідовне виконання тестових скриптів.

Тепер він реалізував свій набір тестів через Selenium Grid, щоб використовувати паралельне тестування з Selenium. Використовуючи можливості Selenium Grid, Андрій зміг запустити кілька тест-кейсів одночасно. Це зменшило загальне виконання тесту.

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

3. Перевірка масштабованості

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

Тестування масштабованості також допомагає визначити продуктивність програми в різних умовах, змінюючи тестові навантаження. Результати тесту показують реакцію програми на диференціальне навантаження. Тестування повинне бути масштабоване за допомогою конвеєра CI/CD. Іноді конвеєр CI/CD масштабується вгору і вниз залежно від вимог проекту. У цей час тестування також має синхронізуватися з конвеєром CI/CD. Тестування масштабованості допомагає інженерам QA виявити проблеми, пов’язані з продуктивністю веб-додатків.

Як стандартна практика QAOps, команди QA повинні мати масштабовану інфраструктуру для проведення тестування та збільшення швидкості тестування, коли це необхідно.

Давайте розглянемо, що зробив Андрій, щоб подолати проблеми з масштабованістю.

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

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

Йому довелося розглянути можливість розширення Selenium Grid для тестування на більш застарілих і останніх версіях браузера, операційних системах як для Windows, так і для macOS, а також для Android і iOS. Виявляється, якщо він продовжить додавати ці пристрої до своєї внутрішньої інфраструктури Selenium Grid, у нього може з’явитися величезний рахунок, що доведеться покласти на стіл свого менеджера. Працюючи в невеликій компанії, він не може скористатися хмарними постачальниками інфраструктури, такими як RackSpace або AWS. Отже, що він може зробити?

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

Інтеграція Dev & Ops з QA

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

Повернемося до Андрія, нашого спеціаліста з автоматизації тестування, який вирішив застосувати QAOps і поділитися своєю точкою зору зі менеджером та стейкхолдерами. Він зрозумів, що чим швидше будуть написані тест-кейси, тим швидше буде вихід на ринок. Він запропонував запровадити «Shift-Left» Testing, щоб включити QAOps у компанії. Відтоді кількість аномалій, виявлених після міграції пайплайнів CI/CD, помітно зменшилася.

Життєвий цикл QAOps Framework

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

Процес QAOps містить три унікальні кроки — тригер, виконання та звіт.

1. Тригер

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

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

2. Виконання

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

3. Звітність

Після запуску та виконання тестів починається процес звітності. Модуль звітності демонструє результати тестів. Важливо правильно спроектувати модуль звітності, щоб процес QAOps був ефективним. Ідеальний дизайн модуля звітності повинен надавати швидку підсумкову інформацію (у моментальному знімку), а також надавати детальну інформацію. Це буде корисно для тих, хто переглядає звіти. Крім того, модуль звітності також повинен мати можливість зберігати історію попередньо проведених тестів, щоб можна було порівняти результати. Звіти мають бути легко доступними.

Де можна використовувати QAOps

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

З огляду на це, давайте розглянемо окремі типи тестування, окрім крос-браузерного тестування, де фреймворк QAOps може використовуватись.

Функціональне дослідницьке тестування

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

Ось кілька переваг функціонального дослідницького тестування:

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

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

Регресійне тестування

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

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

Тестування геолокації

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

За допомогою QAOps ваша команда QA може співпрацювати з командою Ops, щоб краще ознайомитися з цими стандартами Інтернету. Таким чином, вони зможуть скерувати тестовий цикл у правильному напрямку з самого початку, а не блукати в темряві й потім самостійно з’ясовувати це.

Кращі практики

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

• Процес безперервного тестування має бути інтегрований в життєвий цикл розробки програмного забезпечення. Це допомагає компаніям зменшити ризики та забезпечити швидший випуск продукції та час виходу на ринок.
• Усі команди в організації (розробники, Ops, QA) мають бути частиною всього циклу релізу. Вони повинні забезпечити співпрацю та ефективну комунікацію протягом усього періоду релізу.
• CI/CD слід проводити на регулярній основі, бажано щодня. Робота кожного повинна бути об’єднана в пайплайн релізу. Це допомагає виявити дефекти на ранніх стадіях і усунути їх, поки не стало занадто пізно.
• Команди з якості мають бути частиною планування релізу, процесу збору вимог. Буде ефективніше, якщо команди з якості працюватимуть разом із командами розробників, щоб надавати життєво важливий внесок під час розробки.
• Показники кожної команди повинні бути визначені та вимірювані через певні інтервали під час процесу випуску.
• Інженери з тестування повинні використовувати засоби автоматизації та сценарії, щоб автоматизувати якомога більшу частину тестування. Глибоке регресійне тестування має проводитися на існуючих функціях, коли розробляється нова функціональність, щоб переконатися, що наявні функції не порушуються.
• Розробники повинні почати думати як тестувальники, а тестувальники повинні робити навпаки, (тобто виправляти код). Це змушує кожного в організації брати відповідальність за загальну якість продукту.

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