255 ступеней

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

Ограничения задачи

Иногда считают, что на тестирование уходит до 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 вместо аналитиков, программистов и технических писателей посадить разработчика, разработчика и разработчика (не путать с программистом), то во первх проект был бы сделан быстрее, во вторых трудозатраты бы снизились (примерно в два-три раза). Все таки этот проект маленький и на нем кросфункциональные спецы лучше чем узкоспециализированные. К сожалению, на нашем рынке разработчики не востребованы и потому встречаются не так уж часто. Но встречаются.

Это сообщение создано Четверг, Ноябрь 12, 2009 в 20:53 в категорию Всё новое. Вы можете подписаться на сообщения RSS 2.0 Вы можете оставить комментарий или послать trackback на это сообщение.