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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | 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 також будемо рахувати в годинах, бо час = гроші.



Активність


час, год


Коментар


Створення і налаштування проєкту


40


Я завжди закладаю мінімум тиждень на створення структури проєкту, налаштувань, продумування патернів тестування


Автоматизація 300 тестів (1 тест = 1 година)


300


1 тест — 1 година. Це мінімум. Більш реалістично 1,5-2. Але ми будемо дуууже оптимістичними


Дебаг і багфікс


30


Додаткові активності зі стабілізації тестів. Я закладаю до 10% від часу їх написання


Аналіз тестових звітів


20


Тести будуть гарантовано падати. Особливо спочатку. І треба закласти час на аналіз логів і стек трейсів. Знову — я тут дуже оптимістичний


Налаштування CI


10


Залежить від СІ, але якщо у вас є повний контроль і розуміння, що робити — дня роботи вистачить з головою


Ризики — 10%


40


Незаплановані роботи. Краще б 30%, але для нашого магазину слонів ми великих ризиків не вбачаємо


Загальні інвестиції в автоматизацію, год


400

Нарешті рахуємо ROI в статті про ROI 😜

Але спочатку зробимо кілька уточнень і припущень:

  • Нехай робочий місяць складається з 20 днів, 160 годин.
  • Будемо вважати, що автомейшн-інженер працюватиме всі 160 годин на місяць, бо він дуже любить свою роботу❤️ і не чув про фокус-фактор.
  • Також ми не враховуємо час на постійну підтримку тестів в робочому стані і дописування нових тестів, бо, по-перше, вийде ще дорожче, по-друге, наша мета — оцінити окупність певного об’єму робіт, а якщо він постійно ростиме, це зробити буде складніше.

Вносимо наші дані в таблицю. Оскільки релізи 2 рази на місяць, то повна регресія займає 80 людино-годин. На повну автоматизацію 300 тест-кейсів піде 2,5 місяці, після чого тести почнуть приносити користь, а ми почнемо віднімати час, витрачений на автоматизацію.

Як неважко здогадатись, автоматизація початкового об’єму робіт вийде в 0, тобто окупить витрати і почне приносити чистий прибуток лише на 11-й ⚠️ місяць. Майже рік! Саме це я і маю на увазі, коли стверджую, що автоматизація не окупиться. Але це не кінець.



Місяць


1


2


3


4


5


6


7


8


9


10


11


12


Максимально можливий час роботи 1 інженера


160


160


160


160


160


160


160


160


160


160


160


160


Час на ручну регресію (2 рази на місяць)


80


80


56


32


32


32


32


32


32


32


32


32


Витрати часу на автоматизацію


160


160


80


0


0


0


0


0


0


0


0


0


Економія часу на регресійне тестування


0


0


24


48


48


48


48


48


48


48


48


48


ROI


-400


-400


-376


-328


-280


-232


-184


-136


-88


-40


8


56

За 11 місяців ми виконали лише одну ціль з трьох поставлених. За умови, що автотести виконуватимуться лише раз, перед релізом, заміняючи ручне тестування.

Для виконання другої цілі ми налаштуємо щонічний запуск автотестів, щоб точно відслідковувати зміну в якості практично з кожним білдом. Те, що мало руками виконуватись 24 години, виконується за 2-3 години щоночі. Досягти такого ручним тестуванням — неможливо, а значить, це вже вагомий аргумент ЗА автоматизацію.

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

Ціль 3 неможливо визначити для сферичного проєкту у вакуумі, але тест-менеджер має відслідковувати defect leakage — якщо автоматизація пропускає дефекти, то користь від неї одразу прямує до 0.

Висновки

Власне, все досить очевидно. Автоматизація — це не чарівна таблетка, що вирішує всі проблеми з регресійним тестуванням і фінансово може принести користь лише у великих і довготривалих проєктах. (Якщо ви продаватимете автоматизацію замовнику, спираючись лише на фінансові аргументи, а саме на економію коштів — то може бути важко переконати 🥴) Автоматизація має багато як очевидних ризиків (деякі я перелічив вище), так і не очевидних. Майкл Болтон зневажливо називає це automation checking і GEMPOB (GEtting Machines to Press their Own Buttons), бо тестування — це завжди більша робота, ніж банальна перевірка, і людина завжди зробить її краще за скрипт.

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

👍ПодобаєтьсяСподобалось18
До обраногоВ обраному8
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

Коментар порушує правила спільноти і видалений модераторами.

