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

Автор: | 18.07.2011

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

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

В частности:

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

Мгм…

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

Шоб я знал…

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

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

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

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

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

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

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

Ну, как…

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

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

Где придумал? Как взял?: 1 комментарий

  1. Natalya Rukol

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

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

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.