7% - высокий ли процент ошибок с боевого?

Вопиющий случай. Семь процентов ошибок с боевого, мне тут недавно сказали, что это большой показатель. Разрази меня гром! Да так ли это??

Какой у кого, по чесноку, данный показатель (я понимаю что бывают разные приоритеты и все такое, но если брать среднее арифметическое).

Хочу переубедить своего оппонента, но не хватает доводов! С его слов, нормальный показатель это 3%, все что больше - это вы отцтой тестировщики и место ваше в отстойнике.

#2 Сергей

Город: Москва

У нас нет такой оценки. Технический долг есть)))

Интересно, как вы подсчитываете процент этот?

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс

#3 Dananas

ФИО: Егор

Можно считать отдельно по функционалу, можно считать по релизу, а можно общую переменную. Вот по ней у меня получилось порядка 7% ошибок с боевого. При этом максимальное в релизе было порядка 40% =(

#4 Vasiliy

ФИО: Касимов Василий
Город: Москва

А как вы считаете этот показатель?

Я с таким не сталкивался.

#5 Freiman

ФИО: Андрей Адеркин
Город: Йошкар-Ола

Я слышал про 5%, с того времени, как мы начали считать этот показатель, у нас он за это значение сильно не выходил, обычно было 3-4%. Про 5% я когда-то давным-давно услышал на SQADays, и эта цифра показалась мне вполне адекватной.

Менее 3% пропущенных ошибок, по-моему, вообще малореальная ситуация для обычных, не жизненно важных, систем.

#6 clipsa

ФИО: Ермолаева Ольга
Город: Москва

Зависит от принятых в компании норм, ПО то разное бывает.

Ну и я бы считала % только критичных ошибок или по крайней мере в разбивке по критичности, а то мелких ошибок может быть миллион, но они никак не влияют ни на что.

Не следует заставлять тестировщиков тестировать быстрее. Что может быть хуже испуганных, усталых, цинично настроенных тестировщиков? ----------------- Хорошо, когда человек заводит баги . Плохо, когда баги заводят человека (с) ----------------- Проект для начинающих тестировщиков Хомячки

#7 Garm

А какова аргументация? Так-то важно "качество", а не количество, как выше отметили.

Вообще, тоже интересен метод расчёта процентов.

#8 BadMF

ФИО: Dmitry Petrov

В решении таких споров, отлично помогает линейка. Если вы понимаете о чём я.

#9 Dananas

ФИО: Егор

Я считаю просто как дважды два:

Общее кол-во ошибок - 100%

Найдено пользователями - Х

Ну и плюс любой параметр: релиз, функционал, человек, всего и т.д.

#10 Dananas

ФИО: Егор

Зависит от принятых в компании норм, ПО то разное бывает.

Согласен на приоритет. Но любая пропущенная ошибка - это же все равно по факту является ошибкой =)

#11 Freiman

ФИО: Андрей Адеркин
Город: Йошкар-Ола

это бегство тестировщиков от ответственности, выраженной в количественных показателях :)

Да, кстати, и как считается количество найденных пользователями?Каждый отчет от пользователя - +1 или каждая новая ошибка +1?

В общем, надо как-то еще учитывать количество клиентов, написавших о проблеме.Чем больше написало, тем она в действительности критичнее.

Сообщение отредактировал Freiman: 15 марта 2016 - 14:23

#12 Dananas

ФИО: Егор

А какова аргументация? Так-то важно "качество", а не количество, как выше отметили.

Вообще, тоже интересен метод расчёта процентов.

Нет разбора или он не продуктивен на предмет, почему пропускаются ошибки, ибо, если разбираться, то с след релизом данный показатель должен упасть. А в следствии этого, средний процент возврата должен идти по ниспадающей. Если же этого не происходит, то либо ты хреново разбираешься в проблемах, либо ты хреново их устраняешь. В обоих случаях - ты лопух.

Мои же доводы были таковы, что тебе может не хватать ресурсов для разрешения всех проблем, есть факторы на которые ты никак не можешь повлиять и т.д

Но все же хотелось бы увидеть статистику и понять, так 7% это норма или нет? =)

#13 Dananas

ФИО: Егор

Да, кстати, и как считается количество найденных пользователями? Каждый отчет от пользователя - +1 или каждая новая ошибка +1?

