Трудозатраты на тестирование
Эту статью я начал писать, когда мне предложили принять участие в опросе про соотношение программистов и тестировщиков. Я решил дождаться результатов и стелать развернутый анализ.
Ограничения задачи
Иногда считают, что на тестирование уходит до 40% времени проекта. При этом не совсем понятно, что имеют в виду под тестированием. Человекочасы присутствия тестировщиков и кодировщиков на работе? Тогда 40% - это очень, очень много. Виды деятельности, которыми занимаются инженеры? А отладку будем относить к тестированию? А создание тестовых сценариев?
Давайте возьмем для простоты только те группы разработки, где есть четкое ролевое разделение:
* аналитики
* архитекторы-кодеры (программисты)
* техписы
* дизайнеры GUI
* тестировщики
* много кто еще
Отнесем к затратам на тестирование все виды работ, которые выполняет отдел тестирования, а к затратам на программирование все виды работ, выполняемые отделом программирования.
Общетеоретическая часть.
Для начала рассмотрим только соотношение численности программистов и тестировщиков.
у нас есть два основных параметра, определяющих этот коэффициент:
1) критичность (сумма потерь от ошибок)
2) сложность системы
Критичность можно взять по Коберну:
1) человеческие жертвы
2) невосполнимые деньги
3) инвестиционные деньги
4) неудобство
Потери денег нужно считать вместе с дистрибуцией и ударом по репутации.
* Так ошибка в коробочном продукте бьет гораздо больнее, нежели если софт находится в своей сети. Поэтому при равной сложности и размере продукта у Яндекса и Ниваль, Яндекс может позволить себе меньше тестировщиков.
* Удар по репутации зависит от развития рынка. На заре поисковых систем, [сами знаете какая фирма] могла позволить себе выпускать откровенное фуфло (смотри “жизнь в пузыре” Ашманова). На сложившемся, но не монополизированном рынке такие фортеля уже небезопасны.
Попробуем построить шкалу.
Для некритичных (4), несложных крохотулечных систем (до 1 человекомесяца, смотри http://blog.shumoos.com/archives/81) нормальное соотношение 100:0. И именно поэтому сайты-визитки делаются без тестировщика (как правило).
На другом конце шкалы находятся продукты НАСА (1 уровень критичности). По слухам, у них тестировщиков в 5-10 раз больше, чем кодировщиков. А учитывая уровень документирования, полагаю, что кодировщиков на проекте едва ли 5%.
Опять же по слухам, в Микрософте на одного программиста два тестировщика.
Для коробочной системы какой-нибудь автоматизации среднего размера (20-50 человеколет) хорошим соотношением будет от 4:1 до 3:2 (в человекомесяцах)
Всякие разные нюансы.
Плюс к этому куча разных нюансов. Например, какой тип софта? Или как назвать роль создателя юнит тестов для компилятора командной строки? Другого тестирования там нет, но кто это? Программист или тестировщик? А если тестировщик, то почему он С++ знает гораздо лучше подавляющего большинства ведущих программистов в других фирмах? А кто выполняет роли аналитика, техписа (они выделены или нет)? Будучи формально тестировщиком, я писал и/или верифицировал стандарты кодирования, проектирования интерфейса, писал проектную документацию (концепцию, SRS, словарь проектной области). И куда отнести эти виды работ?
Неправильная интерпретация.
Предположим, что в октябре 2009 года на проекте SuperSMS тестировщики отработали 400 часов, а программисты 600. Из этого иногда делают вывод, что трудозатраты на тестирование составлят 40%. Этот вывод глубоко ошибочен.
Пусть этот проект длился с июля по октябрь. Трудозатраты на проект составили в разбивке по месяцам июль/август/сентябрь/октябрь:
- Управление - 200/200/200/200
- Инфраструктурные работы (эникейщики) 100/20/20/10
- Постановка процессов, стандарты и прочее (отдел QA) 100/0/0/50
- Анлиз 400/200/100/0
- Дизайн и верстка (отдел дизайна) 300/100/50/50
- Программирование 600/600/600/600
- Тестирование 50/50/400/400
- Создание пользовательской документации 0/0/200/200
И в такой раскладке, когда мы учли работу всех отделов, трудозатраты на тестирование стали несколько меньше. А ведь есть еще работы, предшествующие запуску проекта, и это очень немаленький процент. Но даже если их не учитывать, получается:
Тестирование: 900/(800+150+150+700+500+2400+900+400) * 100% = 15%
Программирование: 2400/6000 * 100% = 40%
И это разумный результат, хорошо согласующийся с наблюдениями.
Что еще полезно знать при планировании трудозатрат.
Пусть вышеприведенные цифры - это истинные потребности. Если бы мы жили в вымышленном мире RUP-а или PMBOK-а, то имело бы смысл закладывать именно такой бюджет. Однако, как говорил Морфеус: “Добро пожаловать в реальный мир”. В реальном мире случаются девиации (отклонения). Кто-то может заболеть. Или решаемая задача окажется проще, чем оценивали изначально.
В реальном мире рекомендуют сделать ограничением самый дорогой участок, добавив остальным участкам запас мощности (еще можно заложить буфера, но тогда проект вместо 4 месяцев будет длиться 2-3 года). В нашем случае это отдел программирования. А вот остальным отделам нужно запланировать бюджет побольше. Точная цифра зависит от величины девиаций, от стоимости задержки проекта и от относительной стоимости каждого отдела. Для самых дешевых участков нужен наибольший запас мощности. Предположим, что правильный запас мощности 30% для всех отделов, кроме программирования.
В этом случае получаем:
Тестирование: 1170/(1040+ 195+195+910+650+2400+1170+520) * 100% = 16,5%
Программирование: 33,9%
PS.
Что любопытно. На деловой игре по управлению регулярно наблюдаю, как люди пытаются сделать бутылочным горлышком самый дешевый отдел. Естественно это приводит к огромным финансовым потерям. Но объяснить причину феномена я пока не готов.
Еще момент. если бы на проект SuperSMS вместо аналитиков, программистов и технических писателей посадить разработчика, разработчика и разработчика (не путать с программистом), то во первх проект был бы сделан быстрее, во вторых трудозатраты бы снизились (примерно в два-три раза). Все таки этот проект маленький и на нем кросфункциональные спецы лучше чем узкоспециализированные. К сожалению, на нашем рынке разработчики не востребованы и потому встречаются не так уж часто. Но встречаются.