Codeless-підхід для автоматизації тестування: як порахувати ROI

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

Привіт, мене звати Дмитро. Я вже 10 років працюю в компанії MindK, зараз обіймаю позицію Head of QA. Як і багато хто з вас, ми постійно шукаємо нові підходи, які могли б покращити процес розробки. У цій статті я розповім про один з таких експериментів.

Codeless, low-code або no-code підходи обіцяють значно спростити автоматизацію тестування без необхідності знань програмування. Та попри весь гайп, існує дуже мало детальної інформації про реальні проєкти. Майже всю її можна поділити на дві умовні групи. Перша — це дифірамби від маркетологів, які працюють на codeless-платформи. Друга — це розбір обмежень або недоліків нового підходу від адептів традиційних цінностей автоматизації.

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

Загалом ми вже понад вісім років автоматизуємо тестування на багатьох проєктах. Спочатку був тех стек Java, потім перейшли на JavaScript, а згодом — на TypeScript у зв’язці з Playwright.

У цій статті не буде порівнянь функціональних аспектів традиційного і codeless-підходів, їх плюсів, мінусів, ризиків чи обмежень. Натомість зосередимось на більш важливому показнику — рентабельність інвестицій (ROI).

Крім того, поділюсь шаблоном Google Sheets, який допоможе самостійно оцінити ROI для ваших проєктів.

Навіщо автоматизація тестування

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

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

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

В підсумку переваги автотестів можна об’єднати в чотири групи:

• Економія коштів і ресурсів. Замість рутинного полювання за регресійними багами тестувальники можуть зайнятись більш важливими ​​та цікавими задачами.
• Швидкий зворотний зв’язок про стабільність системи. Автотести є частиною CI/CD процесу та можуть бути запущені в будь-який потрібний момент.
• Вища стабільність з меншою кількістю дефектів на проді. Це також зменшує вартість підтримки та робить приємно кінцевим користувачам.
• Ефективність і швидкість релізів. Автотести дають швидший зворотний зв’язок і більш часті цикли тестування, скорочуючи час виходу на ринок.

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

Що таке ROI і як його рахувати

Рентабельність інвестицій (ROI) є фундаментальною концепцією в бізнесі. Вона допомагає оцінити реальний прибуток від конкретної інвестиції, надаючи чітке уявлення про її загальну цінність.

Формула ROI доволі проста:

ROI = (чистий прибуток / загальна вартість інвестицій) x 100%

Чистий прибуток — це загальна вигода, отримана від продукту, мінус загальна вартість інвестицій:

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

Загальна вартість інвестицій — це загальна вартість автоматизації тестування на проєкті:

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

На виході формула дає відсоток, який відображає ефективність і прибутковість інвестицій. Додатне значення свідчить про успіх, від’ємне — про збитковість.

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

Assumptions

Точність розрахунків залежить від певної кількості важливих припущень. Вони впливають як на сам аналіз, так і на його кінцеві результати. Можна виділити такі основні їх групи:

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

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

Наші припущення для розрахунків

• Абсолютно новий проєкт у домені Healthcare. Розрахунок ROI проводиться за перший рік розробки.
• Планується автоматизація UI end-to-end (E2E) сценаріїв із використанням API для менеджменту тестових даних.
• Фултайм залученість Senior TA інженера для традиційного (надалі «TA», бо «Test Automation») та middle QA інженера для codeless (надалі «NC TA», бо «no-code») підходу впродовж усього періоду розробки.
• QA/TA інженери мають достатній досвід роботи з обраними технологіями.
• Для роботи з тестовою документацією для потреб автоматизації не потрібно залучати інших тестувальників.
• Планується автоматизувати одну ітерацію ручного регресійного тестування та дві ітерації smoke-тестування на місяць.
• У Healthcare-домені автотести мають не лише замінити ручну роботу, але й покращити стабільність і надійність системи.
• Обсяг регресійного тестування буде розширюватися щомісяця, оскільки ми будемо розробляти нові функції в нашому продукті.
• Перший реліз планується через шість місяців. Після цього support-команда почне обробляти запити від кінцевих користувачів та фіксити виявлені дефекти.
• TypeScript і Playwright тех стек для традиційного TA і використання однієї з SaaS-платформ для NC TA.
• Одноразова активність із налаштування проєкту для автоматизації не включена в наші розрахунки. Але маємо на увазі, що налаштування фреймворку з репортингом та CI/CD пайплайнами може зайняти до 40 годин для TA і лише кілька годин для NC TA.
• Витрати на рефакторинг і підтримку тестів вважаємо однаковими для обох підходів. Зважаючи на велику різницю в часі на розробку тестів, ці значення також можуть відрізнятися в довгостроковій перспективі. З іншого боку ми очікуємо, що в рамках NC TA підходу буде розроблено набагато більше тестів. А це збільшить час на підтримку більшого скоупу. Але у будь-якому разі поки маємо недостатньо даних для порівняння.

