Переклад: Ольга Алифанова
Так як відповідальність за автоматизацію тестування все більше пов'язується з Agile-командами, роль фреймворка автоматизації тестування розвивається. стає більш розпорошеною. Все менше організацій покладається на монолітний комерційний фреймворк, і рухаються до слабо сполученим інструментам з відкритим вихідним кодом, більш відповідним цілям окремо взятої команди.
Це дозволяє організації бути гнучкою, але створює проблему управління витратами. Розпилення відповідальності за автоматизацію і її інструменти ускладнює QA-експертам оцінку того, скільки в точності автоматизація тестування варто.
Але незважаючи на відсутність точних параметрів розрахунку витрат, ветерани тестування добре знайомі з найбільш дорогими сценаріями автоматизації. TechBeacon попросив трьох професіоналів тестування поділитися своїми думками про те, які практики безглуздо задирають витрати побудови і підтримки ефективного фреймворка автоматизації. Ось п'ять найбільш витратних з них:
1.Оверінжінірінг фреймворка автоматизації
Щодо того, як організації можуть негативно вплинути на економіку автоматизації, існують різні думки, але все тест-професіонали сходяться в одному: оверінжінірінг - це погано. Немає кращого способу задерти витрати, ніж спробувати автоматизувати всі на світі.
"Результатом автоматизації тестування не повинна бути автоматизація всього і вся" - Мелісса Тондій. директор з якості, EMS Software.
"Якщо це те, що ви отримуєте на виході - без оголошеної цінності, без закладеного на підтримку всіх скриптів часу - ви швидко прийдете в ту точку, де у вас буде купа створених скриптів, що не запускалися місяцями. Це трата часу і сил", каже Тондій. "Незалежно від того, комерційним продуктом ви користуєтеся або відкритим вихідним кодом, перший крок - це розуміння, до чого ви хочете прийти. Розберіться і встановіть чекліст критеріїв автоматизації або створіть документ, який повідомляє, що ви автоматизуєте у вашій компанії і чому".
"Якось безглуздо ставати кращим в світі автоматизаторів даремних тестів" - Баз Дійкстра. консультант по автоматизації, The Future Group.
Грег Паскаль. директор з якості в Dave Ramsey Solutions, каже, що як консалтингова організація, що має справу з постачальниками, вони вважають визначення того, що вийде на виході, лакмусовим папірцем. "Бійтеся постачальника, який хоче автоматизувати весь регрес - це майже завжди веде до зайвих витрат".
Він пропонує почати з критичного набору Автотест - від 15 до 25.
"Хороший автотест відстежується до вихідного хорошого ручного тесту. Ручний тест завжди повинен створюватися раніше автоматизованого" - Грег Паскаль.
2.Попросіть консультанта організувати вашу автоматизацію
Ще одна дорога помилка, якої припускаються організації - це звернення до консультантів із запитом побудови фреймворка як одноразового проекту, щоб "запустити" процес автоматизації. "У переважній більшості випадків, що я бачив, автоматизація припадає пилом потім на полиці - її не використовують", говорить Паскаль.
Це часто пов'язано з тим, що QA-менеджер (або той, хто відповідав за інвестицію) продав проект керівництву як засіб заощадити - скоротити кількість людей, що ганяють рунчие тести. Але в момент, коли контрактори покинули будівлю, Автотест стали потребувати підтримки, а без потрібних ресурсів для цього організація зазнає поразки.
"Майже кожен раз, коли я з цим стикався, нам доводилося впрягатися в роботу і робити дуже багато, щоб тримати їх на плаву, і щоб вони могли тривалий час обходитися без нас", каже Паскаль, додаючи, що багато хто з цих проектів виглядають, як автоматизація, але їх абсолютно неможливо підтримувати довго.
"Якщо вас не вчили, що потрібно для того, щоб побудувати підтримуваний фреймворк автоматизації, ви можете зробити щось, що здорово виглядає в демо-версії і може навіть пропрацювати тиждень-другий. Але як тільки воно почне ламатися, ціна підтримки злетить вгору миттєво ", говорить Паскаль.
3.Ігнорірованіе команди при виборі між комерційним інструментом та інструментом на відкритому вихідному коді.
Багато організацій вибирають інструменти автоматизації, засновані на відкритому вихідному коді, щоб домогтися більшої гнучкості, але найчастіше це просто фінансові причини. Більшість технологів в курсі, що "відкритий вихідний код" необов'язково означає "безкоштовний". У тестуванні багато хто просто не розуміють, як багато досвідчених людей їм доведеться підключити до проекту, щоб зробити робочий фреймворк або набір автоматизованих інструментів.
Який урок з цього треба винести: враховуйте витрати на придбання досвідчених розробників та інженерів з якості, або переманювання їх з іншого підрозділу організації. Використання інструментів з відкритим вихідним кодом часто вимагає глибоких знань автоматизації та навичок розробки ПО, щоб створювати тести, а це коштує грошей, каже Дійкстра.
"Один з факторів при виборі відкритого вихідного коду - це оцінка зрілості і рівня знань команди, яка буде відповідати за автоматизацію" - Баз Дійкстра.
4.Создание фреймворка з нуля.
Навіть якщо у вас є необхідний досвід, щоб створити ефективний фреймворк, ви ризикуєте витратити гроші, намагаючись винайти колесо.
Найчастіше Ліди вибирають між інструментом, доступним у продажу, і створенням його з нуля. Обидва варіанти вкрай дороги, за словами Паскаля.
"Навіть якщо вони виберуть відкритий вихідний код, вони витратять гроші, тому що по суті все одно починають з нуля. Існують фреймворки, які вже включають доступні платформи, але в більшості випадків інженери цим не користуються" - Грег Паскаль.
5.Відсутність пріоритетності, коли білди падають
Автоматизація - це відмінна штука, коли вона працює, але вона швидко вставить палиці в колеса безперервної розробці, якщо правильні люди і правильні процеси вчасно не виправляють її проблем. Автоматизація може швидко задерти витрати, якщо організація не має процесу пріоритетності для падаючих білдів, каже Тондій.
Якщо в якийсь момент білд падає на сьютах, які запускаються з кожним новим білдом, і у вас немає потрібних людей, то результатом будуть "десятки повалених білдів, з якими ніхто не розбирається", додає вона.
Консенсус, хто в першу чергу відповідає за падіння, і процес розбору цих падінь, критично важливі для гарної автоматизації. В іншому випадку ви отримаєте купу непотрібних рухів тіла, які витрачають ваш час, говорить вона.
"І ось ви виявляєте, що у вас купа впали білдів, і тепер нам потрібно витрачати час на з'ясування, чому вони впали, замість виразної комунікації за критеріями, яких потрібно дотримуватися, коли і якщо білд падає" - Мелісса Тондій.
Отримуйте вигоду за ваші гроші
Пріоритезація потреб організації по відношенню до ресурсів повинна стояти на чолі кута, якщо ви плануєте тримати витрати автоматизації під контролем. Ідеальний фреймворк необов'язково має всі можливі свистілки, які забажали розробники і тестувальники. Виконання їх бажань може вилитися в непотрібний багаж.
Замість цього організації повинні взяти за основу ітеративний підхід мінімально життєздатного продукту. як і з будь-яким іншим ПО. Таким чином ви швидко отримаєте щось корисне і робоче, а потім поступово поліпшите його.