Тестирование эффективности по. Как измерить тестирование. Тестирование методом белого ящика

Каждый раз, когда мы заваливаем очередной релиз, начинается суета. Сразу появляются виноватые, и зачастую – это мы, тестировщики. Наверное это судьба – быть последним звеном в жизненном цикле программного обеспечения, поэтому даже если разработчик тратит уйму времени на написание кода, то никто даже не думает о том, что тестирование – это тоже люди, имеющие определенные возможности.
Выше головы не прыгнуть, но можно же работать по 10-12 часов. Я очень часто слышал такие фразы)))

Когда тестирование не соответствует потребностям бизнеса – то возникает вопрос, зачем вообще тестирование, если они не успевают работать в установленные сроки. Никто не думает о том, что было раньше, почему требования нормально не написали, почему не продумали архитектуру, почему код кривой. Но зато когда у вас дедлайн, а вы не успеваете завершить тестирование, то тут вас сразу начинают карать…

Но это было пару слов о нелегкой жизни тестировщика. Теперь к сути 🙂

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

Руководству нужны цифры, статистика. Простые слова – это вас послушали, покивали головой, сказали – “Давай, делай” и все. После этого все ждут от вас чуда, но даже если вы что-то предприняли и у вас не получилось, вы или Ваш руководитель опять получает по шапке.

Любое изменение должно поддерживаться руководством, а чтобы руководство его поддержало, им нужны цифры, измерения, статистика.
Много раз видел, как из таск-трекеров пытались выгружать различную статистику, говоря, что “Мы снимаем метрики из JIRA”. Но давайте разберемся, что такое метрика.

Метрика - технически или процедурно измеримая величина, характеризующая состояние объекта управления.

Вот посмотрим – наша команда находит 50 дефектов при приемочном тестировании. Это много? Или мало? Говорят ли Вам эти 50 дефектов о состоянии объекта управления, в частности, процесса тестирования?
Наверное, нет.

А если бы Вам сказали, что количество дефектов найденных на приемочном тестировании равно 80%, при том, что должно быть всего 60%. Я думаю тут сразу понятно, что дефектов много, соответственно, мягко говоря, код разработчиков полное г….. неудовлетворителен с точки зрения качества.

Кто-то может сказать, что зачем тогда тестирование? Но я скажу, что дефекты – это время тестирования, а время тестирования – это то, что напрямую влияет на наш дедлайн.

Поэтому нужны не просто метрики, нужны KPI.

KPI – метрика, которая служит индикатором состояния объекта управления. Обязательное условие – наличие целевого значения и установленные допустимые отклонения.

То есть всегда, строя систему метрик, у вас должна быть цель и допустимые отклонения.

Например, Вам необходимо (Ваша цель), чтобы 90% всех дефектов решались с первой итерации. При этом, вы понимаете, что это не всегда возможно, но даже если количество дефектов, решенных с первого раза, будет равняться 70% – это тоже хорошо.

То есть, вы поставили себе цель и допустимое отклонение. Теперь, если вы посчитаете дефекты в релизе и получите значение в 86% – то это конечно не хорошо, но и уже не провал.

Математически это будет выглядеть, как:

Почему 2 формулы? Это связано с тем, что существует понятие восходящих и нисходящих метрик, т.е. когда наше целевое значение стремится к 100% или к 0%.

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

При этом не стоит забывать о том, как рассчитывать ту или иную метрику.

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

Для наглядного примера я расскажу Вам о метрике “Своевременность обработки дефектов тестированием”.

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

Не пугайтесь, в жизни это не так сложно, как выглядит на картинке!

Что мы имеем?

Ну понятно, что номер релиза, номер инцидента….

Critical - коэф. 5,

Major - коэф. 3,

Minor - коэф. 1,5.

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

Для ответа на эти вопросы мы сразу перенесемся к показателю эффективности и сразу зададим вопрос. А как рассчитать показатель, если значение одного запроса может равняться “нулю”. Если один или несколько показателей будет равно нулевому значению, то итоговый показатель при этом будет очень сильно снижаться, поэтому возникает вопрос, как наш расчет сбалансировать так, чтобы нулевые значения, к примеру, запросов с коэффициентом тяжести “1” не сильно влияли на нашу итоговую оценку.

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

Для того, чтобы у вас не сложилось непонимания в расчетах, введем конкретные переменные для расчета:

х - фактические время, потраченное на ретестирование дефекта;

y - максимально допустимое отклонение;

z - коэффициент тяжести.

Или на обычно языке, это:

W = E СЛИ (x<=y,1,(x/y)^z)

Таким образом, даже, если мы вышли за установленные нами рамки по SLA, наш запрос в зависимости от тяжести не будет серьезно влиять на наш итоговый показатель.

Все как и описывал выше:

х – фактические время, потраченное на ретестирование дефекта;

y – максимально допустимое отклонение;

z – коэффициент тяжести.

h – плановое время по SLA
Как это выразить в математической формуле я уже не знаю, поэтому буду писать программным языком с оператором ЕСЛИ.

R = ЕСЛИ(x<=h;1;ЕСЛИ(x<=y;(1/z)/(x/y);0))

В итоге мы получаем, что если мы достигли цели, то наше значение запроса равно 1, если вышли за рамки допустимого отклонения, то рейтинг равен нулевому значению и идет расчет весов.

Если наше значение находится в пределах между целевым и максимально допустимым отклонением, то в зависимости от коэффициента тяжести, наше значение варьируется в диапазоне .

Теперь приведу пару примеров того, как это будет выглядеть в нашей системе метрик.

Для каждого запроса в зависимости от их важности (коэффициент тяжести) имеется свой SLA.

Что мы тут видим.

В первом запросе мы на час всего лишь отклонились от нашего целевого значения и уже имеем рейтинг 30%, при этом во втором запросе мы тоже отклонились всего на один час, но сумма показателей уже равна не 30%, а 42,86%. То есть коэффициенты тяжести играют важную роль в формировании итогового показателя запроса.

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

Ну и чтобы в этом убедиться, можно просто посчитать, что среднее арифметическое показателей будет равно 43,21%, а у нас получилось 33,49%, что говорит о серьезном влиянии запросов с высокой важностью.

Давайте изменим в системе значения на 1 час.

при этом, для 5-го приоритета значение изменилось на 6%, а для третьего на 5,36%.

Опять же важность запроса влияет на его показатель.

Все, мы получаем итоговый показатель метрики.

Что Важно!

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

В одной организации я видел, что был разработан собственный фреймворк для сбора метрик из HP ALM и JIRA. Это действительно круто. Но важно помнить, что подобный процесс ведения метрик требует серьезного соблюдения регламентных процессов.

Ну и что самое важное – только вы можете решить, как и какие метрики Вам собирать. Не нужно копировать те метрики, которые вы собрать не сможете.

Подход сложный, но действенный.

Попробуйте и возможно у вас тоже получится!

Александр Мешков – Chief Operations Officer в Перфоманс Лаб, – обладает опытом более 5 лет в области тестирования ПО, тест-менеджмента и QA-консалтинга. Эксперт ISTQB, TPI, TMMI.

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

Тестирование программного обеспечения является неотъемлемой частью цикла разработки программного обеспечения.

Что такое тестирование программного обеспечения?

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

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

Методика тестирования

Широко используемыми методами тестирования являются модульное тестирование, интеграционное тестирование, приемочное тестирование, и тестирование системы. Программное обеспечение подвергается этим испытаниям в определенном порядке.

3) Системное тестирование

4) Приемочные испытания

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

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

Системное тестирование

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

Приемочные испытания

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

Если тестирование проводится с помощью предполагаемых клиентов, оно называется приемочными испытаниями клиента. В случае если тестирование проводится конечным пользователем программного обеспечения, оно известно, как приемочное тестирование (бета-тестирование).

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

Тестирование методом черного ящика

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

Тестирование методом белого ящика

Тестирование методом "Белого ящика", в отличие от "черного ящика", учитывает внутреннее функционирование и логику работы кода. Для выполнения этого теста, тестер должен иметь знания кода, чтобы узнать точную часть кода, имеющую ошибки. Этот тест также известен как White-box, Open-Box или Glass box тестирование.

Тестирование методом серого ящика

Тестирование методом серого ящика или Gray box тестирование, это что-то среднее между White Box и Black Box тестированием, где тестер обладает лишь общими знаниями данного продукта, необходимыми для выполнения теста. Эта проверка осуществляется посредством документации и схемы информационных потоков. Тестирование проводится конечным пользователем, или пользователям, которые представляются как конечные.

Нефункциональные тесты

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

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

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

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

