Получил три вопроса про метрику «количество багов на фичу»/ которая упомянута в самом низу моей простыни-тысячеслова «про смысел тестирования«:
параметры качества и дефектов
В частности:
- в какой книге я прочитал про этот метод?
- где я взял эту диаграмму?
- как я применяю эту метрику в проектном быту?
Мгм…
В какой книге прочитал про этот метод?
Шоб я знал…
Это одна из старейших форм попытки формального оценки качества ПО, и я подразумеваю, что до нее может додуматься любой работник отрасли.
В целом я эту форму архи НЕ одобряю. Она слишком формальна, и преисполнена недостаков:
- не все дефекты связаны с определенной функцией, как это хотелось бы отобразить на диаграмме. Бывают дефекты «на стыке», или связанные с несколькими функциями одновременно. Такие баги на такой диаграмме не отобразить.
- диаграмма не отображает важность багов. Просто вот для фичи №17 найдено 4 бага. И что? Насколько они влияют на функционал, а следовательно, и на качество всего проекта? Если попытаться на диаграмме отобразить не количество багов на функцию, а просто указывать «вот для этой функции были найдены баги«, это будет смотреться круто, но не более. Степень удовлетворенности или неудовлетворенности она не отобразит.
- в информации с подобной диаграммы не очень много смысла в проектной работе. Смысл ведь в том, чтобы предоставить адекватно работающую систему, чтобы все было «по нулям» или выше нуля, а не в том, чтобы ПОКАЗАТЬ, что где-то есть дефекты.
Где взял эту диаграмму?
Открыл «Excel 2003», в столбике проставил циферки, выделил сектор с циферками, нажал на иконку «Создать новую диаграмму»…
Я сделал ее для того, чтобы более внятно объяснить свое видение в определенный момент, не более.
Как применять эту метрику в проектном быту?
Ну, как…
Рисуем диаграмму, вешаем на стену, подводим к стене тех, кто ответственен за разработку функции, собравшей наибольшее количество багов, и расстреливаем.
Или предлагаем каждому написать на ней «Я больше не буду делать баги!«, но ей-богу, я бы выбрал в этой ситуации расстрел автора подобной диаграммы 🙂
1. Проблема багов на стыковках решаема: если бага влияет на обе фичи, надо учитывать в обоих. Тем более что в таком случае значительно упрощается автоматизация рисования диаграмки.
2. Использовать её можно и для понимания, готовы ли мы к релизу. Добавляем помимо количество ещё и северити багов, умножаем на коэффициент и получаем «цифровую оценку бажности фичи». А потом подводим РМа к диаграмме и говорим ему:
— Почему нельзя релизиться (или, если возможно, какие фичи отключить в релизе)
— На каких областях ему надо концентрировать внимание, ресурсы и прочая-прочая