Рахуємо ROI автоматизації UI-тестування

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

Привіт друзі! Я — Льоша, автор блогу про тестування QAMania і один з ведучих подкасту «Питання Якості» на DOU. В одному з останніх випусків подкасту ми обговорювали очевидні проблеми автоматизації тестування. Один з болючих для мене аргументів — ROI, оскільки, з мого досвіду, автоматизація майже ніколи не окупає витрат на себе. Звісно, я одразу отримав купу коментів, що рахувати не вмію, і є інші причини робити автоматизацію, окрім грошей. Найчастіше прикладом таких інших причин виступає пришвидшення надання зворотного зв’язку про якість продукту команді розробки і, як наслідок, — покращення в сторону зменшення показника «Time To Market». За таке, ймовірно можна і переплатити 💰 Втім, в цій статті пройдімо разом з вами весь шлях планування автоматизації тестування і порахуймо класичний ROI сферичного проєкту в вакуумі, тобто такий, який порівнюватиме час, витрачений на автоматизацію, з часом, який завдяки автоматизації вдалось зекономити в ручному тестуванні. А в коментарях обговоримо всі параметри та помилки. Поїхали! 🚀

За критику і редактуру окрема подяка співавтору QA Mania — Михайлу Чубу 💪

База

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

• Тут і надалі під автоматизацією тестування ми будемо мати на увазі саме UI-автоматизацію, що може використовувати Playwright, Selenium, TestComplete, Ranorex, Appium, <your framework name>. Не виключаючи додаткові API тести, але переважна більшість — саме тести через інтерфейс користувача.
• Автоматизацію тестування нема сенсу робити для короткотривалих проєктів, життєвий цикл розробки яких менше року.
• Автоматизацію тестування нема сенсу проводити, якщо продукт в активній розробці і постійно змінюється.
• Автоматизацію тестування є сенс впроваджувати, якщо є налагоджені процеси розробки і тестування, є написані регресійні тест-кейси, що виконуються постійно і регулярно (рутина).
• Автоматизацію тестування є сенс впроваджувати, коли чітко зрозуміла мета (шоб шо?). Це потрібно для того, щоб оцінити користь нашої автоматизації. Якщо у нас нема цілі, є лише шлях, то ми, звісно, самураї, але автоматизацію краще не починати.

Сферичний проєкт у вакуумі

Щоб зробити план проєкту з тестування, придумаємо собі деякі його параметри, від яких будемо відштовхуватись:

• продукт — типовий інтернет-магазин з продажу слонів 🐘;
• продукт — вебзастосунок, створений за допомогою популярних фреймворків;
• проєкт існує вже рік, був успішний реліз, фікси і нові фічі релізяться раз на 2 тижні. Старий функціонал практично не змінюється, лише додається новий;
• розробку заплановано мінімум на 1 рік вперед;
• команда: 1 тестер, 3 розробники, девопс, менеджер і ви — молодий, амбітний інтелігентний амбал симпатичний тест-лід 😍;
• за рік роботи ви з тестером написали 500 тест-кейсів, які мусите регулярно проганяти перед кожним релізом + під час процесу розробки. Ви дуже втомились від цього, тому логічно думаєте, як би перекласти цю роботу на потужні плечі машин;
• час ручного прогону регресійних тестів ~ 40 man*hours, тобто тиждень на одного тест-інженера чи 2,5 дні на двох (вас і тестера);
• для нової функціональності ви регулярно додаєте нові регресійні тести + витрачаєте час на ретест, тестову звітність, мітинги і т.д.;
• у вас є всього 2 середовища — ТЕСТ, де ви проводите тестування, і ПРОД;
• вам пощастило, і тестове середовище під вашим абсолютним контролем: можна створювати і видаляти будь-які дані, налаштовувати пайплайни білд сервера, писати моки для інтеграційних тестів.

Загальне планування

Щоб планувати, давайте спочатку визначимо цілі:

