Comments 16
Имхо
если уж наводим метрики, то начинаться все должно с требований. Формальные требования ( внешние, от заказчика ) должны быть пройти оценку QA и расширены до полных, внутренних.
По требованиям создаются тесты, которые оцениваются как по покрытию требований, так и по покрытию кода. Понятно что покрытие должно быть полным.
Соотношение успешно пройденных полных тестов и даст нам искомое качество.
Упомянутые сценарии есть use cases, которые в какой-то мере относятся к требованиям.
Severity, присваиваемые багам, должны в первую очередь отражать важность их устранения. Наличие critical и major в успешно используемом продукте показывает что критерии для установки severity не соответствуют действительности.
если уж наводим метрики, то начинаться все должно с требований. Формальные требования ( внешние, от заказчика ) должны быть пройти оценку QA и расширены до полных, внутренних.
По требованиям создаются тесты, которые оцениваются как по покрытию требований, так и по покрытию кода. Понятно что покрытие должно быть полным.
Соотношение успешно пройденных полных тестов и даст нам искомое качество.
Упомянутые сценарии есть use cases, которые в какой-то мере относятся к требованиям.
Severity, присваиваемые багам, должны в первую очередь отражать важность их устранения. Наличие critical и major в успешно используемом продукте показывает что критерии для установки severity не соответствуют действительности.
Вообще все это похоже не на то что называется «оценка качества ПО», самостоятельная дисциплина смежная с метрологией и стандартизацией, а на оценку только лишь одной составляющей — ошибок (дефектов). Оценка качества преподносится обычно значительно шире и включает всё от реализации до документации и поддержки.
Как то размыто ваша формула указана
Идея веса для сценариев использования очень интересная.
Но часто натыкается на пользовательское недовольство, ибо клиент который приобрел продукт для использования по редкому не стандартному сценарию будет почти в любом случае недоволен, и объяснить что он некорректно использует продукт часто бывает довольно сложной задачей. Ошибка есть — продукт не качественный. Соотвественно имидж продукта падает.
Мы кстати оцениваем качество продукта только на основании учета ошибок поступивших от клиентов, а внутренние ошибки обнаруженные внутри компании не учитываются, если конечно до их устранения их не обнаружат клиенты.
Но часто натыкается на пользовательское недовольство, ибо клиент который приобрел продукт для использования по редкому не стандартному сценарию будет почти в любом случае недоволен, и объяснить что он некорректно использует продукт часто бывает довольно сложной задачей. Ошибка есть — продукт не качественный. Соотвественно имидж продукта падает.
Мы кстати оцениваем качество продукта только на основании учета ошибок поступивших от клиентов, а внутренние ошибки обнаруженные внутри компании не учитываются, если конечно до их устранения их не обнаружат клиенты.
А что именно вы подразумеваете под «некорректным» использованием продукта? Возможности продукта, мне кажется, должны быть строго регламентированы, в том числе интерфейсом. Если интерфейс позволяет осуществлять коммуникацию с продуктом, которая приводит к нежелательным последствиям, наверное, какие-то проблемы в самом программном продукте.
Или я вас не понял?
Или я вас не понял?
Да, разумеется это так. Но в реальности все возможные сенарии работы с продуктом не предусмотреть. Вот для этого случая в классификацию и добавлена категория «Сценарий не нормального использования».
В результате когда при каком-то не предусмотренном варианте клиент получает ошибку, то эта ошибка будет классифицирована как менее серьезная чем та же ошибка в одном из основных сценариев.
Разумеется тут мы исходим из того что сценарии использования согласованны с заказчиком и наличие не предусмотренного, но возможно сценария является не только нашим собственным просчетом.
В результате когда при каком-то не предусмотренном варианте клиент получает ошибку, то эта ошибка будет классифицирована как менее серьезная чем та же ошибка в одном из основных сценариев.
Разумеется тут мы исходим из того что сценарии использования согласованны с заказчиком и наличие не предусмотренного, но возможно сценария является не только нашим собственным просчетом.
клиент который приобрел продукт для использования по редкому не стандартному сценарию
Насколько я понимаю, продукт разрабатывается под клиента (исключение составляют серийные продукты). В этом случае сценарий, который нужен клиенту, является базовым, и никак не может быть отнесен к редким и нестандартным.
Да, конечно любой баг в продукте сказывается на имидже продукта и разработчика.
Но в реальности продуктов без ошибок не бывает. Как пример, тот же баг трекер скайпа с 200 Critical errors ( jira.skype.com )
Данная система была создана для того чтобы и заказчик продукта и комманда разработчиков смогла более детально увидеть общую картину.
Возвращаясь к примеру со скайпом. Зайдя на трекер и увидя что там достаточное большое количество ошибок с очень серьезными статусами может создасться впечатление что продукт совершенно не работоспособный, что конечно не соотвествует общей картине.
Но в реальности продуктов без ошибок не бывает. Как пример, тот же баг трекер скайпа с 200 Critical errors ( jira.skype.com )
Данная система была создана для того чтобы и заказчик продукта и комманда разработчиков смогла более детально увидеть общую картину.
Возвращаясь к примеру со скайпом. Зайдя на трекер и увидя что там достаточное большое количество ошибок с очень серьезными статусами может создасться впечатление что продукт совершенно не работоспособный, что конечно не соотвествует общей картине.
Традиционно ошибки в системах учета ( bug track system ) делятся на категории
Обычно делятся на priority и severity. Но часто их путают и тупо severity не используют.
Обычно делятся на priority и severity. Но часто их путают и тупо severity не используют.
Тем временем, в далёком 1986 году Моторола придумала шесть сигма.
Извиняюсь, ссылка не вставилась: ru.wikipedia.org/wiki/Шесть_сигма
Возможно что я ошибаюсь, но ведь эта методология применима в первую очередь к серийному производственному процессу. Я с трудом себе представляю как ее можно применить в случае когда продукт существет в единственном экземпляре.
Программный продукт — это не одна единая и неделимая сущность. Это — куча строк кода, и производятся они серийно на протяжении длительного времени. Поэтому считается количество ошибок на миллион строк кода (хотя в точном количестве могу и ошибаться).
ЗЫ
Я не фантазирую, это действительно так и используется.
ЗЫ
Я не фантазирую, это действительно так и используется.
Sign up to leave a comment.
Способ подсчета коэффициента, отражающего качество выпущенного программного продукта