28
1 © Luxoft Training 2012 Григорий Сенин Оценка проектов тестирования Трудозатраты, бюджет, сроки код

Оценка проектов тестирования

Embed Size (px)

Citation preview

1 © L

uxoft

Tra

inin

g 2

012

Григорий Сенин

Оценка проектов

тестирования

Трудозатраты, бюджет, сроки

код

2 © L

uxoft

Tra

inin

g 2

012

1969-1977 – МГУ, ВМК, к.ф.-м.н.

1977-1990 – ВЦ АН СССР

1996-2005 – IBS, Luxoft, руководитель отдела подготовки документации, отдела тестирования

2006-2008 – Auriga, CDO

2009-2014 – менеджер/директор по качеству, начальник отдела тестирования (Ritzio Entertainment Group, AnywayAnyday, Luxoft)

C 2011 – Luxoft, тренер

О себе

[email protected]

3 © L

uxoft

Tra

inin

g 2

012

1 Зачем оценивать

2 Просто и грубо – когда это работает

3 Оценка на базе модели процесса

4 Что влияет на оценку, как её защитить

5 Некоторые смежные вопросы (для обсуждения)

Содержание

4 © L

uxoft

Tra

inin

g 2

012

Независимое

testing organization (not unit testing)

Функциональное

black box (not structural testing)

Динамическое

Running software (not Reviews)

Что здесь понимаем под Тестированием

5 © L

uxoft

Tra

inin

g 2

012

Зачем нужна оценка

оценка

Комплектование

команды

Объём проекта

Сроки

проекта

Fixed price

bid Качество

тестирования

Анализ хода

проекта

Улучшение

процесса

Защита бюджета

тестирования

Бюджет

6 © L

uxoft

Tra

inin

g 2

012

Структура затрат на тестирование

ФОТ

«Инженерная» часть -- собственно тестировщики

Управление -- тест-менеджмент

Бонусы/премиальный фонд

Outsourcing -- субподряд

Закупки

Software – инструментарий (лицензии)

Hardware – тест-лаб (аренда и т.д.)

Другое

presale, командировки, найм, обучение, …

7 © L

uxoft

Tra

inin

g 2

012

Самые простые оценки

На 5 разработчиков –

2 тестировщика

или 3

Бюджет тестирования =

15% бюджета разработки

или 40%

Трудозатраты на проект в целом = 800 чел-дней

Доля трудозатрат на тестирование = 18% (статистика)

Суммарные трудозатраты (все работы по тестированию):

800*0,18=144 чел-дня

8 © L

uxoft

Tra

inin

g 2

012

Проекты похожи

Этапы/фазы, относительная длительность

Выполняются одинаково

«процесс»

персонал

Есть статистика

Cбор и анализ результатов

Сохранение истории проектов

Статистика иногда говорит о неустойчивости процесса!

Есть уверенность в базовой оценке

Почему нужно пять разработчиков? А не 8?

Когда работает?

9 © L

uxoft

Tra

inin

g 2

012

Оценка на основе модели

Какой работой и сколько времени будут заняты

участники проекта?

Структурная декомпозиция работ по тестированию

Анализ

Подготовка

Выполнение

Оценка результатов

Объём работы каждого вида

Производительность

Тест-дизайнер

Тестер

Как это

узнать?

10 © L

uxoft

Tra

inin

g 2

012

А что у нас было в прошлом проекте?

Без истории не обойтись…

Сколько тестов в час в среднем

выполняет один тестер?

11 © L

uxoft

Tra

inin

g 2

012

Пример 1. Простейшая модель

Расчёты по разным моделям

12 © L

uxoft

Tra

inin

g 2

012

Пример 2. Приоритеты требований

Расчёты по разным моделям

13 © L

uxoft

Tra

inin

g 2

012

Пример 3. Разные виды требований

Расчёты по разным моделям

14 © L

uxoft

Tra

inin

g 2

012

Пример 4. Прогноз числа дефектов.

Типы тестирования

Расчёты по разным моделям

16 © L

uxoft

Tra

inin

g 2

012

Соотношение «Требования-тесты»

17 © L

uxoft

Tra

inin

g 2

012

О «коэффициентах»

Соотношение требований и тест-сценариев

1 требование = 3,5 теста (Т.Аткинс)

1 требование = 4,5 тест-кейса (Кардосо)

1 бизнес-сценарий = 5 тест-кейсов; 1 бизнес-требование = 8 б.-сц. = 40 тест-

