<style>.lazy{display:none}</style>Оценка затрат на тестирование ПО

Оценка затрат на тестирование ПО

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

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

БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"

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

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

Содержание

Процесс оценки затрат

Оценка (англ. estimation, осюда – “эстимация”, “эстимейты”) — это поиск более или менее точной, но пригодной к использованию величины в ситуации недостатка исходных данных. [Ссылка: Википедия].

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

Первый подход – реактивный. Мы пытаемся справиться с проблемой только после того, как она возникла.

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

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

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

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

Основные входные данные для оценки

Ниже приведены основные вводные, необходимые для оценки затрат на тестирование.

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

2. Доступные документы (артефакты). В таких случаях очень полезны системы управления тестированием (TMS), поскольку они хранят требования и документы с уточнениями. Эти документы могут быть использованы командой QA для четкого определения объема задач проекта.

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

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

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

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

7. Ведение документации и составление протоколов. Вся информация, имеющая отношение к процессу оценки, должна быть документирована.

Действия, которые необходимо выполнить в процессе оценки затрат:

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

Наиболее известные методы оценки тестирования

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

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

Техника оценки тестовых поинтов

Оценка трудозтрат на тестирование с применением тестовых поинтов происходит следующим образом:

  1. Определяем существующий размер ПО
  2. Конвертируем размер ПО в необработанные тестовые поинты (Unprocessed Test Points, UTP). Для этого используется регулирующий коэффициент, соответствующий типу приложения (десктопное, клиент-серверное, веб-приложение).
  3. Вычисляем комбинированный весовой коэффициент (Combined Weight Factor, CWF).
  4. Назначаем уникальный вес каждому отдельному тесту.
  5. Складываем все отдельные веса тестов.
  6. Умножаем результат на вес, назначенный приложению (Application Weigth).
  7. Умножаем результат на вес, назначенный языку (для юнит-тестирования).
  8. Умножаем результат на вес инструментов, если они применяются в тестировании.

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

Необработанные тестовые поинты (UTP) умножаются на комбинированный весовой коэффициент (CWF) для получения оценки тестирования в эквиваленте тестового поинта.

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

Затраты по тестированию в человеко-часах рассчитываются путем умножения веса тестового поинта на коэффициент продуктивности.

Для расчета оценки с использованием метода тестовых поинтов мы учитываем следующие переменные:

Сложность требований к тестированию

Вид сложностиСложность
Простой< 2 транзакций
Средний3-6 транзакций
Сложный> 6 транзакций

Взаимодействие с другими требованиями

Вид сложностиИнтерфейс с другими требованиями
Простой0
Средний< 3
Сложный> 3

Общее количество поинтов верификации

Вид сложностиОбщее число поинтов верификации
Простой< 2
Средний3-8
Сложный> 8

Базовые тестовые данные

Вид сложностиБазовые тестовые данные
ПростойНе требуются
СреднийТребуются
СложныйТребуются

Затем нам нужно рассмотреть вес для каждого параметра тестируемого ПО и организовать их следующим образом:

КоэффициентВес коэффициентаВес сложности
Весомость домена(0-10)(0-3)
Горизонтальная весомость(0-10)(0-3)
Подготовка тестовых данных(0-10)(0-3)
Поддержка многоязычности(0-10)(0-3)
Настройка среды и задержка сети(0-10)(0-3)
Стабильность требований(0-10)(0-3)
Интеграция с другими устройствами(0-10)(0-3)
Управление настройками(0-10)(0-3)

Формулы:

Коэффициент корректировки = Среднее значение (Вес сложности * Вес коэффициента) / 30

Скорректированный тестовый поинт для разработки тест-кейса = Общий тестовый поинт * (1 + Коэффициент корректировки для разработки тест-кейса)

Скорректированный тестовый поинт для выполнения тест-кейса = Общий тестовый поинт * (1 + Коэффициент корректировки для выполнения тест-кейса)

