Як переконати клієнта в доцільності автоматизації

Привіт, мене звати Марина, і я працюю QA Consultant в компанії Valtech Україна. Хочу поділитися власним досвідом того, як можна запропонувати автоматизацію клієнту, який не дуже в цьому зацікавлений, на проєкті, який уже давно триває. У статті не буде однозначних і безапеляційних рішень, але буде все те, що допомогло нам переконати замовника, що інвестиція в автоматизацію окупиться.

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

Ілюстрація Марії Рибак

Навіщо автоматизація на проєкті, де й так усе добре

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

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

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

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

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

Бути клієнту партнером, а не супротивником

Якщо ми повернемося до самої суті тестування і роботи QA-команди, то можемо говорити, що мета тестування — це гарантувати якість програмного забезпечення. Нині високу якість продукту сприймають як належне та безумовне. Наша толерантність до недостатньої якості програмного забезпечення різко знижується, щойно ми з розробників/тестувальників стаємо користувачами. Якщо після релізу знаходяться помилки, ми намагаємося їх швидко виправити та знайти пояснення, чому так сталося, проте з погляду користувача there is no excuse. Тому саме на підвищенні якості як основної переваги застосування автоматизації можна будувати свою пропозицію для клієнта.

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

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

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

На нашому ecommerce-проєкті ідея автоматизації витала давно. Складнощі полягали в тому, що проєкт масштабний і вміщує велику кількість сайтів, які побудовані на спільній платформі. Тож спочатку було важко визначити, що саме потрібно автоматизовувати. Вирішили застосовувати автотести для перевіряння найбільш важливого функціоналу: end-to-end сценарію можливості купівлі товару.

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

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

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

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

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

Автоматизація як ілюстрація роботи QA

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

Натомість автотести дуже промовисті й звіти пройдених тестів підходять тут якнайкраще. Вони інформативні: видно кількість тестів і відсоткове значення успішних, видно покриття і перелік девайсів/браузерів, на яких тести запускалися, видно, які кроки перевіряли і з якими даними. І все це можна отримувати регулярно, до чашки кави зранку. Метрики, побудовані на основі звітів автотестів, — наочні й доступні. Так клієнт бачитиме результати запуску тестів і знатиме деталі самого тесту.

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

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

👍НравитсяПонравилось14
В избранноеВ избранном3
Подписаться на тему «тестирование»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


2 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

«Якщо ми повернемося до самої суті тестування і роботи QA-команди»
Мені здається, що в 21 році нам вже давно варто розрізняти тестування та QA...

«...мета тестування — це гарантувати якість програмного забезпечення»
Тестування — не може гарантувати якість ПЗ від слова «ніколи».

«Тому саме на підвищенні якості як основної переваги застосування автоматизації можна будувати свою пропозицію для клієнта»

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

«Вирішили застосовувати автотести для перевіряння найбільш важливого функціоналу: end-to-end сценарію можливості купівлі товару»

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

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

Цікаво, як розвивалася сами дискусія з клієнтом?

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