1. Зменшити час ручного регресійного тестування мінімум в 2 рази.
2. Забезпечити команді регулярний (оптимально — щоденний) звіт з поточної якості продукту.
3. Гарантувати стабільну якість існуючого функціоналу — користувачі не мають повідомляти баги рівня major та вище в тій частині функціональності, що покрита автотестами.

Щоб подальше планування мало сенс, потрібно визначити, чи можна взагалі автоматизувати тести, який рівень testability має система? (нещодавно в тест дайджесті була гарна стаття на цю тему)

У нас — вебзастосунок. Проаналізувавши HTML-сторінок, переконуємось, що сторінки не містять якоїсь дичини типу iframe, вбудований в iframe, вбудований в інший iframe з динамічно змінними id (що можуть бути характерні для nocode-конструкторів сайтів і значно погіршити можливості автоматизації). Для гарантії, створюємо і проганяємо кілька тестів в якості PoC.

Тепер варто визначити, хто буде робити автоматизацію. Є 2 варіанти: піти на курси і навчитись самим чи найняти готового спеціаліста. Другий варіант здається швидшим і подобається більше, тому ми наймаємо 1 senior test automation. Його стек — мова Python, фреймворк — Playwright (така в мене уява ¯\_(ツ)_/¯ ). Далі, коли я пишу «ми», спираюсь на експертну думку найнятого спеціаліста.

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

• Гарно описані, з кроками, чіткими даними, очікуваними результатами, передумовами. Є таке емпіричне правило: «сценарій ручного тест кейсу != автоматичному», тому існує ймовірність, що сценарії наших тест-кейсів доведеться доповнювати до стану «ready for automation».
• Важливі. В першу чергу варто автоматизувати найпріоритетніші тести, що перевіряють критичний функціонал.
• Короткі. Менше кроків — менше шанс, що щось впаде.
• Такі, що можна повторювати багато разів. Якщо ви тестуєте реєстрацію, зважайте, що кількість доступних даних користувачів може бути лімітована.
• Тести, що не залежать від стану. Тут треба пояснити: якщо ви автоматизуєте покупку в магазині, у вас має бути користувач, товар, тестова кредитна картка з достатньою кількістю тестових грошей. Багато сутностей зі своїми станами, що змінюються з кожним тестом і потребують конфігурації. Тест, що перевіряє наявність пунтку меню — від стану не залежить, тому автоматизувати його просто.
• Data-driven тести. Якщо треба перевірити однакову поведінку на великому обсязі даних — це гарний кандидат на автоматизацію.
• Не залежать від зовнішніх факторів. Якщо продукт під час виконання тесту робить запит в сторонню систему, і вона може бути недоступна, тест впаде з незалежних від вас причин. В мене були тести, де треба було ввести номер телефону, а потім — код SMS, що прийшов. Такі штуки спочатку мокаються, а потім автоматизуються.
• Не залежать від часу. Якщо підтвердження якоїсь дії відбувається асинхронно (наприклад, запуском джоби), такі тести краще облишити.

Після аналізу всіх існуючих тестів в regression test suite, ми виділили 300 таких, що точно можна автоматизувати. Тобто, теоретично, ми можемо досягти цілі № 1 — скоротити час регресійного тестування в 2 рази! А точніше, якщо один регресійний тест вимагає 40 годин, то автотести зекономлять цілих 24 години.

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

Середовище тестування не працює чи працює частково

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

Зміна вимог до застусунку

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

Зміна даних застосунку, критичних для тестування (наприклад: нема слонів — нема покупок)

• Ідеальний сценарій — окреме середовище.
• Домовленість з командою, що визначені дані ні розробники, ні тестери не чіпають, бо вони необхідні автотестам.
• Precondition і postcondition скрипти, що створюють всі необхідні передумови для успішного тестування.

Тепер порахуймо грубо витрати часу на автоматизацію, і ROI також будемо рахувати в годинах, бо час = гроші.