У меня в компании была другая система мотивации сотрудников. Премиальный фонд состоял 15% зарплатного фонда. В случае нормального хода работ работник просто получал эти 15% в дополнении к авансу. В случае допущенных косяков, внеочередных отгулов или болезней, эти 15% начислялись в качестве премии тем, кто выполнял работу за этого работника или исправлял его ошибки. Могу как-нибудь написать об этом подробнее, как это было, какие были правила и к чему это всё привело.
Попробуй посчитать вероятность возникновения ошибки по другому: у тебя в программном модуле есть N методом и в каждом из них ты можешь сделать ошибку с вероятностью, пропорциональной количеству строчек кода, реализующих бизнес-логику. Вероятность допустить ошибку является композицией от вероятностей сделать ошибку в этих N методах. В случае TDD ты пишешь N тестов, чтобы покрыть функциональность методов (при правильном применении ТДД количество тестов будет соответствовать количеству методов, при неправильном — количество тестов будет больше, чем количество методов). Соответственно, вероятность возникновения ошибок в тестах считается так же. Так-как функциональность методов пишется после создания тестов, то вероятность возникновения первичной ошибки в тестах считается первичной, то при возникновении ошибки в тесте реализация уже будет неправильной. По этому вероятность ошибки реализации программы в целом будет считаться как сумма вероятностей от ошибки в тесте и одновременной ошибки и в тесте и в реализации.
Соответственно, при увеличении строк кода в тесте и увеличении N вероятность ошибки увеличивается. Откуда были получены эти «в разы» мне, лично, непонятно.
Функционал проверяется тестировщиком, который вначале с продактом пишет/уточняет тест-план, а потом составляет список регресс-тестов.
Время на прохождение тестов и правку багов обычно соотносится как 2 к 1 по отношению к времени разработки. Увеличение до 7 к 3 является поводом для тотального код-ревью.
Сильно зависит от скорости мутации требований. Обычно на обсуждение функционала выделяется по 1-1,5 часа два раза в неделю при эффективном рабочем времени в 30 рабочих часов в неделю.
Много деталей специально опущено, чтобы напомнить главное и побыстрее перейти к практике :)
java -Xms1024m -Xmx1024m -cp ./;./jai_core.jar;./jai_codec.jar;./clibwrapper_jiio.jar;./mlibwrapper_jai.jar;./jai_imageio.jar;./map_cutter.jar ru.ak.tools.MapCutter 17498 18520 17498 18520 0 0 214 214 outimg source/cheb24576x24576.png
pause 0
Этого вполне достаточно, чтобы его взяли на работу. Как плюс — это отсутствие неправильных паттернов программирования.
Соответственно, при увеличении строк кода в тесте и увеличении N вероятность ошибки увеличивается. Откуда были получены эти «в разы» мне, лично, непонятно.
Время на прохождение тестов и правку багов обычно соотносится как 2 к 1 по отношению к времени разработки. Увеличение до 7 к 3 является поводом для тотального код-ревью.