Где придумал? Как взял?

Получил три вопроса про метрику «количество багов на фичу»/ которая упомянута в самом низу моей простыни-тысячеслова «про смысел тестирования«:

параметры качества и дефектов

В частности:

  1. в какой книге я прочитал про этот метод?
  2. где я взял эту диаграмму?
  3. как я применяю эту метрику в проектном быту?

Мгм…

В какой книге прочитал про этот метод?

Шоб я знал…

Это одна из старейших форм попытки формального оценки качества ПО, и я подразумеваю, что до нее может додуматься любой работник отрасли.

В целом я эту форму архи НЕ одобряю. Она слишком формальна, и преисполнена недостаков:

  1. не все дефекты связаны с определенной функцией, как это хотелось бы отобразить на диаграмме. Бывают дефекты «на стыке», или связанные с несколькими функциями одновременно. Такие баги на такой диаграмме не отобразить.
  2. диаграмма не отображает важность багов. Просто вот для фичи №17 найдено 4 бага. И что? Насколько они влияют на функционал, а следовательно, и на качество всего проекта? Если попытаться на диаграмме отобразить не количество багов на функцию, а просто указывать «вот для этой функции были найдены баги«, это будет смотреться круто, но не более. Степень удовлетворенности или неудовлетворенности она не отобразит.
  3. в информации с подобной диаграммы не очень много смысла в проектной работе. Смысл ведь в том, чтобы предоставить адекватно работающую систему, чтобы все было «по нулям» или выше нуля, а не в том, чтобы ПОКАЗАТЬ, что где-то есть дефекты.

Где взял эту диаграмму?

Открыл «Excel 2003», в столбике проставил циферки, выделил сектор с циферками, нажал на иконку «Создать новую диаграмму»…

Я сделал ее для того, чтобы более внятно объяснить свое видение в определенный момент, не более.

Как применять эту метрику в проектном быту?

Ну, как…

Рисуем диаграмму, вешаем на стену, подводим к стене тех, кто ответственен за разработку функции, собравшей наибольшее количество багов, и расстреливаем.

Или предлагаем каждому написать на ней «Я больше не буду делать баги!«, но ей-богу, я бы выбрал в этой ситуации расстрел автора подобной диаграммы 🙂

Один ответ на “Где придумал? Как взял?”

  1. 1. Проблема багов на стыковках решаема: если бага влияет на обе фичи, надо учитывать в обоих. Тем более что в таком случае значительно упрощается автоматизация рисования диаграмки.
    2. Использовать её можно и для понимания, готовы ли мы к релизу. Добавляем помимо количество ещё и северити багов, умножаем на коэффициент и получаем «цифровую оценку бажности фичи». А потом подводим РМа к диаграмме и говорим ему:
    — Почему нельзя релизиться (или, если возможно, какие фичи отключить в релизе)
    — На каких областях ему надо концентрировать внимание, ресурсы и прочая-прочая

Добавить комментарий