«Ну штош». Чому тести починають запускатися тільки піля того як усі тести написані? Адже якщо ми маємо 40 годин на сетап на 1 годину на написання тесту то до кінці 1 місяця ми вже маємо ~ 100 тестів і це чомусь не враховується в ROI. Не зрозуміло чому наші тести починають запускатись кожен день лише після того як вже усі тести написані? Чому не враховуємо що тести можуть запускатися на кожен комміт, наприклад, разів 5 на день?( в моєму випадку це разів 20-30 на день). Адже усі знають що чим раніше знайшли дефект тим він дешевше. Чомусь не враховується що розробка тестів може йти паралельно з розробкою застосунку (наприклад АПІ тести)? І ще багато-багато чого. Я так чекав цю статтю а вона не виправдала моїх очікувань :(

до кінці 1 місяця ми вже маємо ~ 100 тестів і це чомусь не враховується в ROI

можемо врахувати, але їх небагато і виграшем в часі можна знехтувати. Тому я почав рахувати прибуток з 3-го місяця

Чому не враховуємо що тести можуть запускатися на кожен комміт, наприклад, разів 5 на день?( в моєму випадку це разів 20-30 на день)

По-перше, враховуємо, ось пряма цитата

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

По-друге, я не чув success stories, коли всі регресійні UI-тести виконувались би на кожен коміт

Адже усі знають що чим раніше знайшли дефект тим він дешевше

а запобігти багам ще дешевше, го краще вимоги аналізувати

Чомусь не враховується що розробка тестів може йти паралельно з розробкою застосунку (наприклад АПІ тести)

бо для цього конкретного випадку ми рахуємо ROI саме UI автоматизації, про що я теж явно написав

Тут і надалі під автоматизацією тестування ми будемо мати на увазі саме UI-автоматизацію
Я так чекав цю статтю а вона не виправдала моїх очікувань

«Ну штош» ¯\_(ツ)_/¯

можемо врахувати, але їх небагато і виграшем в часі можна знехтувати. Тому я почав рахувати прибуток з 3-го місяця

Як це не багато? В перший місяц ми пишемо 100 тестів ( а це 1/3 від загального), в другий місяць ми пишемо ще 140, адже нам не потрібен час на сетап ( а це вже більше ніж 2/3 від загальної кількості).

По-перше, враховуємо, ось пряма цитата

Цитату бачу а от в розрахунках я цього не бачу.

По-друге, я не чув success stories, коли всі регресійні UI-тести виконувались би на кожен коміт

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

а запобігти багам ще дешевше, го краще вимоги аналізувати

Мабуть це робили мануальні тестувальники за той рік шо вони писали 500 тестів?

бо для цього конкретного випадку ми рахуємо ROI саме UI автоматизації, про що я теж явно написав

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

В перший місяц ми пишемо 100 тестів ( а це 1/3 від загального)

100 тестів — 20% від загальної кількості мануальних тестів, тобто економія у 8 годин у 1й місяць
+140 у другий — ще 16. Якщо маєте бажання, додайте в таблицю. На фінальний результат це радикально не вплине

Цитату бачу а от в розрахунках я цього не бачу.

🤦‍♂️то перечитайте статтю ще раз, що саме я рахую. там було щось про цілі автоматизації... я у вас вірю

мабуть у Вас мало знайомих

правда 🥲 зробив опитування у себе в ТГ, аж цікаво

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

unit тести — це категорія must have, в той час як UI-автоматизація — додаткова плюшка. Саме тому і є запит на розрахунок ROI, щоб зрозуміти, чи є сенс робити, чи краще мануально ганяти

100 тестів — 20% від загальної кількості мануальних тестів, тобто економія у 8 годин у 1й місяць
+140 у другий — ще 16. Якщо маєте бажання, додайте в таблицю. На фінальний результат це радикально не вплине
На повну автоматизацію 300 тест-кейсів піде 2,5 місяці, після чого тести почнуть приносити користь, а ми почнемо віднімати час, витрачений на автоматизацію.

20% від загальної та ~30% від тих що ми плануємо автоматизувати.

🤦‍♂️то перечитайте статтю ще раз, що саме я рахую. там було щось про цілі автоматизації... я у вас вірю

Все ще не бачу розрахунків.

unit тести — це категорія must have, в той час як UI-автоматизація — додаткова плюшка. Саме тому і є запит на розрахунок ROI, щоб зрозуміти, чи є сенс робити, чи краще мануально ганяти

Тож як це мастхев? А порахувати ROI? Може нема сенсу писати юніт тести мануальщики все одно знайдуть проблеми.

Підсумуємо. Галєра намагається зекономити звільняючи Manual QA, набирає SDET, виходить дорожче, тести падають, часу витрачається не менше, якість продукту в кращому разі = equals

Дякую Олексій, за підняття цієї теми. І звичайно ком’юніті, яке так бурхливо на це реагує, бо є дійсно що обговорити. І це схоже на те, як ми з Романом робили естімейти по тестуванню діалогового віконця в Телеграмі :D

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

Мені здається, що не розглянуті деякі речі щодо того, які бенефіти буде мати компанія від автоматизації.
Окрім просто скоротити регресію (так собі мета насправді). Ми можемо додатково отримати покращення ТТМ (time to market), скоротити витрати на багфікс (бо ми ж то знаємо скільки буде коштувати виправлення багу на більш піздніх етапах). Тобто загально я б тут все таки дивився в сторону бізнесових бінефітів напевно.

А далі питання, чи будуть рахувати це в продуктових компаніях? Зазвичай не будуть рахувати, бо в очевидь, якщо продукт не має кінцевої дати життя, то автоматизація буде мати сенс.
І тут скоріше ми можемо зіштовхнутися з іншими обмеженнями:
1. кваліфікація команди.
2. моливість зміщувати фокус.
3. інфраструктурні, архітектурні проблеми.
4. і тд.

Згоден, розрахунок ROI не може бути універсальним, але я б його і в продукті рахував, просто щоб розуміти, яку користь ми можемо принести.
Саме тому я написав аж 3 потенційні цілі автоматизації, і окрім як зменшення часу на регресію, це регулярна тестова звітність, що, в теорії, має покращити ТТМ за рахунок раннього виявлення дефектів.
І чомусь всі коментатори, що пишуть про золоті хвилини простою проду нічого не кажуть про 3 мету — непропускання багів. Якщо у вас є постійний defect leackage, то чи є сенс від тої автоматизації. Сама по собі її наявніть якість не покращує

так, я люблю бурхливі дискусії! Взяли в останній DOU подкаст занадто лайтові теми і тепер там мало коментів і переглядів ¯\_(ツ)_/¯
hold my beer, як то кажуть, нам є що накинути 😂

Мега радий, шо спільнота жива та має суперечки
З огляду на те скільки ще існує проблем поза межами тестування та автоматизації в SDLC, що РОІ автоматизації це така мєлоч :)

