Как количество багов влияет на качество программного обеспечения?

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Чтобы правильно обрисовать проблему, я начну издалека.

1. Сколько багов (насекомых) может находиться в шоколадке?
Может показаться, что вопрос глупый, потому что шоколадка должна быть чиста от багов. Ошибочное мнение. FDA декларирует, что в 100 граммах шоколадки может находиться в среднем не более 59 частичек насекомых, когда шесть 100 граммовых шоколадок проверены. 59 — это нормально. 60 — это уже перебор. В принципе на вкус не должно сильно повлиять. Там ещё указывается, сколько волосинок шерсти грызунов может находиться в шоколадке. Среднее значение 1 или более волосинок при проверке шести проб по 100 грамм — это считается нарушением. Если в пяти пробах будет по одной волосинке, а в шестой не будет, то получаем 5/6 = 0.83 — норма.
Можно сравнить с разработкой программного обеспечения. Если вы найдёте лапку таракана в шоколадке, которую с удовольствием кушали, и пожалуетесь производителю, вам могут ответить, что это фича. Всё соответствует высочайшим стандартам написания качественного кода. Могут даже подтвердить, что в шоколадке ещё есть 58 низкоприоритетных багов и одна волосинка крысы, но не критичная. Ешьте на здоровье!
Food Defect Levels Handbook
www.fda.gov/...​od-defect-levels-handbook

2. Сколько багов (насекомых) живёт на планете Земля?
Учёные примерно подсчитали, что одномоментно на планете Земля живёт около 10 квинтиллионов (10,000,000,000,000,000,000) насекомых.
Сколько багов находится в программном обеспечении, никому не известно. Скорее всего их совокупное количество меньше, чем количество насекомых на планет Земля. Есть ещё к чему стремиться. Пока же баги подсчитываются, клиентов информируют только о самых важных. Мелкие по приоритету баги не замечают и стараются не исправлять, так как это экономически невыгодно.
www.si.edu/spotlight/buginfo/bugnos

3. Норма количества мух (багов) в супе?
Мокрая, но живая или мёртвая муха в супе не приветствуется ни одним нормативным актом. Тут можно быть спокойным, если конечно муха не является частью блюда. Нет блюд с мухами, я проверил в Интернете, но есть сыр casu marzu или «гнилой» сыр. В нём водятся личинки сырной мухи, которые этот сыр делают и одновременно являются показателем его свежести. Я не пробовал это изысканное блюдо, но говорят есть можно. Гурманов заранее предупреждают, что во время употребления сыра нужно беречь глаза, так как баги (личинки сырной мухи) способны прыгать на расстояние до 15 сантиметров. Сомнительное удовольствие, конечно, пробовать сыр и уклоняться от выпрыгивающих из него личинок, но всегда можно надеть защитные очки. Помимо этого, употребление сыра в пищу несёт несколько опасностей, одна из которых — это те же самые личинки сырной мухи. Как вы понимаете, они могут быть съедены вместе с сыром. Их устойчивость к желудочному соку и стремление вырваться наружу сквозь стенки желудка — это и есть одна из проблем. Личинки просто бурят себе дорогу к свету и расстраивают клиента отобедавшего сыром. Прямо как баги в новом софте, которые только и ждут хорошего момента, чтобы вырваться наружу и испортить клиенту приятное впечатление от использования программного продукта.
ru.wikipedia.org/wiki/Касу_марцу

4. Какое количество багов в программном обеспечении является нормой?
Конечно же, нет такого справочника, как таблицы Брадиса, в котором можно легко найти норму багов на основании размера фирмы, количества программистов и т.д. Норма багов — сугубо индивидуальное и субъективное понятие. Лучший показатель нормы — это нервная системы клиента. Если клиент уже кричит, брызжет слюной и выпучивает глаза, то это верный знак, что норма багов была превышена и нужно срочно что-то делать, а именно клинап. Это всегда помогает уменьшить накал и пофиксить старые баги, попутно сломав функциональность, которая до этого прекрасно работала. Такой себе задел на будущее. Заодно можно проверить клиента, как он пользуется софтом. Если нужная ему функциональность сломана, а клиент это заметил через пять лет после клинапа, то не так уж и сильно он ей пользуется. И поделом ему. Для успокоения клиента всегда можно выпустить обновление софта с быстрофиксом.

В борьбе с багами IT уникален. Баги в софте можно постараться посчитать, но избавиться от них получится только непрямым воздействием. Желательно обратить пристальное внимание на условия способствующие возникновению бага. Влиять на количество багов не прямым опрыскиванием ядохимикатами, а опосредованным воздействием на сопутствующие факторы. Вот только как определить, что качество софта улучшилось после исправления багов и устранения факторов, влияющих на их возникновение. Существует ли универсальная метрика, которая покажет качество софта до и после улучшения, чтобы можно было понять, в какую сторону идёт улучшение? Желательно иметь метрику, которая не основывается на ложных ощущениях качества, а только на объективных показателях. С шоколадками всё просто шесть волосков — плохо, а пять — норма. С программным обеспечением это не работает. В софте может быть миллион багов неизвестных клиенту, и он будет счастлив, а может быть один супербаг расстраивающий клиента, и клиент расторгнет договор.
Как же измерить объективное качество программного обеспечения?
Для меня это вопрос открытый.
Буду признателен, если кто-то сможет посоветовать что-то дельное.
Заранее спасибо.