Подсчет ROI для автоматизации не имеет ничего общего с реальностью

общие вопросы
#1

По моему глубокому убеждению, «ROI для автоматизации» придумали консультанты с дикого запада, которым нечего было считать, и они решили придумать считать Test Automation Return On Investment.

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

Ну, а после внедрения автоматизации – ROI посчитать очень просто, потому что он бинарный: либо классный либо хреновый.

Да, наверное, этот самый ROI зависит и от навыков Автоматизаторов, и от качества тестового фреймворка. С подходом Record&Play, TA ROI для 300 тестов будет очень хреновый.

Кто что думает по этому поводу? Или кто это даже считал?

#2

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

Менеджеры или те кто заказывают автоматизацию, видят ее приблизительно так:

  • заказчик: мы уже потратили на тестирование 100к у.е.
  • заказчик: а в следующем году нам надо каждый месяц делать тестирование
  • заказчик: блин, но 100к у.е. много?! что же делать?
  • голос с стороны: а может автоматизировать тестирование?
  • заказчик: а сколько это будет стоить мне? хм, не знаю... (дай-ка я позову людей которые разбираются)
  • консультант: что вам надо?
  • заказчик: я не хочу тратить 100к у.е. на тестирование, хочу чтобы было меньше
  • консультант: автоматизация будет стоить вам 80к у.е.
  • заказчик: ого... почему так дорого? покажите мне почему такая цена?

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

#3

Я хочу сделать жизненно важное уточнение вопроса.
На самом деле, подсчитать ROI очень просто, потому что формула тоже очень простая:

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

Но, вот вопрос, как предсказать ROI перед началом автоматизации? На сколько прогноз будет верным?
Дело в том, что если погуглить по фразам Test Automation ROI Calculator, ROI for Test Automation, то можно найти много различных статей, и докторских диссертаций по этой теме.
Но, я уверен, что сделать реальный прогноз, может только гениальный экономист + финансист + математик + автоматизатор. И таких, наверное, не много. Дело в том, что цена автоматизации зависит и от квалификации разработчика, и от качества фреймворка.

Вот предположим, линейный Record&Play фреймворк может очень быстро дать результаты очень быстро. За день можно записать тесткейсов с 20-ть, а то и больше. Но, вот только потом все отразится на поддержке кода так, что в итоге скорее всего всё придется переписать. Зато за год, если приложения не менялось и автоматизаторы не увольнялись, он может показать хороший ROI: потому что затраты за зарплату автоматизаторов не большие и много тесткейсов было автоматизировано.

С другой стороны, объектно-ориентированный фреймворк, с применением того же Page Object, с кодом, который можно использовать повторно, может показать невысокие цифры окупаемости в краткосрочной перспективе. И очень сильно зависит от квалификации его разработчиков. Зато, в долгосрочной перспективе, такой фреймворк устойчив к изменением как самого приложения, так и команды автоматизаторов.

Вот как показать на цифрах то, что с линейным фреймворком сначала будет все круто, а потом капец, а с объектно-ориентированным сначала не очень – а потом круто?

Я хочу сделать жизненно важное уточнение вопроса.

На самом деле, подсчитать ROI очень просто, потому что формула тоже очень простая:

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

 

Но, вот вопрос, как предсказать ROI перед началом автоматизации? На сколько прогноз будет верным?

Дело в том, что если погуглить по фразам Test Automation ROI Calculator, ROI for Test Automation, то можно найти много различных статей,  и докторских диссертаций по этой теме.

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

 

Вот предположим, линейный Record&Play фреймворк может очень быстро дать результаты очень быстро. За день можно записать тесткейсов с 20-ть, а то и больше. Но, вот только потом все отразится на поддержке кода так, что в итоге скорее всего всё придется переписать. Зато за год, если приложения не менялось и автоматизаторы не увольнялись, он может показать хороший ROI: потому что затраты за зарплату автоматизаторов не большие и много тесткейсов было автоматизировано.

 

С другой стороны, объектно-ориентированный фреймворк, с применением того же Page Object, с кодом, который можно использовать повторно, может показать невысокие цифры окупаемости в краткосрочной перспективе. И очень сильно зависит от квалификации его разработчиков. Зато, в долгосрочной перспективе, такой фреймворк устойчив к изменением как самого приложения, так и команды автоматизаторов.

 

Вот как показать на цифрах то, что с линейным фреймворком сначала будет все круто, а потом капец, а с объектно-ориентированным сначала не очень – а потом круто?

Материал для изучения ROI Automation и его подсчета
#4

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

К фиксированным затратам относятся затраты на лицензии (если испоьзуются платные инструменты) + время на начальную подготовку фреймворка (из опыта могу сказать, что на это уходит обычно 1-2 недели). Что можно определить здесь? Например, у вас есть веб-приложение и вы выбираете, чем бы его автоматизировать. Есть возможность использовать QTP (10k$ за лицензию) или же взять Selenium, так как ничего сверх-хитрого и стороннего не используется. Банальная оценка затрат на постановку автоматизации покажет, что при таких раскладах стоимость одной лицензии QTP будет дороже затрат на постановку автоматизации, если ее делать на Селениуме. То есть, в этом случае явное предпочтение идет более бесплатному инструменту, так как величина ROI в ближайшей перспективе уже будет положительной и заметно превышать 100%, в то время как аналогичное решение на QTP все еще будет сидеть в минусах.

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

У нас остаются показатели затрат на разработку и затраты на поддержку тестов. В цифрах разные подходы отражаются по-разному для затрат на поддержку и на разработку.

Например, если вначале при Record&Play затраты на поддержку равны 0, то через определенное время эта поддержка занимает 80-100%. Основная беда Record&Play в том, что через некоторое время мы фактически переписываем все нафик, в то время как при более maintenance-oriented подходе (тот же Page object) затраты на поддержку за то же время достигают порядка 20-30%. Вот примерно в этих цифрах выражается "капец как плохо" или "а потом все хорошо". Просто нужно взять несколько графиков, отражающих динамику развития автоматизации и выразить это в общих числах. Например, можно взять количество автотестов. Если со временем затраты на поддержку займут 100%, то прироста автоматизации просто не будет.

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

#5

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

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

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

Как бы все не планировалось, все равно надо будет перепланировать!

Тем не менее, ROI нужно считать и показывать, иначе заказчик не понимает, за что же все таки нужно платить деньги и когда это окупиться.