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

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

Как правильно оценивать время на тестирование?

  • Что такое оценка?
  • Для чего нужна оценка?
  • Из чего состоит оценка?
  • Ошибки при составлении оценки
  • Какие риски могут выбить из оценки и как управлять временем, если все сроки сорваны?

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

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

Оценка время - один из трех показателей, влияющих на качество выпускаемого продукта
Оценка время — один из трех показателей, влияющих на качество выпускаемого продукта

Оценка времени на тестирование состоит из различных аспектов, таких как:

  • определение приоритетов
  • определение объема задач
  • расчет времени на написание тестовой документации
  • расчет времени на прохождение тест-кейсов, чек-листов
  • расчет времени на оформление и локализацию дефектов с повторным ре-тестом после исправлений
  • дополнительные расчеты времени на совещания, анализ требований, сбор информации, получение ответов на вопросы
  • закладывание процента времени от общей оценки на риски
                                                   Жизненный цикл тестирования на проекте
Жизненный цикл тестирования на проекте

Если с 1-6 пунктов все более-менее прозрачно, то с риски — это отдельная проблема, требующая индивидуального анализа на каждом проекте.

Важно понимать специфику проекта и учитывать риски, которые могут сработать.

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

                                                           Абстрактный пример матрицы рисков
Абстрактный пример матрицы рисков

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

Менеджеров в команде интересуют сроки поставки готового функционала на продуктивный стенд (заказчику).

Какие перекосы по оценке времени могут быть в команде:

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

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

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

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

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

  • позадачная оценка
  • оценка на smoke-тестирование
  • оценка на регресс
  • оценка End-To-End-тестирования
  • оценка на регрессионное тестирование и т.д.

Примеры оценок по видам тестирования:

  • позадачная оценка состоит из
  • 2-4 часа на написание тестовой документации
  • 1-4 часа на тестирование “простой” задачи, 4-8 часов на тестирование “сложной” задачи, 1-2 раб.дня на тестирование “сверхсложной” задачи. Более 2 раб.дней может занимать сложное тестирование объемной задачи
  • Smoke-оценка: не более 2-4 часов на тест.стенде, не более 1 часа на продуктивном стенде
  • Регрессионное тестирование 1-5 раб.дней на полное покрытие тестами всей системы
  • End-To-End — тестирование 1-2 раб.дня

Какую пользу приносит проекту оценка по тестированию:

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

Важно также понимать, что оценка не обязательно может выражаться в часах или раб.днях. Например, в методологии разработки Scrum применяется оценка в story-point с планнинг покером.

2.5 2 votes
Article Rating
Подписаться
Уведомление о
guest
0 Комментарий
Inline Feedbacks
View all comments