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

С очень хорошим и сильным докладом на конференции SQA Days-15 выступила Александа Ковалева – “Планирование трудозатрат на тестирование”. Саша, как и на прошлых свои выступлениях,  была воодушевляюща, мила, открыта, профессиональна! Восторгаюсь ей. Всё очень по делу.

Как и ранее, я транслирую конспект доклада, совмещенный с моим пониманием этой темы и моими дополнениям.

Планирование тестирования – это целый комплекс работ, состоит из следующих этапов:

1. Определение требований к тестам
2. Оценка продуктовых и проектных рисков
3. Разработка плана тестирования:
   1. Разработка стратегии тестирования
   2. Определение ресурсов
   3. Проработка конкретных задач по тестированию
4. Оценка трудозатрат на каждую из работ
5. Создание графика работ с распределением ресурсов
6. Мониторинг и сравнение результатов работы и на соответствие плану и графику. Перепланирование по необходимости.

Часто и мы сами и наши коллеги отвергаем вообще просьбы о том, что нужно оценить задачу, и подвергаемся  стрессу. По сути, причины чаще всего в том, что мы не знаем методов оценки, в том, что не понимаем что конкретно нужно оценивать и в том, что просто боимся совершить ошибку.  Это всё наши естественные психологические защиты. И решение заключается в том, чтобы заставить себя выйти из этой зоны комфорта – “работы без оценок”.

Изучите существующие методы оценки трудозатрат (дальше в статье описано несколько вариантов). И не стесняйтесь, если вы не поняли каких-то сложных математических методов. Использовать метод, основанный на собственной интуиции (по сути на прошлом опыте) – прекрасный, и рабочий вариант. Но для этого необходимо развить в себе интуицию. А развить её можно постоянно оценивая все задачи, которые вам поступают, и сравнивая в конце начальную оценку с реально затраченным временем (что мы упустили при начальной оценке, куда ушло время, почему переоценили).

Нужно заставить себя вести хронометраж. (offtopic: на конференции также был доклад от Андрея Ладутько про время, самомотивацию, а также и предложено несколько инструментов хронометража. Уже есть его видеоверсия.)

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

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

Чтобы не упустить что-то важное при оценке проекта, можно и себе распечатать, и ребятам-тестировщикам раздать, подобные списки-“незабудки” о том, что нужно вложить в оценку:

1. Ознакомление/исследование
2. Ревизия спецификации
3. Написание тестовой документации (чек-лист, тест кейсы)
4. Подготовка данных
5. Подготовка тестового окружения6.       Выполнение тестов (и не только тех, что придумываем сами, программисты могут много полезных идей подсказать).
6. Регистрация багов и проверка их исправления.
7. Буфер/риски.

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

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

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

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

1. Метод Дельфи;
2. Метод трех точек, когда дается оптимистичная (a), пессимистичная (b) и наиболее вероятная оценка (m). Итоговая оценка считается как Е = )а + (4*m) + b) / 6.;
3. Метод анализа функциональных точек /точек тестирования;
4. Метод оценки точек вариантов использования
5. COCOMO (COnstructive COst MOdel) – модель издержек;

Более простые в использовании методы:

1. ПВН (пальцем в небо), или метод проб и ошибок, он же метод научного тыка;
2. “Специальный” метод, когда оценка приходит сверху (от менеджеров, руководителей, маркетологов) без настоящих попыток оценить трудозатраты;
3. Аналогии с другими проектами и рекомендации экспертов (экспертные оценки довольно понятно описаны на wiki и вот этой страничке);
4. Оценка через декомпозицию работ (декомпозируем до тех пор, пока не сможем оценить);
5. Процентное отношение к разработке (исходя из предыдущего опыта высчитывается какой процент от разработки занимает тестирование и в прогнозировании будущих проектов используется этот процент);
6. Метод процентного распределения (все этапы жизненного цикла разработки программного продукта делятся на части, которым присваивается значение трудозатрат в %.).

Но оценкой всё не заканчивается.

Следующий наш шаг – это разработка графика работ.

Здесь Саша напоминает о критическом пути (читайте Элияху Голдтатта “Цель” ): задач может быть очень много, некоторые из них можно выполнять параллельно, но существует  набор задач, которые должны выполняться последовательно. И как ни крути, вы не завершите проект раньше, чем закончится эта последовательность задач на критическом пути.

«Девять женщин не выносят ребенка за 1 месяц.»

Народная мудрость.

Рекомендуемые шаги составления плана работ:

1. Решить, что будем тестировать
2. Сделать оценки
3. Заполнить сетевой график работ, построить диаграмму Ганта.
4. Проставить логические связи между работами
5. Назначить ресурсы
6. Определить критический путь
7. Проставить ресурсные связи
8. Оптимизировать ресурсы (количество исполнителей).

Как создать план работ в MS Project Саша показала в своем демо-примере. Так что желающие, смотрите видео версию, как только она появится. А в целом, доклад очень мотивирующий и его, мне кажется, будет интересно посмотреть в любом случае.

И не забывайте, что в плане нужно учесть:

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

Однако и наличие графика не даёт 100% гарантии того, что он рабочий. Как только началась работа, требуется постоянно проводить мониторинг и контроль:

• а вкладываемся ли мы в оценку?
• всё ли идет так как запланировано?
• если что-то пошло не так, то как оптимизировать?
• вкладываемся ли мы в сроки?

Существует прекрасный доклад Наташи Руколь о планировании тестирования как ежедневной активности. Я его рекомендую смотреть не только тем, кто занимается или планирует этой задачей заниматься, а всем тем, кто хочет развиваться личностно и профессионально.

Видеоверсию доклада Александры можно будет найти на сайте конференции.