Сообщений в теме: 37

[Dananas]

Да доброго дня всем! =)

 

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

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

 

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

[Сергей]

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

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

[Dananas]

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

[Vasiliy]

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

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

[Freiman]

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

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

[clipsa]

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

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

[Garm]

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

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

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

[BadMF]

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

 

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

[Dananas]

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

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

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

X = User*100/All

 

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

[Dananas]

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

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

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

[Freiman]

Если продукт "коробочный" либо saas, и клиентов много, то на каждого, сообщившего об ошибке, приходится сотня тех, кто с ней столкнулся, но писать не стал. А просто, например, не купил продукт :)
Так что, на мой взгляд,

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

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

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

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

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

[Dananas]

 

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

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

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

 

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

 

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

 

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

[Dananas]

 

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

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

[Freiman]

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

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

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

[SALar]

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

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

[Dananas]

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

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

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

 

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

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

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

[Little_CJIOH]

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

[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

[SALar]

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

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

 

 

 

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

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

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

 

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

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

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

 

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

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

 

 

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

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

[DmitriyQA]

Важен не процент багов, а их критичность. Были ли вызваны ролобеки (откаты версии) даннными багами. Как много хотфиксов было сделано из за багов. 

При этом добавлю что до 10% это еще можно пожурить, но 40% давай досвидания. Надо срочно что то менять в отделе тестирования