Розрахунок і порівняння ROI

Крок 1: порівнюємо час на розробку тестів

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

Це дає змогу порівняти effort в обох підходах.

У нашому випадку розробка NC TA тестів потребує в 3.18 рази менше часу в порівнянні з традиційним TA.

Крок 2: рахуємо витрати

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

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

Ви, звісно, можете змінити ці всі цифри відповідно до ваших процесів.

Маючи цю інформацію, ми можемо оцінити реальну вартість години розробки нового тесту.

Легенда:

• QA Engineer Salary: середня зарплата Senior TA та Middle General QA з відкритих джерел.
• Rate: погодинна ставка на основі зарплати.
• Tools and Licences Price: середня місячна ціна необхідних ліцензій і NC TA продукту.
• Infrastructure Costs: середня ціна використання клауду та пайплайнів, необхідних для тестування.
• Training Costs: середні витрати на навчання співробітників використанню програмного забезпечення. Додатково можемо взяти час, витрачений іншими людьми на потреби нашого процесу. Наприклад, інший TA інженер дивиться наш пул реквест.
• Total test development hrs: середня кількість годин на місяць, витрачених на розробку нових тестів за попередніми розрахунками.
• Total test development hrs with k: кількість годин, помножена на коефіцієнт із попередніх розрахунків (3.18).

Як бачимо, одна година розробки нових тестів є більш ніж у 4 рази дорожчою в традиційному TA підході в порівнянні з NC TA.

Крок 3: рахуємо ROI

Нарешті у нас є всі дані, необхідні для підрахунку ROI та порівняння двох підходів.

Легенда:

• Development Costs: зарплата інженерів, вартість інструментів і ліцензій.
• Infrastructure Costs: середня ціна клауду і пайплайнів, необхідних для тестування.
• Training Costs: середні витрати для навчання працівників використанню ПЗ.
• Cost Savings (QA): економія коштів завдяки заміні ручного регресійного тестування. Це приблизна кількість годин, помножена на погодинну ставку QA-інженера.
• Cost Savings (Maintenance): економія коштів, витрачених на виправлення дефектів та підтримку після релізу.
• Increased Revenue: додатковий дохід від продажів завдяки впровадженню нового підходу до тестування.
• Intangible Benefits: задоволення клієнтів, ефективність рішень щодо розвитку продукту, конкурентна перевага тощо.

Як показують результати, річне ROI класичного TA гірше, ніж у NC TA (тут ми обмежимося лише цією якісною оцінкою, залишивши вам можливість надати більш розгорнуту або кількісну оцінку самостійно).

Ми навмисне залишили категорії «Increased Revenue» та «Intangible Benefits» порожніми. Вони повністю залежать від особливостей вашого проєкту. Продакт-менеджери можуть виміряти або спрогнозувати їх на основі різних метрик і показників. Але ці дві змінні можуть суттєво вплинути на кінцеву рентабельність, зробивши її позитивною.

Висновки

Розрахунки ROI дозволяють оцінити потенціал автотестів для кожного конкретного проєкту. Фреймворк, розглянутий у цій статті, може стати посібником, який допоможе приймати обґрунтовані рішення. Незалежно від того, працюєте ви з традиційним TA, досліджуєте потенціал нових інструментів чи процесів.

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

Хочете зробити розрахунки для свого проєкту? Скопіюйте шаблон Google Sheets та налаштуйте його відповідно до своїх потреб.