 |
| Альбом: bug |
Обнаружено у А. Селяева, ориджинал контент тут.
Тут не написано, сколько это стоит трудозатрат, это бы серьезно поменяло картину.
Опытные товарищи говорят, что львиная доля приходится на - Personal desk checking of code, да и reviewsстоят недешево.
UPD: Там и дальше интересно:
non-critical bugs are twice as expensive to fix after release, on average. However, the multiplier becomes much, much larger for severe bugs: according to several estimates severe bugs are 100 times more expensive to fix after shipping than they are to fix before shipping.
Ещё бы про эффективность статического анализа услышать.
ОтветитьУдалитьНа картинке Formal code/design inspections
ОтветитьУдалитьЦифры весьма интересные, но еще больше хочется знать какого типа баги находят какой из техник. Очень порадовало соотношение между формальным и неформальным код–ревью.
ОтветитьУдалитьу меня из личного опыта следует, что добросовестный тест, проведённый самим разработчиком, выявляет 99% багов. остальное допиливается в процессе начальной эксплуатации.
ОтветитьУдалитьбОльшая часть проблем выявляется при взаимодействии с другими частями ПО. поэтому гоняем тесты каждый свои, потом - совместные, потом - на прогон тестерам, потом - на отказоустойчивость и далее на сертификации и т.п.
Гг. А помоему опыту тестировщика - добросовестные тесты, выявляющие 99% багов проводят пять - шесть разработчиков в городе. Не чаще раза в месяц.
ОтветитьУдалитьИ да, большая часть проблем на моем опыте - возникает оттого что разрабу не объяснили - а он не понял чего от него хотят. Но мы же не тот админ из анекдота, мы не будем говорить что у нас все пули вылетели.
ОтветитьУдалитьну, это смотря чего разработчик хочет добиться. вот у меня всегда есть доп. требование к трудовому договору: никаких командировок. в принципе. даже на сутки. так что приходится писать такой код, который не свалится где-нибудь в поле. и я это делать умею.
ОтветитьУдалитьу нас есть объекты, где софт на машинах работает круглосуточно. и это не софт верхнего уровня, это управление железом. проблемы в таком софте могут быть крайне неприятны и дорого обойтись. поэтому всё проверяется. по крайней мере, по нашей хардварной части.
а вот насчёт "не объяснили" существует деловая переписка с согласованием ТЗ всеми заинтересованными сторонами.
ОтветитьУдалитьу нас на этапе разработки создаётся куча документов.
ОтветитьУдалитьпри этом я сначала разрабатываю интерфейсы, согласовываю их с программистами, потом пишу доку и только потом начинаю писать код.