Тестирование ПО

Алгоритм оценки времени на тестирование

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

Предлагаю следующий алгоритм для оценки трудозатрат на тестирование ПО:

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

2. Определить среднее время на разработку и выполнение 1 теста

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

4. Учесть возможные дополнительные затраты времени и риски

5. Получить суммарную оценку, с учетом предыдущих шагов

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

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

а) Должны суммироваться 2 числа от 0 до 100

б) Для сложения между числами необходимо ввести знак «+»

в) Результат сложения должен отображаться под строкой ввода после нажатия «Calculate»

г) При некорректном вводе и попытке вычисления, под строкой ввода должно появляться сообщение «Ошибка вычисления»

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

Проведем оценку времени на тестирования для нашего примера:

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

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

Что проверяем? Тесты Количество тестов
Ввод корректных значений в строку ввода и проверка итоговой суммы - ожидаем правильный результат Вводим в строку 0+100, ожидаем 100 1
Вводим в строку 10+0, ожидаем 10 1
Вводим в строку 4+5, ожидаем 9 1
Вводим новые значения после предыдущего вычисления 66+66, ожидаем 132 1
При вводе чисел используем "backspace" и продолжаем ввод, ожидаем правильный результат 2
Вычисление минимальной и максимальной итоговой суммы - ожидаем правильный результат Вводим в строку 0+0, ожидаем 0 1
Вводим в строку 100+100, ожидаем 200 1
Варианты ввода разделителя между числами - ожидаем правильный результат Вводим в строку 1+2, ожидаем 3 1
Вводим в строку 10 + 20, ожидаем 30 1
Вводим в строку 15+ 25, ожидаем 40 1
Варианты ввода разделителя между числами - ожидаем ошибку Вводим числа без +, используем подряд более 1 пробела 3
Варианты ввода некорректных символов - ожидаем ошибку При вводе чисел используем символы "" , . / a и т.д. 5
Ввод некорректных значений в строку ввода и проверка итоговой суммы - ожидаем ошибку Вводим в строку -1+100, ожидаем ошибку 1
Вводим в строку 100, ожидаем ошибку 1
Вводим в строку 1+101, ожидаем ошибку 1
Работу кнопки "Calculate" Нажимаем "Calculate" при пустой строке ввода, ожидаем ошибку 1
Нажимаем "Calculate" 2 раза после ввода корректных значений, результат не меняется 1
  Всего тестов:   24

2. Определить среднее время на разработку и выполнение 1 теста

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

а) Описать тест-кейс (как описать тест-кейс можно посмотреть тут - Шаблон тестового кейса)

б) Выполнить проверку по тест-кейсу

  • Для оценки времени на разработку тест-кейса проще всего попробовать описать 1 из них или провести этот эксперимент мысленно. Допустим мы знаем, что в каждом тест-кейсе у нас примерно равное количество шагов (в среднем 3-5) а остальные части одинаковые по структуре. Тогда, если на описание 1 тест-кейса уйдет, например, 20 минут (учитываем время на уточнение требований, вопросы), то далее мы можем умножить это значение на количество тестов: 20х24=480 мин.
  • Подход к оценке времени на выполнение проверки по тест-кейсу точно такой же: оцениваем время на выполнение 1 шага (например, 3 минуты), берем среднее количество шагов в тесте (например, 5), учитываем время на подготовку данных и среды тестирования (5 минут), итого (3х5+5)=20 минут на тест-кейс. Далее умножаем это время на количество тестов, получаем: 20х24=480 минут на 1 полный прогон всех тестов.

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

На этом этапе нам необходимо спрогнозировать:

а) С каким примерно количеством ошибок мы можем столкнуться

б) Сколько времени необходимо на регистрацию дефекта