Так про SDLC то хай там скрам мастера одне одному мордяки бють)))

А взагалі я дуже здивований, що з усієї статті про ROI найбільше дискусій викликає оцінка налаштування тестового проєкта у вакуумі, що забирає лише 10% від загальної оцінки часу автоматизації, а не, власне, ROI 🤣

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

Витрати часу на автоматизацію

160

160

80

0

0

0

0

0

0

0

0

0

Сфіга отам 0, ти хоч один проект бачів шоб там написали тести і взагалі потім до них не дивились, а прицьому ти пишеш шо у тебе проект ще у фазі девелопменту.

бо статтю треба читати, повністю і послідовно, щоб не пропустити пояснення, чому так

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

Прочитав.
По-перше дякую за, IMO, першу статтю про ROI автоматизації українською.
По-друге. Дуже вузький погляд на автоматизацію. Бо автоматизація — це не тільки UI автотести. А весь набір інструментів, перевірок, що дозволяють швидко отримати фідбек чи не зламалося чи щось після мерджу.
По-третє. Якщо розглядати автоматизації тільки як замінник регресійних тестів перед релізом — то так, це робити тяжко, довго та болісно. Але якщо знову ж таки сприймати ці автотести як засіб швидкої оцінки ризиків білда для УСІЄЇ команди — то автотести дуже допомагають.
Авжеж автотести — це не замінник звичайному дослідницькому тестуванню. Це — ще один інструмент в арсеналі інженера.
P.S. сетап нового ТИПОВОГО проєкту — 40 годин — це дуже круто. Я можу повірити, якщо в цю оцінку включати усі розмови з командою та менеджментом про те, як будемо автоматизовувати і тд.

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

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

По-друге, саме тому я і виділив аж 3 цілі автоматизації, і можливість отримати швидкий фідбек — безцінно, але не єдина можлива мета

Якщо розглядати автоматизації тільки як замінник регресійних тестів перед релізом — то так, це робити тяжко, довго та болісно