Это тестирование проверяет аспект удобства и практичности программного обеспечения для пользователей. Легкость, с которой пользователь может получить доступ к устройству формирует основную точку тестирования. Юзабилити-тестирование охватывает пять аспектов тестирования, - обучаемость, эффективность, удовлетворенность, запоминаемость, и ошибки.

Тесты в процессе разработки программного обеспечения

Каскадная модель использует подход "сверху-вниз", независимо от того, используется ли она для разработки программного обеспечения или для тестирования.

Основными шагами, участвующими в данной методике тестирования программного обеспечения, являются:

• Анализ потребностей
• Тест дизайна
• Тест реализации
• Тестирование, отладка и проверка кода или продукта
• Внедрение и обслуживание

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

Agile Model

Эта методика основана на избирательном сочетании последовательного и итеративного подхода, в дополнение к довольно большому разнообразию новых методов развития. Быстрое и поступательное развитие является одним из ключевых принципов этой методологии. Акцент делается на получение быстрых, практичных, и видимых выходов. Непрерывное взаимодействие с клиентами и участие является неотъемлемой частью всего процесса разработки.

Rapid Application Development (RAD). Методология быстрой разработки приложений

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

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

Спиральная модель

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

Rational Unified Process (RUP). Рациональный унифицированный процесс

Методика RUP также похожа на спиральную модель, в том смысле, что вся процедура тестирования разбивается на несколько циклов. Каждый цикл состоит из четырех этапов - создание, разработка, строительство, и переход. В конце каждого цикла продукт/выход пересматривается, и далее цикл (состоящий из тех же четырех фаз) следует при необходимости.

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

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

Тест Вудкока

Инструкция

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

Не тратьте много времени, обдумывая каждое утверждение: достаточно нескольких секунд.

Помните, что результаты будут иметь смысл, только если Вы искренни.

Тестовое задание

1. Наша команда испытывает достаток в лидерстве.

2. Кажется, что решения являются принудительными по отношению к нам.

3. Людей не поощряют высказываться откровенно.

4. В трудной ситуации каждый берется за свои интересы.

5. Общение нуждается в улучшении.

6. Решения принимаются на неадекватном уровне иерархии.

7. Некоторые менеджеры неискренни сами с собой.

8. Мы редко подвергаем сомнению основное содержание или пользу наших совещаний.

9. Созданы недостаточные возможности для развития.

10. Мы часто ссоримся с другими подразделениями.

11. Члены команды не общаются друг с другом в достаточной мере.

12. Ясно, что организация ожидает от нашей команды.

13. Принятый порядок редко подвергается сомнению.

14. В действительности никому не ясно, куда мы движемся.

15. Люди не говорят, что они в действительности думают.

16. Люди имеют позицию «моя хата с краю».

17. В команде конфликт носит деструктивный характер.

18. Решения основываются на неадекватной информации.

19. Некоторым менеджерам не доверяют.

20. Мы не учимся на своих ошибках.

21. Менеджеры не помогают своим подчиненным учиться.

22. Отношения с другими группами являются прохладными.

23. Мы не обдумываем хорошо наше положение внутри организации.

24. Наша команда «политически» восприимчива.

25. Мы часто обнаруживаем, что нам недостает нужной квалификации.

26. Мы все очень заняты, но, кажется, везде не успеваем.

27. Спорные вопросы прячутся под ковер.

28. Помогло бы, если бы люди имели больше желания признавать свои ошибки.

29. Имеют место недоверие и враждебность.

30. Люди не допускаются к решениям.

31. Мало лояльности к команде.

32. Мнения извне не приветствуются.

33. Следовало бы иметь большую ротацию работ.

34. Мы редко работаем эффективно вместе с другими командами.

35. Нам не удалось обеспечить сотрудничество с другими командами и подразделениями.

36. Способность работать в команде является критерием отбора при поступлении в эту организацию.

37. Никто не налаживает необходимых связей с другими группами.

38. Мы не тратим требуемого времени на планирование будущего.

39. Деликатных вопросов избегают.

40. Бывает, что кому-то «всадили нож в спину».

41. В действительности мы не работаем вместе.

42. Неподходящие люди принимают решения.

43. Менеджеры являются слабыми и не готовы бороться и требовать внимания к своей точке зрения.

44. Я не получаю достаточной обратной связи.

45. Развиваются несоответствующие виды умений.

46. Помощь не придет из других частей организации.

47. Существует сильное непонимание между нашей командой и профсоюзами, которые оказывают давление на нас.

48. В этой организации вознаграждается слаженность работы в команде.