Общий тестовый поинт (нормализованный) * (1 + Коэффициент корректировки для разработки/исполнения тест-кейса) = Скорректированный тестовый поинт для разработки/исполнения тест-кейса

Общее усилие в человеко-часах (ЧЧ) = Количество нормализованных тестовых поинтов / Производительность (в нормализованных тестовых поинтах на человеко-час)

Примеры оценки

Давайте попробуем применить вышеприведенные формулы на практике.

Предположим, у нас есть требования к тестированию, в соответствии с которыми мы должны проверить 5 тестовых сценариев.

Допустим, тестовый сценарий 1 содержит 5 ожидаемых результатов тестирования, тестовый сценарий 2 — 6 ожидаемых результатов тестирования, тестовый сценарий 3 — только 2 ожидаемых результата тестирования, тестовый сценарий 4 — 9 ожидаемых результатов тестирования, тестовый сценарий 5 — также 9 ожидаемых результатов тестирования.

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

Тестовые сценарии в сложном классе будут иметь более 7 ожидаемых результатов, тогда как в простом – менее 5. В умеренном классе тестовые сценарии будут иметь от 4 до 7 ожидаемых результатов.

Таким образом, мы классифицируем тестовый сценарий 1 и тестовый сценарий 2 как умеренные, сценарий 4 и сценарий 5 как сложные, а сценарий 3 как простой.

Теперь мы применим тестовые поинты ко всем этим сценариям. Мы применили 5 тестовых поинтов для сложного класса, 3 для умеренного и 2 для простого.

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

  • Сценарий 1: 3 тестовых поинта * 5 ожидаемых результатов = скорректированные тестовые поинты = 25
  • Сценарий 2: 3 тестовых поинта * 6 ожидаемых результатов = скорректированные тестовые поинты = 30
  • Сценарий 3: 2 тестовых поинта * 2 ожидаемых результата = скорректированные тестовые поинты = 4
  • Сценарий 4: 5 тестовых поинтов * 9 ожидаемых результатов = скорректированные тестовые поинты = 45
  • Сценарий 5: 5 тестовых поинтов * 9 ожидаемых результатов = скорректированные тестовые поинты = 45

Таким образом, учитывая, что нам нужно подать заявку, скажем, на 5 человеко-часов для каждого скорректированного тестового поинта, мы получаем следующий приблизительный результат:

  • Сценарий 1: 25 скорректированных тестовых поинтов * 5 человеко-часов = 125 человеко-часов
  • Сценарий 2: 30 скорректированных тестовых поинтов * 5 человеко-часов = 150 человеко-часов
  • Сценарий 3: 4 скорректированных тестовых поинта * 5 человеко-часов = 20 человеко-часов
  • Сценарий 4: 45 скорректированных тестовых поинтов * 5 человеко-часов = 225 человеко-часов
  • Сценарий 5: 45 скорректированных тестовых поинтов * 5 человеко-часов = 225 человеко-часов

Таким образом, общее приблизительное количество человеко-часов составляет 745.

Метод оценки сценариев использования

Метод оценки точек сценариев использования основан на пользовательских сценариях (use-cases), при этом мы рассчитываем общую сумму затрат на тестирование на основе сценариев использования или требований.

Ниже приведен подробный процесс метода оценки сценариев использования:

метод оценки точек сценария использования

Рассмотрим на том же примере: в конкретном требовании у нас есть 5 вариантов использования, вариант использования 1, вариант использования 2,…, вариант использования 5 соответственно. Теперь рассмотрим, что вариант использования 1 состоит из 6 актеров (акторов), вариант использования 2 состоит из 15 актеров, варианты использования 3, 4 и 5, 3, 4 и 5 актеров соответственно.

Мы рассматриваем любой вариант использования, в котором общее количество актеров меньше 5, как отрицательный, любой вариант использования, в котором общее количество актеров равно или больше 5 и меньше или равно 10, как положительный, а любой вариант использования, в котором больше 10 актеров, как исключительный.