Одна з цілей будь-якого тестування — надання об’єктивної інформації про якість. Якщо проводити регресійне тестування 1 раз перед релізом — в нас буде періодичний зріз, по якому ми можемо робити висновки. Автоматизація дає можливість зробити періодичність зрізу коротшою, навіть щоденною, але сама по собі не збільшує якість самого ПЗ

сетап нового ТИПОВОГО проєкту — 40 годин — це дуже круто

Такий мій досвід. Всі експерти в коментах пишуть, що це задофіга, але поки не відповідають, скільки ж має бути і що вони в цей час враховують ¯\_(ツ)_/¯

Дані за 15 рік якісь. Якщо ви працюєте з реально сіньором то перший UI тест за 2 дні має бути готовий. Ранити можна на AWS cloud погодинно, то ще день сетапу. (Дані з власного досвіду)

Додаткові штуки типу роботи в банку не враховую бо отримувати доступи місяць то однаково для всіх

перший UI тест за 2 дні має бути готовий

Наговнокодити окремий UI тест і за 2 години можна. Зробити проєкт для автотестів — складніше. Я в коментах нижче розписав, що вкладаю в ті 40 годин 👇

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

Дуже спірно, 50 доларів на місяць на машину знайти можна

ггг, пройшли ті часи, коли я замовляв окремий десктоп, ставив його поруч і ганяв на ньому тести.
Окрім очевидно дорогих кейсів типу K8 кластерів, які точно не 50 баксів коштують, ви врахуйте ще роботу людей (девопсів, адмінів), що мають вам його налаштувати, включити в пайплайни, підключити моніторинг, зробити міграцію даних

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

Якщо ваш

1 senior test automation

інсталить тестовий проект 40годин, то мабуть так, короткотривалі проекти не для вас)).

Якщо ручний регрес займає 3 дні двома працівниками — шанс провмикати більший ніж при автоматизації.

автоматизація окупить витрати і почне приносити чистий прибуток лише на 11-й ⚠️ місяць

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

1 senior test automation

, то для подібного проекту з релізом 1 в 2 тижні краще найняти ще 3 manual QC за ту ж ціну сумарно, і діло в шляпі.

Я в коментах нижче написав, що саме входить в 40 годин. Напишіть ви, скільки часу це займає у вас?

Якщо ручний регрес займає 3 дні двома працівниками — шанс провмикати більший ніж при автоматизації.

Чому? Автоматизація покриває ручні тести. Якщо ручні тести не знайдуть помилок, то як їх мають знайти автотести?

Це поки у вас downtime в проді певної функціональності не вимірюється в секундах($x сума в секунду — збитків)

Знову попереднє питання — якщо автотест пропустить баг і на проді трапиться даунтайм, то що? Це ж не чарівна пігулка, що рятує від багів?

Рахувати витрати-прибуток в людино-годинах дивно.

В автоматизації тестування можуть бути різні цілі. Я спеціально в статті вказав 3 різні. Для цілі № 1 — цілком ок

для подібного проекту з релізом 1 в 2 тижні краще найняти ще 3 manual QC за ту ж ціну сумарно, і діло в шляпі.

Про це ж і мова! Коли вам, як спецу з тестування, кажуть «а давай ми автомейшн зробимо», ти рахуєш ROI і кажеш — «а давайте краще 3 manual QC наймемо за ту ж ціну». І ця порада не на рандомних почуттях 🤌, а цілком математично обґрунтована 👍

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

1) Автоматизація не обов’язково спрямована саме на покриття ручних тестів.
2) Помилки, що були пропущені при ручному тестуванні, можуть бути пов’язані з людським фактором. Автотести нівелюють людський фактор
3) Програмне виконання тестів чудово працює на великих обсягах розрахунків, на які людям потрібно набагато більше часу
4) Той самий набір тестів автоматично можна пускати на кожну зборку хоч по декілька разів нв день. Повне ручне тестування з такою інтенсивністю вже може бути неможливим з-за браку часу, а також фактору втомлення людей, що призводить до припущення помилок

В старих книжках писали, що автоматизація тестування окупається після 6 релізних циклів.

Хтось міряв в 90х затрати часу на мануальне тестування та автоматизацію. Виявилось, що автоматизація в 5-6 разів повільніше робиться.

Привіт. цікавить цей пункт:

Створення і налаштування проєкту — 40 годин

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

npm init playwright@latest займає хвилину. Але якшо в аутсорсінгу, то 40 годин =)

а також там релізи 2 рази в місяць :))))))

Сергію, ну що ти, як Арестович?

npm init playwright@latest займає хвилину

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