в) Сколько времени уйдет на проверку исправлений

  • Сначала разберемся с количеством возможных ошибок. Конечно же количество ошибок может зависеть от множества факторов: сложность системы и архитектуры, квалификация разработчиков, четкость требований, фаза проекта и т.п. Опираясь на все эти знания и факторы нужно ответить на вопрос: «на какое количество тестов\проверок в среднем будет приходиться одна ошибка?». Если знания о системе дополнительных уточнений не дает, то нужно сделать предположение. Допустим, мы будем находить ошибку на каждом пятом тесте или, другими словами, 20% проверок позволят выявить ошибки в тестируемом ПО. В этом случае мы получаем 24/5=4,8, округлим до 5 дефектов.
  • Время для описания и регистрации 1 дефекта фактически можно приравнять к оформлению 1 тест-кейса (аналогичные атрибуты, данные, шаги). Поэтому считаем, что на заведение 5 дефектов нам необходимо: 5х20=100 минут (как оформляется дефект можно посмотреть тут - Шаблон типового дефекта).
  • При работе с ошибками мы тратим время не только на оформление дефекта, но и на выполнение проверки, после его исправления. При этом не всегда все дефекты исправляются с первого раза, поэтому иногда будут необходимо несколько итераций перепроверки. Чтобы оценить количество ретестов можно либо базироваться на опыте или использовать более или менее стандартную пропорцию: 50% «исправленных» ошибок не проходят перепроверку и их исправляют снова, из них опять 50% не проходят перепроверку и т.д. Получается, что в этом случае мы выполним в 2 раза больше проверок исправления, чем зарегистрировано дефектов. На 1 проверку исправленной ошибки, необходимо столько же времени как и на выполнение тест-кейса. Поэтому для 5 дефектов мы получаем 5х2х20=200 минут на проверки и перепроверки исправленных дефектов.

4. Учесть возможные дополнительные затраты времени и риски

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

  • Подготовка среды тестирования Частично мы учли время на подготовку данных и среды в выполнении тест-кейса, а здесь речь идет, например, о настройке интеграционной схемы.  
  • Взаимодействие с внешними командами
  • Уточнение требований, вопросы к аналитикам\разработчикам. Частично мы уже заложили время в подготовке тест-кейса и в регистрации дефекта, но может потребоваться более глубокий анализ задач
  • Изменение ТЗ\FSD\спецификации
  • Подготовка и установка сборок\билдов
  • Обновление тест-кейсов

Допустим, что для нашего примера мы заложили следующее дополнительное время:

  • По 3 минуты на ревью каждого тест-кейса (предположим, что наш процесс подразумевает, что каждый тест-кейс проходит ревью у аналитиков)

Итого, получаем дополнительно 24*3=72 минуты

5. Получить суммарную оценку, с учетом предыдущих шагов

Итак, теперь посмотрим, какие оценки у нас получились на каждом шаге:

  • Подготовка 24 тест-кейсов: 480 минут
  • Однократное выполнение 24 тест-кейсов: 480 минут. Закладываем минимум 4 итерации полного тестирования на выполнение функциональных, регрессионных и интеграционных проверок (см. схему Этапы и участники процесса тестирования). В итоге, общее время на тестирование (4 раза выполняем весь скоп проверок): 480х4=1920 минут
  • Оформление дефектов (предполагаем, что их будет 5): 100 минут
  • Ретест после исправления дефектов: 200 минут
  • Дополнительное время и риски: 72 минуты

В сумме получается: 480+1920+100+200+72=2772 минуты или 46 часов. При этом к общей сумме уже можно не прибавлять какие-то дополнительные риски, т.к. мы их учли на отдельных шагах.

Вот так на проработку простейшего функционала запланирована целая рабочая неделя! Хотя на первый взгляд и может показаться, что работы там максимум на 1 час. Но когда мы приступим к реальной задаче, начнем прорабатывать требования, оформлять тест-кейсы и дефекты, станет очевидно, что оценка в 46 часов гораздо ближе к действительности.

 

О проекте

  • Проведение тренингов и вебинаров: QA, Time management, People management, Agile
  • Консалтинг в области организации рабочих процессов в ИТ
  • Проведение и подготовка к собеседованиям

Информация об авторе проекта

 

Контакты

Skype: xpavnov

E-mail: xpavnov@gmail.com

VK: https://vk.com/doitsmartly

Группа вконтакте

doITsmartly©2024
Яндекс.Метрика

Search