49. Мы не уделяем достаточно внимания взаимоотношениям.

50. Мы не имеем ясного представления о том, чего от нас ожидают.

51. Честность не является характерной чертой нашей команды.

52. Я не чувствую поддержки со стороны моих коллег.

53. Квалификация и информация распределены недостаточно хорошо.

54. Имеются сильные личности, которые идут своим собственным путем.

55. Чувство собственного достоинства не одобряется.

56. Нам следует уделять больше времени обсуждению методов работы.

57. Менеджеры не принимают всерьез личное развитие.

58. Другие части организации нас не понимают.

59. Нам не удается донести наше сообщение к внешнему миру.

60. Люди в команде имеют хорошие связи с другими членами организации.

61. Часто мы достигаем решений слишком быстро.

62. Образ действий, при котором ценится личность, имеет мало общего с тем, что достигнуто.

63. Слишком много секретов.

64. Конфликтов избегают.

65. Разногласия разлагают.

66. Приверженность к решениям низка.

67. Наши менеджеры полагают, что более строгий надзор улучшает результат.

68. Слишком много запретов в нашей команде.

69. Очевидно, что в другом подразделении имеются лучшие возможности.

70. Мы тратим много энергии на защиту наших границ.

71. Члены команды не понимают, чего от них ожидают.

72. Культура организации поощряет слаженную работу в команде.

73. Мы не уделяем достаточно внимания новым идеям.

74. Приоритеты не ясны.

75. Люди не вовлекаются в достаточной мере в принятие решений.

76. Слишком много взаимных обвинений и упреков.

77. Не всегда выслушивают.

78. Мы не используем в полном объеме навыки, которыми обладаем.

79. Менеджеры полагают, что люди по своему существу ленивы.

80. Мы тратим много времени на то, чтобы делать, и не уделяем достаточно времени тому, чтобы думать.

81. Не поощряется стремление личности к росту.

82. Мы не стараемся понять точку зрения других команд.

83. Нам не удается выслушать наших клиентов.

84. Команда работает в соответствии с целями организации.

Спасибо за ответы!

Ключ к тесту Вудкока для оценки эффективности команды

Описание

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

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

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

Кроме того, очень полезно сравнить результаты тестов руководителей и их подчиненных. Это позволяет оценить атмосферу в команде и определить степень доверия подчиненных к руководству.

Ключ к тесту

Перенесите выделенные ответы из анкеты в таблицу результата. Посчитайте количество отметок в каждом столбце. Запишите количество в строке «Итого».

Таблица результата

	А	В	С	D	Е	F	G	Н	I	J	К	L
	1	2	3	4	5	6	7	8	9	10	11	12
	13	14	15	16	17	18	19	20	21	22	23	24
	25	26	27	28	29	30	31	32	33	34	35	36
	37	38	39	40	41	42	43	44	45	46	47	48
	49	50	51	52	53	54	55	56	57	58	59	60
	61	62	63	64	65	66	67	68	69	70	71	72
	73	74	75	76	77	78	79	70	81	82	83	84
Итого

Перенесите счет столбцов из строки «Итого» в таблицу.

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

Как можно при помощи достаточно простого инструмента оценить возможную эффективность использования автотестов на проекте?

Что определяется как «эффективность» автоматизации тестирования?

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

В случае автоматизации под прибылью понимается экономия на ручном тестировании . Кроме того, что прибыль в данном случае может быть и не явной – например, результаты нахождения дефектов в процессе ad-hoc тестирования инженерами, время которых высвободилось за счет автоматизации. Такую прибыль достаточно сложно рассчитать, поэтому можно либо делать допущение (например +10%) либо опускать.

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

Другой пример – исключение «человеческого фактора» из процесса тестирования систем. Это важно, когда точность и корректность выполнения операций является критической для бизнеса. Цена такой ошибки может быть значительно выше стоимости разработки и поддержки автотеста.

Зачем измерять эффективность?

Измерение эффективности помогает ответить на вопросы: «стоит ли внедрять автоматизацию на проекте?», «когда внедрение принесет нам значимый результат?», «сколько часов ручного тестирования мы заместим?», «можно ли заменить 3 инженеров ручного тестирования на 1 инженера автоматизированного тестирования?» и др.

Данные расчеты могут помочь сформулировать цели (или метрики) для команды автоматизированного тестирования. Например, экономия X часов в месяц ручного тестирования, сокращение расходов на команду тестирования на Y условных единиц.