Наговнокодити — дійсно думати не треба, фігак-фігак і в продакшн 🫡

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

Наче тільки ти один в країні робив сладні проекти

ні, в мене як раз все досить лайтово

Більше того, в 80% кейсів оці всі архітектурні вихухолі в тестах нафіг не потрібні

Невже ти жодних патернів не використовуєш?
Перефразую: напиши плз, які типові патерни ти юзаєш і які проблеми ти ними вирішуєш?

Ніяких, бо все вже написано і реалізовано в бібліотеках. Хіба шо PageObject, але він пишеться по мірі написання тестів, тому таке.

В мене нема готових темплейтів під кожну технологію. Є один універсальний шаблон проєкту, який я перевикористовую, але закладаю час на
✅ після аналізу застосунку, придумати і реалізувати стуктуру page objects
✅ продумати і реалізувати базові фікстури — для атомарних тестів, для сесій і т.д.
✅ налаштувати конфіги — виокремити ті, що можна задати з команд лайна, що можуть просто з фала читатись, а що — секюрне і має десь з БД читатись
✅ о, ми читаємо щось з БД — треба написати адаптер, це ж не хвилина часу
✅ а ще для деяких тестів треба REST інтерфейс заюзати — ще один адаптер, ще одна фікстура
✅ а ще, напевно, треба зробити проєкт гнучким, щоб обирати, які тести на яких платформах використовувати
✅ а ще треба інтегрувати репортінг, щоб не тільки пас/фейл зберігав, а ще скріни, логи і красиво все це міг команді показати
✅ а може ще й звіт висилати в Test Case Management, а готової реалізації нема (тут точно буде більше 40 годин)
✅ ну і на останок — написати гайд, як проєктом користуватись для запуску локально і в CI/CD

з мого досвіду — роботи на тиждень точно набігає. А можете написати, скільки часу у вас іде на сетап і що ви в нього включаєте?

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

Так а нашо? Якшо кожному замовнику можна продати котіків з 30% націнкою

Саме тому ми і рахуємо ROI, щоб показати чи варто взагалі «купляти котиків», а не бездумно пропонуємо автомейшн всім, аргументуючи «я проєкт за хвилину створю» 😂

ну звісно бо не в ваших інтересах оптимізація.

класно накидуєш, аж не можу відірватись 😁
Ну то покажи майстер клас — напиши свої естімейти по автоматизації чого завгодно.

Всіх так зачепила моя оцінка часу на сетап (10% від загального часу на автоматизацію), ніби я пост тільки про це написав 🤔

В нормальних командах ніхто не естімейтить такі речі. Я тобі можу навести приклад того як ми зекономили 16 man/hours за допомогою автоматизації, без втрати в якості і це дало змогу зробити процесс релізу автоматичним. Прицьому цей проект розробляється навіть зараз і він заробляє багато грошей, це теж момент який ти не врахував. Ціна помилки і час на її знаходження.

тобто, ви не проводите оцінку роботи, а просто робите речі, бо «такий шлях»?
І ще закидаєш, що оптимізація не в моїх інтересах?

А якщо провести перевірку, не виявиться, що хтось витратив 100 годин часу, щоб «оптимізувати» тести, і вони тепер виконуються не умовні 3 години, а 2 години, 55 хв?

ну ти ж вмієш рахувати. Вот я витратив на ці тести 80 годин, вони економлять нам 16 mh і бігають мінімум 1 раз на день: 365*16 = 5840
5840 — 80 = 5760. Ну хай там ще на їх підримку заберемо 3 години в тиждень, це ще 156 годин, по ітогу маємо 5604 години. Парапарапам, піу

я вмію рахувати і бачу маніпулції з цифрами. Твій розрахунок нагадує бородатий анекдот:
— «я сьогодні пішов пішки, а не поїхав на автобусі, і зекономив 50 коп.»
— «треба було не поїхати на таксі, і зекономити 10 грн.»

В чому абсурдність такого розрахунку?
1. Беремо 1 тест, що руками виконувати 1 хв і 5 сек і автоматизауємо за 1 годину (60 хв). Тепер він виконується автоматично за 5 сек
2. Економія на 1 прогоні = 1 хв 👍
3. тест бігає раз на день: 365*1 = 365 хв
4. 365 хв — 60 хв = 305 хв чистого профіту
5. А якщо ми засетапимо, щоб цей тест ранився 10 разів на день, та же й в 10 потоків паралельно (в різних браузерах, наприклад), то економія вийде 305 * 10 *10 = 30500 хв = 508 год!
Оце оптимізація і всього на 1 тесті, можна автоматизувати 2 і вибивати собі ЗП 8к.