Мы решили присвоить 2 балла за исключительные случаи использования, 1 балл за положительные и -1 балл за отрицательные.

Таким образом, мы классифицируем случаи использования 1 и 5 как положительные, случай использования 2 как исключительный и случаи использования 3, 4 как отрицательные соответственно, исходя из наших вышеуказанных предположений.

Таким образом, вес необработанных актеров = случай использования 1 = (общее количество актеров) 5 * 1(присвоенный балл) = 5.

Аналогично:

Вариант использования 2 = 15 * 2 = 30.

Повторяя процесс для остальных сценариев использования, мы получаем вес необработанных актеров = 33

Вес необработанного случая использования = общее количество случаев использования = 5

Точка необработанного сценария использования = вес необработанного актера + вес необработанного сценария использования = 33 + 5 = 38

Обработанный сценарий использования = 38 * [0,65 + (0,01 * 50] = 26,7 или приблизительно 28 человеко-часов

Метод разбивки рабочих фаз

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

  • Разделите общую работу на этапы.
  • Начните с самого простого этапа и определите его приблизительную оценку затрат.
  • Затем определите следующий возможный этап, к которому можно приступить после завершения этого этапа.
  • Определите возможный набор приближенных значений, которые могут быть применены к этому этапу, и выберите максимальное значение из всех полученных приближенных значений.
  • Суммируйте приближенное значение оценки, добавив значение оценки усилий на текущем этапе к уже существующему значению.
  • Продолжайте выполнять шаги с 3 по 5, пока не будут исчерпаны все этапы, определенные на первом этапе.
  • Примите окончательное приближенное значение оценки как конечное.

Предположим, что в требовании есть 5 необходимых этапов. На начальном этапе 1 мы предполагаем, что общее количество необходимых усилий составляет 35 человеко-часов, затем мы приступаем к следующему этапу 2, для которого у нас есть 4 сравнительных предположения 35, 45, 55 и 65 соответственно.

Мы рассматриваем 65 человеко-часов, что является максимальным значением. На этапах 3, 4, 5 мы получаем оценки (12, 33, 43, 54), (15, 10, 7, 8) и (2, 16, 5, 13) соответственно. Применяя указанный принцип, мы получаем 185 человеко-часов соответственно.

9 общих советов о том, как точно оценить время тестирования

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

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

2. Учитывайте цикл исправления ошибок: Оценка тестирования также включает в себя цикл работы над дефектами. Фактический цикл тестирования может занять больше дней, чем предполагалось.

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

3. Наличие всех ресурсов на расчетный период: Оценка тестирования должна учитывать все отпуска, запланированные членами команды (обычно учитываются длительные отпуска) в ближайшие несколько недель или несколько месяцев. Это обеспечит реалистичность оценок.

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

4. Можно ли проводить параллельное тестирование? Есть ли у вас предыдущие версии того же продукта, чтобы можно было сравнить результаты? Если да, то это может немного облегчить задачу тестирования. Вам следует подумать об оценке на основе версии вашего продукта.

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

6. Используйте свой прошлый опыт при принятии решений! Опыт прошлых проектов играет важную роль при подготовке оценки необходимого времени. Мы можем попытаться избежать всех трудностей или проблем, с которыми сталкивались в прошлых проектах. А также проанализировать, какими были предыдущие оценки и насколько они помогли реализовать продукт в срок.

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

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

8. Собираетесь ли вы проводить нагрузочное тестирование? Если вам необходимо потратить значительное время на тестирование производительности, то смета должна быть составлена соответствующим образом. Оценки для проектов, включающих нагрузочное тестирование, должны рассматриваться по-другому.

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

Некоторые люди могут работать быстрее, чем другие. Хотя это и не является основным фактором, это увеличивает общую задержку релиза.

Заключение

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

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

Перевод статьи N. Sandhya Rani “Software Test Estimation Techniques (Test Effort Estimation Complete Guide)”

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *