Home

Автор: Эрика Чиковски (Ericka Chickowski)

Оригинал статьи: https://techbeacon.com/5-proven-ways-blow-your-test-automation-budget

Перевод: Ольга Алифанова

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

Это позволяет организации быть гибкой, но создает проблему управления издержками. Распыление ответственности за автоматизацию и ее инструменты усложняет QA-экспертам оценку того, сколько в точности автоматизация тестирования стоит.

Но несмотря на отсутствие точных параметров расчета издержек, ветераны тестирования хорошо знакомы с наиболее дорогостоящими сценариями автоматизации. TechBeacon попросил трех профессионалов тестирования поделиться своими мыслями о том, какие практики бессмысленно задирают издержки построения и поддержки эффективного фреймворка автоматизации. Вот пять наиболее затратных из них:

1. Оверинжиниринг фреймворка автоматизации

Насчет того, как организации могут негативно повлиять на экономику автоматизации, существуют разные мнения, но все тест-профессионалы сходятся в одном: оверинжиниринг – это плохо. Нет лучшего способа задрать издержки, чем попытаться автоматизировать все на свете.

"Результатом автоматизации тестирования не должна быть автоматизация всего и вся" – Мелисса Тонди, директор по качеству, EMS Software.

"Если это то, что вы получаете на выходе – без объявленной ценности, без заложенного на поддержку всех скриптов времени – вы быстро придете в ту точку, где у вас будет куча созданных скриптов, которые не запускались месяцами. Это трата времени и сил", говорит Тонди. "Вне зависимости от того, коммерческим продуктом вы пользуетесь или открытым исходным кодом, первый шаг – это понимание, к чему вы хотите прийти. Разберитесь и установите чеклист критериев автоматизации или создайте документ, который сообщает, что вы автоматизируете в вашей компании и почему".

"Как-то бессмысленно становиться лучшим в мире автоматизатором бесполезных тестов" – Баз Дийкстра, консультант по автоматизации, The Future Group.

Грег Паскаль, директор по качеству в Dave Ramsey Solutions, говорит, что как консалтинговая организация, имеющая дело с поставщиками, они считают определение того, что получится на выходе, лакмусовой бумажкой. "Опасайтесь поставщика, который хочет автоматизировать весь регресс – это почти всегда ведет к лишним тратам".

Он предлагает начать с критического набора автотестов – от 15 до 25.

"Хороший автотест отслеживается до исходного хорошего ручного теста. Ручной тест всегда должен создаваться раньше автоматизированного" – Грег Паскаль.

2. Попросить консультанта организовать вашу автоматизацию

Еще одна дорогостоящая ошибка, которую делают организации – это обращение к консультантам с запросом построения фреймворка как одноразового проекта, чтобы "запустить" процесс автоматизации. "Практически во всех случаях, что я видел, автоматизация пылится потом на полке – ее не используют", говорит Паскаль.

Это зачастую связано с тем, что QA-менеджер (или тот, кто отвечал за инвестицию) продал проект руководству как средство сэкономить – сократить количество людей, гоняющих рунчые тесты. Но в момент, когда контракторы покинули здание, автотесты стали нуждаться в поддержке, а без нужных ресурсов для этого организация терпит поражение.

"Почти каждый раз, когда я с этим сталкивался, нам приходилось впрягаться в работу и делать очень многое, чтобы держать их на плаву, и чтобы они могли длительное время обходиться без нас", говорит Паскаль, добавляя, что многие из этих проектов выглядят, как автоматизация, но их совершенно невозможно поддерживать долго.

"Если вас не учили, что нужно для того, чтобы построить поддерживаемый фреймворк автоматизации, вы можете сделать что-то, что здорово смотрится в демо-версии и может даже проработать недельку-другую. Но как только оно начнет ломаться, цена поддержки взлетит вверх мгновенно", говорит Паскаль.

3. Игнорирование команды при выборе между коммерческим инструментом и инструментом на открытом исходном коде.

Многие организации выбирают инструменты автоматизации, основанные на открытом исходном коде, чтобы добиться большей гибкости, но зачастую это просто финансовые причины. Большинство технологов в курсе, что "открытый исходный код" необязательно значит "бесплатный". В тестировании многие просто не понимают, как много опытных людей им придется подключить к проекту, чтобы сделать рабочий фреймворк или набор автоматизированных инструментов.

Какой урок из этого надо извлечь: учитывайте издержки на приобретение опытных разработчиков и инженеров по качеству, или переманивание их из другого подразделения организации. Использование инструментов с открытым исходным кодом зачастую требует глубоких знаний автоматизации и навыков разработки ПО, чтобы создавать тесты, а это стоит денег, говорит Дийкстра.

"Один из факторов при выборе открытого исходного кода – это оценка зрелости и уровня знаний команды, которая будет отвечать за автоматизацию" – Баз Дийкстра.

4. Создание фреймворка с нуля.

Даже если у вас есть нужный опыт, чтобы создать эффективный фреймворк, вы рискуете потратить деньги, пытаясь изобрести колесо.

Зачастую лиды выбирают между инструментом, доступным в продаже, и созданием его с нуля. Оба варианта крайне дороги, по словам Паскаля.

"Даже если они выберут открытый исходный код, они потратят деньги, потому что по сути все равно начинают с нуля. Существуют фреймворки, которые уже включают доступные платформы, но в большинстве случаев инженеры этим не пользуются" – Грег Паскаль.

5. Отсутствие приоритезации, когда билды падают

Автоматизация – это отличная штука, когда она работает, но она быстро вставит палки в колеса непрерывной разработке, если правильные люди и правильные процессы вовремя не исправляют ее проблем. Автоматизация может быстро задрать издержки, если у организации нет процесса приоритезации для падающих билдов, говорит Тонди.

Если в какой-то момент билд падает на сьютах, которые запускаются с каждым новым билдом, и у вас нет нужных людей, то результатом будут "десятки упавших билдов, с которыми никто не разбирается", добавляет она.

Консенсус, кто в первую очередь отвечает за падения, и процесс разбора этих падений, критично важны для хорошей автоматизации. В противном случае вы получите кучу ненужных телодвижений, которые тратят ваше время, говорит она.

"И вот вы обнаруживаете, что у вас куча упавших билдов, и теперь нам нужно тратить время на выяснения, почему они упали, вместо внятной коммуникации по критериям, которым нужно следовать, когда и если билд падает" – Мелисса Тонди.

Получайте выгоду за ваши деньги

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

Вместо этого организации должны взять за основу итеративный подход минимально жизнеспособного продукта, как и с любым другим ПО. Таким образом вы быстро получите что-то полезное и рабочее, а затем постепенно улучшите его.

Обсудить в форуме