Парапарапам, піу

Занадто різні проєкти, щоб шаблонізувати. Навіть з мого скромного досвіду, я робив UI автоматизацію:
✅ Windows desktop app на JS TestComplete
✅ Windows desktop app на C# VS UI
✅ Windows desktop app на C# Ranorex
✅ Web App на Java Selenium
✅ Web App на Python Selenium
✅ Web App на Python Playwright
і чув від колег ще більше кейсів з варіаціями фреймворків, мов і типів застосунків. Якщо шаблонізувати все і підтримувати в актуальному стані, то ми станемо не аутсорсно-аутстафною компанією, а виробником шаблонів 😄. В різних замовників різні побажання і технології

Кожен каже, що його проєкт унікальний. Але особисто я бачив за 12 років в індустрії тільки 1-2 дійсно унікальних продукти для яких просто немає достатньо інструментів та треба створювати їх «з нуля».
До того ж можна створювати N загальних шаблонів які потім легко трошки «доробити» та писати тести.
Плюс — можливо в мене мало досвіду, але більшість клієнтів хоче швидкого випуску фічей з мінімумом багів — а на яких технологіях написані тести (Selenium чи Playwright) — це задача якраз автоматизаторів «продати» те, що потрібно.

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

Одна справа стек, інша справа — темплейт солюшена для автоматизації на обраному стеку.
Плюс — я дуже сумніваюся, що якщо прийде кастомер на Rust чи Haskell — ви будете писати UI тести на тій же мові програмування.

враховуючи, що в індустрії вцілому все ще є велика доля проєктів на PHP чи Cobol, все залежить від наполегливості клієнта

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

Звичайно є одиниці людей, яких неможливо переконати.

Так ти ж сам обмежив скоуп до Web UI на початку статті. Для веба шаблон зробити на ізі.

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

я думаю, це слушна думка для аутсорс компаній мати фреймворки під стеки проектів, які вона бере. При хорошому knowledge-sharing в компанії можна швидко відпрацьовувати best-practice.
І це стосується не тільки тестування, та автоматизації, а ще і розробки. Бо якщо одразу ми думаємо про розробку+автоматизацію, можемо закладати певні патерни одразу.

Шоб так робить, треба шоб проект заводився з 0, в аутсорсі це прямо дуже рідкий кейс

Ну в статті ж наводився приклад автоматизації з нуля.
Плюс якщо автотестів небагато та вони нестабільні та брудно написані — в деяких окремих випадках можна переписати. (Далеко не завжди)

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

Тут просто розговор про аутсорс та розробка з нуля.
В аутсорсі важливий ноледж шерінг в середині, а для клієнта швидкість і якість (і дешевизна офк :D)
Якщо компанія має гарну культуру по шерінгу знань, то в заводити всі ці речі стане краще і швидше.

А відповідно до темплейту, інколи деякі бібліотеки приходиться докручувати. Ми трішки доробляли ліби для пайтона (точно request), щоб легше було дебажити, при помилках. І ще робили власні ліби.
Нажаль я не технічна людина, тому тут деталей на скажу :(

у нас в організації я зробив темплейт під стек технологій. тобто умовно є один великий фреймворк який підтримує наприклад стек джава і все около нього. і там вже є і логуваня, і репортінг, і адаптори під ui, під рест, під графкуель та під базу даних, ну і звісно все структуровано, з можилвостями запуска тестів під різними конфігами, та рідмі файл як цим користуватися. з прикладами використання кожного адаптора а також yml файлом як це все розгорнути на CI.
коли новий проєкт заходе — то людина просто видаляє зайві модулі і приклади використання, підналаштовує необхідні парамтери проєкта(урли і оце все) і все по суті. займає від 4 до 12 годин це все.

ну це те, про що я писав, ага :)

А нахіба оці сферичні заміри в сферичному вакуумі? Шоб шо?

З енною кількістю замірів і таких статтей можна потім простіше собі вибити +500

якби я міг вказати дані реального проєкта, так би і зробив ¯\_(ツ)_/¯
а заміри в сферичному вакуумі потрібні, щоб зрозуміти алгоритм дій, якщо потрібно порахувати ROI. підстав свої естімейти, врахуй свої ризики і вийде вже не сферичний, а реальний проєкт

«щас я вам покажу звідки беруться естімейти» ©

Давайте хоч тут Джиру не чіпати :D

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