кейсов (Гупта)

Производительность при тест-проектировании

7 тестов/час (Т.Аткинс)

14,5 тест-кейсов/день (Кардосо)

20 тест-кейсов/день (Гупта)

Производительность прогона тестов

12 тестов/час (Т.Аткинс)

10 тест-кейсов/день (Кардосо)

30 тест-кейсов/день (Гупта)

Убойность

0,775 дефекта/тест-кейс (Кардосо)

0, 505 дефекта/тест-кейс (Кейперс-Джонс)

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

25 дефектов/день (Кардосо)

18 © L

uxoft

Tra

inin

g 2

012

Чем объясняется разница коэффициентов

1. Разным объёмом понятий (терминов)

– Требование <–> СИС* <–> бизнес-сценарий

– Тест <-> тестовый сценарий <–> test case

Точно определяйте измеряемые объекты

2. Спецификой организации

– Единого рецепта нет

Собирайте исторические данные

Определяйте «коэффициенты»

своих процессов

* СИС ~ use case

19 © L

uxoft

Tra

inin

g 2

012

Проработанные тесты или только идеи?

Как выглядят идеи тестов

20 © L

uxoft

Tra

inin

g 2

012

Оценка по одному коэффициенту

Требования написаны в виде

функциональных сценариев (use cases)

Из истории проектов известно:

для тестирования одного UC требуется 20

тестеро-часов.

1.Считаем число (приведённых) UCs

2.Умножаем на 20, получаем трудозатраты на

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

21 © L

uxoft

Tra

inin

g 2

012

Расчёт бюджета проекта

22 © L

uxoft

Tra

inin

g 2

012

Оценка затрат на специальные виды

тестирования

Особые виды тестирования

– Автоматизированное функциональное тестирование

– Тестирование производительности/нагрузочное

Своеобразные подпроекты проекта тестирования

– Трудно или невозможно вычислить эти затраты как % от

общих трудозатрат на тестирование

23 © L

uxoft

Tra

inin

g 2

012

Затраты на автоматизацию тестов.

Коэффициенты

Проектирование

= 7 т.сц (в день )

запись скриптов

= 3 (ручная запись)

= 6 (автоматизированная запись)

подготовка тестовых данных

= 4 скрипта

объединение в автоматизир. сценарии

= 3 автом. сц.

отладка скриптов и сценариев (прогон +исправления)

= 2-4 скрипта;

= 2-4 автом.сц.

запуск

= 12 автом. сц. (в день)

Производительность в час

24 © L

uxoft

Tra

inin

g 2

012

Параметры:

модель нагрузки

Производительность по видам работ

Число раундов н.т., напр., 5

Число прогонов каждого скрипта (считая отладочные)

Затраты на нагрузочное тестирование

Модель процесса:

Анализ нагрузочных требований, разработка модели нагрузки

Разработка нагрузочных скриптов

Подготовка тестового стенда, доп оборуд, спец ПО

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

25 © L

uxoft

Tra

inin

g 2

012

«Белые пятна» и факторы оценки

Доступны ли требования?

Ожидания стейкхолдеров? Давление на цифры

Методология разработки?

Известны ли бизнес-критерии успеха проекта?

Кто принимает решение о выпуске?

Вероятность изменений в проекте?

Опыт и квалификация членов группы

тестирования?

Готовность среды и средств тестирования?

Нужны закупки?

26 © L

uxoft

Tra

inin

g 2

012

Допущения

– условия, без которых оценка

недействительна

– напр., не более двух раундов тестирования

Поправки на риск

–в оценку вносится поправка,

учитывающая эффект нежелательного

события

– напр., буфер в 15% на изменения в

требованиях

(указываются в ТКП)

Как «спасти» оценку

27 © L

uxoft

Tra

inin

g 2

012

Несколько замечаний

28 © L

uxoft

Tra

inin

g 2

012

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

«Нам такое высокое качество не нужно!» (за эти деньги)

Когда завершать тестирование

Что важно: Много дефектов найдено или «мало не найдено»?

Оценка и качество тестирования

«Если умеючи, то дольше…». Убойность тестов

DRE

Статистическая устойчивость процесса достижима?

Тестирование и рецензирование

Может ли хорошее рецензирование «урезать» оценку?

Тест-менеджер или менеджер качества

Роль рисков. Продуктовые и проектные риски

Правильно ли потрачен бюджет тестирования

Оценка и смежные вопросы

29 © L

uxoft

Tra

inin

g 2

012

Обсудим?