Если ТП, а потом отдел тестирования подтверждает, что описанный клиентом случай - бага, то заводим ее с пометкой "Найдено_пользователями". Ну и потом долю таких задач и высчитываю.

#14 Freiman

ФИО: Андрей Адеркин
Город: Йошкар-Ола

Да, кстати, и как считается количество найденных пользователями? Каждый отчет от пользователя - +1 или каждая новая ошибка +1?

Ок.Ну, в общем, 7% - это чуть больше, чем идеально, но в принципе тоже нормально.Сделайте еще разбивку по компонентам, где больше всего багов находится пользователями, а где меньше. Станет ясно, чему уделить больше внимания и кто из тестировщиков лажает :)

#15 SALar

Город: Москва

Не предлагаю использовать напрямую. Просто посмотрите.

facebook (Дети диаграммы Ганта)

#16 Dananas

ФИО: Егор

Посмотрите http://blog.shumoos.com/archives/271

Не предлагаю использовать напрямую. Просто посмотрите.

Что могу ответить. Только грустный смайл =((((

Слушай, а может тогда еще и подскажешь, а на основании какой информации можно определить оптимальный процент пропущенных багов? Я же так понимаю, что для разных компаний оптимальный процент будет своим, так а на основании чего его тогда можно было бы высчитать?

Например, для компании1 процент пропущенных будет равняться 25% и это будет хороший показатель, ибо штат тестирования всего 1 человек, а тестирует он соц сеть ВК.

Или компания2, процент пропущенных будет 1%, но это критично, ибо тестируют самолет.

#17 Little_CJIOH

ФИО: Власкин Павел
Город: Санкт-Петербург

Нужен анализ причины пропуска багов, сбор статистики и работа над устранением причины.

#18 Freiman

ФИО: Андрей Адеркин
Город: Йошкар-Ола

Цифры везде разные приводятся.Быстрый гуглеж показывает следующее:1. http://qablog.practi. caping-defects/ - тут говорят про 1.5-3%2. http://www.qamentor. akage-analysis/ - тут про 5%3. http://www.amdocs.co. ne-oct-2014.pdf - тут вообще говорят, что 2.5% очень хорошо, а 10% - вполне обычное явление

Еще нашлась статья без цифр, но с интересным списком метрик http://www.ust-globa. s_and KPI_s.pdf

А еще погуглите книгу Capers Jones, Applied Software Measurement - там вообще много статистики. В книге этот параметр называется defect removal efficiency (сколько дефектов было найдено и пофикшено командой перед релизом), и, если я правильно понял, лучший результат для больших систем - 98% (не берем специализированные системы, конечно).

Сообщение отредактировал Freiman: 16 марта 2016 - 09:40

#19 SALar

Город: Москва

1. В моей практике был "рекорд" - 0.03% пропущенных в прод багов. Да, да. Одна пропущенная ошибка на 3500 найденных. Но теперь я этим рекордом не горжусь. Лучше бы в прод вышли пораньше. Для того софта уровень бездефектности был ненужно высоким. Если что, на эту тему делал доклад: "SRS как основа для создания бездефектного ПО". http://school.system. roject-stories/

Но если какой то фирме важна высокая бездефектность - обращайтесь. Мне нравится делать ПО бездефектным.

Посмотрите http://blog.shumoos.com/archives/271

Не предлагаю использовать напрямую. Просто посмотрите.

Что могу ответить. Только грустный смайл =((((

Или компания2, процент пропущенных будет 1%, но это критично, ибо тестируют самолет.

Я скажу больше. Есть софт, который тестировать тестировщику просто бессмысленно. Его сразу отправляют в прод и уже в проде ищут ошибки. Т.е. 100% пропущенных при тестировании ошибок - это хорошо для бизнеса.

Таблицы процентов не видел. Или не помню, что видел. Но могу после обследования предложить модель, сколько ошибок каких типов имеет смысл пропускать в прод (стратегия тестирования).

Нужен анализ причины пропуска багов, сбор статистики и работа над устранением причины.

Это совсем другое. Но согласен, эти техники очень эффективны. И их применение часто позволяет "малой кровью" отказаться от тестирования. Если наладив процесс управления конфигурациями, коде ревью, подготовки SRS, вы предотвратите 90% багов, то может и тестирование будет не нужно?

📎📎📎📎📎📎📎📎📎📎