Оценка количества ошибок после релиза
#1
Отправлено 16 марта 2006 - 06:45
Под методикой понимается алгоритм расчета, под критериями что-то типа орг. выводов : плохо, очень плохо, ужасно.
Например, на этапе разработки обнаружено 4000 багов на 1000000 строк кода. Допустим, все 4000 багов исправлены и оттестированы.
Вышел релиз, не важно Альфа или Бета, или даже final - заявленная фунциональность по идее должна работать без ошибок.
За время тестирования заказчиками (приемочные испытания) обнаружено еще 200 багов.
Собственно вот эти 200 багов - это катастрофа или допустимо?
#2
Отправлено 16 марта 2006 - 07:05
Баг багу рознь. Сколько человек погибло в результате проявления этих 200 багов? Если меньше десятка -- тогда ещё терпимо, а если под сотню -- значит, точно катастрофа.Собственно вот эти 200 багов - это катастрофа или допустимо?
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#3
Отправлено 16 марта 2006 - 09:11
Если меньше десятка -- тогда ещё терпимо, а если под сотню -- значит, точно катастрофа.
Какой Вы добрый :)
По существу. Что бы ответить на этот вопрос необходио учесть еще разные факторы. Например, такие как область для которой разработана программа, сколько багов в прогремме конкурентов и т.п.
#4
Отправлено 16 марта 2006 - 09:22
Из множества вариантов, которые я прорабатывал больше всего мне понравился следующий подход:
Test Execution Efficiency
What is Test Execution Efficiency?
It is generally very difficult to measure the efficiency of the testing process or the testing team for a project. Test Efficiency helps to calculate the efficiency of testing i.e. how many defects were leaked to the customer as compared to number of defects reported by the testing team. Generally almost 10-15 % of defects will be leaked and is considered acceptable. In the recent years, Companies have stared spending huge amount of money for developing quality. Due to this defect leakage percentage has come down to less than 10%.
How to Measure?
The Excel Sheet Attached helps us to calculate the efficiency of a testing process based on the number of defects reported by Customer and to the number of defects identified by the Testing Team.
Steps
1) Provide Ranking to each severity.
In the excel sheet the severity rankings have been assigned as
a) Critical--4
b) Serious – 3
c) Moderate –2
d) Minor –1
2) Collect the list of defects reported by the Testing and Customer based on Severity.
For example:
The customer has Reported 1 Critical, 1 Serious, 2 Moderate and 5 Minor Defects. The Testing Team should have identified these defects. The defects that were not replicable in a test environment but only in a live production environment should not be considered.
The Testing Team has Reported 10 Critical, 5 Serious, 10 Moderate and 10 Minor Defects.
The Test Efficiency is calculated as follows: (T/T+C) * 100
T=4*10+5*3+10*2+10*1=85
C= 1*4+1*3+2*2+5*1=16
So Test Efficiency is (85/85+16) * 100=84.16%
Suppose if the Customer had not identified any defects in above example then the Test Efficiency will be 100%.
Consider a small project in which the testing team and customer did not find any defects (Assume you had a good programmer who did unit testing properly) then also the Test Efficiency will be 100%.If the Testing Team Failed to find any Defects and the Customer were finding them then the efficiency of the testing will be 0%. The formula used required fine-tuning in this case.
#5
Отправлено 16 марта 2006 - 10:07
Алексей и Kaluga, абсолютно с Вами согласен, как раз можно, получив количественные показатели на базе подхода от Артема, двигать их в ту или иную сторону как раз путем ввода различных факторов.
#6
Отправлено 16 марта 2006 - 10:11
Вроде бы я эту статейку на www.StickyMinds.com нашел...
Точнее сказать не могу...
#8
Отправлено 16 марта 2006 - 10:46
Ну, метрики тоже подвергаются критике. Я думаю, если тот же стикимайндс почитать, найдутся и статьи против их использования.Алексей и Kaluga, абсолютно с Вами согласен, как раз можно, получив количественные показатели на базе подхода от Артема, двигать их в ту или иную сторону как раз путем ввода различных факторов.
Так информация к размышлению. Что если мы нашли миллион критических ошибок, но в результате упущенной серьезной человек стал калекой? Или нанесен серьезный материальный ущерб?.. По этим формулам получается, что мы очень даже не плохо поработали, а на самом деле...
Есть над чем подумать.
Сразу скажу, я не сторонник и не противник использования таких методов.
#9
Отправлено 16 марта 2006 - 16:05
Ну, метрики тоже подвергаются критике. Я думаю, если тот же стикимайндс почитать, найдутся и статьи против их использования.
Так информация к размышлению. Что если мы нашли миллион критических ошибок, но в результате упущенной серьезной человек стал калекой?
Если кто-то стал калекой, то это значит, что не правильно были оценины риски и расставлены приоритеты в создание такого комплекса вообще или кого-то не предупредили на что он идёт, начиная этим комплексом пользоваться, что тоже свинство!
#10
Отправлено 12 июля 2006 - 09:30
Нашел :)
Кому интересно - вот и ссылка на статью: Test Efficiency
Только это похоже на effectiveness а не на efficiency...
#11
Отправлено 12 июля 2006 - 09:38
Ну, метрики тоже подвергаются критике. Я думаю, если тот же стикимайндс почитать, найдутся и статьи против их использования.Алексей и Kaluga, абсолютно с Вами согласен, как раз можно, получив количественные показатели на базе подхода от Артема, двигать их в ту или иную сторону как раз путем ввода различных факторов.
Так информация к размышлению. Что если мы нашли миллион критических ошибок, но в результате упущенной серьезной человек стал калекой? Или нанесен серьезный материальный ущерб?.. По этим формулам получается, что мы очень даже не плохо поработали, а на самом деле...
Есть над чем подумать.
Сразу скажу, я не сторонник и не противник использования таких методов.
Подобный расхождения можно решить более правлильным подбром коэффициентов:
In the excel sheet the severity rankings have been assigned as
a) Critical--4s
b) Serious – 3
c) Moderate –2
d) Minor –1
Например для Critical ввести вес не 4, а 1000, например.
Как вариант, ввести severity supercritycal с очень большим весом.
#12
Отправлено 14 июля 2006 - 07:01
Например может быть такое требование:
* Продукт признается неготовым к выпуску при наличии хотя бы одного бага класса / типа...
Не ставьте телегу впереди лошади.
Сначала требование, потом измерение (если оно вообще нужно).
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#14
Отправлено 02 августа 2006 - 12:38
А вообще, ещё, логично приемочные испытания проводить на стороне исполнителя а не заказчика. Иначе, на каком основании продукт передается заказчику либо в отдел продаж?
Вопрос терминологии. Например, у нас тестировние до передачи заказчику называется "System Test", а на стороне заказчика - "User Acceptance Testing".
А насчёт основания для передачи заказчику - вопрос и вовсе провокационный (оговорюсь сразу, что говорю не о компании где я работаю ). Вам не знакомо такое основание под названием "dead line"?
Майк.
#15
Отправлено 07 августа 2006 - 10:36
Так информация к размышлению. Что если мы нашли миллион критических ошибок, но в результате упущенной серьезной человек стал калекой?
Если серьезная - человек стал калекой, то критикал - утопили континент, а блокер - Землю взорвали? ;)
Есть определенный сорт ПО, в котором наличие хоть какой-то ошибки недопустимо (кардиостимулятор например) в других областях где не требуется повышенной надежности (телефон например) наличие ошибок допускается.
Соответсвенно качество Вашей работы при тестирования кардиостимуляторов не может быть оценено по данной методике. Наличие хотя-бы одной ошибки недопустимо.
#16
Отправлено 07 августа 2006 - 10:59
А причем тут дедлайн? Это уже ошибки планирования...А насчёт основания для передачи заказчику - вопрос и вовсе провокационный (оговорюсь сразу, что говорю не о компании где я работаю ). Вам не знакомо такое основание под названием "dead line"?
Надеюсь, мы говорим о компании, имеющей мало-мальскую СМК?
#17
Отправлено 07 августа 2006 - 11:48
Ну и понятно, что ответственность за качество при таком подходе размазывается между заказчиком и исполнителем. Но получат по башке, если что оба - поэтому сроки иногда всё же переносятся....
Сообщение отредактировал Mike: 07 августа 2006 - 11:53
Майк.
#19
Отправлено 25 ноября 2006 - 00:19
Вопрос: почему тестеры не нашли этой проблемы: потому, что работают плохо или потому, что клиент маньяк?
На мой взгляд единственный случай, когда мы сможем оценить качество работы тестеров - это когда мы будем точно знать количество багов в системе, а это уже мутационное тестирование. Т.е. делаем в система (специально) 10 багов и отдаем тестерам. Они находят 8. Эффективность - 80%.
Если говорить об оценке качества релиза, то тут скорее можно смотреть на статистику, сравнивая рализы между собой. При этом нужно четко определять для каждого найденного клиентом дефекта: в какой версии он появился, а также вводить поправку на сложность того или иного релиза.
#20
Отправлено 25 ноября 2006 - 17:38
Скажите, а подразумевается что в целом система свободна от ошибок и есть только эти 10 багов?На мой взгляд единственный случай, когда мы сможем оценить качество работы тестеров - это когда мы будем точно знать количество багов в системе, а это уже мутационное тестирование. Т.е. делаем в система (специально) 10 багов и отдаем тестерам. Они находят 8. Эффективность - 80%.
Просто тяжело это представить. Сначала группа тестирования говорит, что продукт свободен от ошибок. Потом в продукт намерянно вносятся 10 ошибок и снова отдается на тестирование? И уже после проверяется эффективность работы группы тестирования?
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных