понедельник, 24 октября 2011 г.

Процент багов найденных различными техниками.

Проценты багов найденных различными техниками.
Альбом: 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.

9 комментариев:

  1. Ещё бы про эффективность статического анализа услышать.

    ОтветитьУдалить
  2. На картинке Formal code/design inspections

    ОтветитьУдалить
  3. Цифры весьма интересные, но еще больше хочется знать какого типа баги находят какой из техник. Очень порадовало соотношение между формальным и неформальным код–ревью.

    ОтветитьУдалить
  4. у меня из личного опыта следует, что добросовестный тест, проведённый самим разработчиком, выявляет 99% багов. остальное допиливается в процессе начальной эксплуатации.
    бОльшая часть проблем выявляется при взаимодействии с другими частями ПО. поэтому гоняем тесты каждый свои, потом - совместные, потом - на прогон тестерам, потом - на отказоустойчивость и далее на сертификации и т.п.

    ОтветитьУдалить
  5. Гг. А помоему опыту тестировщика - добросовестные тесты, выявляющие 99% багов проводят пять - шесть разработчиков в городе. Не чаще раза в месяц.

    ОтветитьУдалить
  6. И да, большая часть проблем на моем опыте - возникает оттого что разрабу не объяснили - а он не понял чего от него хотят. Но мы же не тот админ из анекдота, мы не будем говорить что у нас все пули вылетели.

    ОтветитьУдалить
  7. ну, это смотря чего разработчик хочет добиться. вот у меня всегда есть доп. требование к трудовому договору: никаких командировок. в принципе. даже на сутки. так что приходится писать такой код, который не свалится где-нибудь в поле. и я это делать умею.
    у нас есть объекты, где софт на машинах работает круглосуточно. и это не софт верхнего уровня, это управление железом. проблемы в таком софте могут быть крайне неприятны и дорого обойтись. поэтому всё проверяется. по крайней мере, по нашей хардварной части.

    ОтветитьУдалить
  8. а вот насчёт "не объяснили" существует деловая переписка с согласованием ТЗ всеми заинтересованными сторонами.

    ОтветитьУдалить
  9. у нас на этапе разработки создаётся куча документов.
    при этом я сначала разрабатываю интерфейсы, согласовываю их с программистами, потом пишу доку и только потом начинаю писать код.

    ОтветитьУдалить