Перейти к содержимому

Фотография

Оценка количества ошибок после релиза


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 24

#1 I_G

I_G

    Активный участник

  • Members
  • PipPip
  • 120 сообщений

Отправлено 16 марта 2006 - 06:45

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

Под методикой понимается алгоритм расчета, под критериями что-то типа орг. выводов : плохо, очень плохо, ужасно.

Например, на этапе разработки обнаружено 4000 багов на 1000000 строк кода. Допустим, все 4000 багов исправлены и оттестированы.
Вышел релиз, не важно Альфа или Бета, или даже final - заявленная фунциональность по идее должна работать без ошибок.
За время тестирования заказчиками (приемочные испытания) обнаружено еще 200 багов.

Собственно вот эти 200 багов - это катастрофа или допустимо?
  • 0

#2 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 16 марта 2006 - 07:05

Собственно вот эти 200 багов - это катастрофа или допустимо?

Просмотр сообщения

Баг багу рознь. Сколько человек погибло в результате проявления этих 200 багов? Если меньше десятка -- тогда ещё терпимо, а если под сотню -- значит, точно катастрофа.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#3 Kaluga

Kaluga

    Опытный участник

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 16 марта 2006 - 09:11

Если меньше десятка -- тогда ещё терпимо, а если под сотню -- значит, точно катастрофа.

Просмотр сообщения


Какой Вы добрый :)

По существу. Что бы ответить на этот вопрос необходио учесть еще разные факторы. Например, такие как область для которой разработана программа, сколько багов в прогремме конкурентов и т.п.
  • 0
no fate but what we make

#4 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 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.
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#5 I_G

I_G

    Активный участник

  • Members
  • PipPip
  • 120 сообщений

Отправлено 16 марта 2006 - 10:07

Артем, спасибо! Это как раз то, в чем и был вопрос. Можно-ли попросить ссылку на источник, либо название "авторитетного органа" данного подхода?

Алексей и Kaluga, абсолютно с Вами согласен, как раз можно, получив количественные показатели на базе подхода от Артема, двигать их в ту или иную сторону как раз путем ввода различных факторов.
  • 0

#6 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 16 марта 2006 - 10:11

Ссылка, к сожалению, затерялась в аналах истории :)
Вроде бы я эту статейку на www.StickyMinds.com нашел...

Точнее сказать не могу...
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#7 I_G

I_G

    Активный участник

  • Members
  • PipPip
  • 120 сообщений

Отправлено 16 марта 2006 - 10:20

Нашел :)

Кому интересно - вот и ссылка на статью: Test Efficiency
  • 0

#8 Kaluga

Kaluga

    Опытный участник

  • Members
  • PipPipPipPip
  • 303 сообщений
  • ФИО:Александр
  • Город:Москва

Отправлено 16 марта 2006 - 10:46

Алексей и Kaluga, абсолютно с Вами согласен, как раз можно, получив количественные показатели на базе подхода от Артема, двигать их в ту или иную сторону как раз путем ввода различных факторов.

Просмотр сообщения

Ну, метрики тоже подвергаются критике. Я думаю, если тот же стикимайндс почитать, найдутся и статьи против их использования.
Так информация к размышлению. Что если мы нашли миллион критических ошибок, но в результате упущенной серьезной человек стал калекой? Или нанесен серьезный материальный ущерб?.. По этим формулам получается, что мы очень даже не плохо поработали, а на самом деле...
Есть над чем подумать.
Сразу скажу, я не сторонник и не противник использования таких методов.
  • 0
no fate but what we make

#9 Volant

Volant

    Активный участник

  • Members
  • PipPip
  • 92 сообщений

Отправлено 16 марта 2006 - 16:05

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

Просмотр сообщения


Если кто-то стал калекой, то это значит, что не правильно были оценины риски и расставлены приоритеты в создание такого комплекса вообще или кого-то не предупредили на что он идёт, начиная этим комплексом пользоваться, что тоже свинство!
  • 0

#10 QArer

QArer

    Новый участник

  • Members
  • Pip
  • 57 сообщений

Отправлено 12 июля 2006 - 09:30

Нашел :)

Кому интересно - вот и ссылка на статью: Test Efficiency

Просмотр сообщения



Только это похоже на effectiveness а не на efficiency...
  • 0

#11 QArer

QArer

    Новый участник

  • Members
  • Pip
  • 57 сообщений

Отправлено 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 с очень большим весом.
  • 0

#12 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 14 июля 2006 - 07:01

Вообщето, требования к бездефектности софта могут формулироваться до написания кода. И это очень помогает.
Например может быть такое требование:
* Продукт признается неготовым к выпуску при наличии хотя бы одного бага класса / типа...
Не ставьте телегу впереди лошади.

Сначала требование, потом измерение (если оно вообще нужно).
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

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

ВебПосиделки клуба имени Френсиса Бэкона 

 


#13 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 14 июля 2006 - 08:34

А вообще, ещё, логично приемочные испытания проводить на стороне исполнителя а не заказчика. Иначе, на каком основании продукт передается заказчику либо в отдел продаж?
  • 0

#14 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 02 августа 2006 - 12:38

А вообще, ещё, логично приемочные испытания проводить на стороне исполнителя а не заказчика. Иначе, на каком основании продукт передается заказчику либо в отдел продаж?

Просмотр сообщения


Вопрос терминологии. Например, у нас тестировние до передачи заказчику называется "System Test", а на стороне заказчика - "User Acceptance Testing".

А насчёт основания для передачи заказчику - вопрос и вовсе провокационный (оговорюсь сразу, что говорю не о компании где я работаю :blush: ). Вам не знакомо такое основание под названием "dead line"? :crazy:
  • 0
Best regards,
Майк.

#15 Guriy

Guriy

    Опытный участник

  • Members
  • PipPipPipPip
  • 316 сообщений
  • Город:Киев, Украина

Отправлено 07 августа 2006 - 10:36

Так информация к размышлению. Что если мы нашли миллион критических ошибок, но в результате упущенной серьезной человек стал калекой?


Если серьезная - человек стал калекой, то критикал - утопили континент, а блокер - Землю взорвали? ;)

Есть определенный сорт ПО, в котором наличие хоть какой-то ошибки недопустимо (кардиостимулятор например) в других областях где не требуется повышенной надежности (телефон например) наличие ошибок допускается.
Соответсвенно качество Вашей работы при тестирования кардиостимуляторов не может быть оценено по данной методике. Наличие хотя-бы одной ошибки недопустимо.
  • 0

#16 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 07 августа 2006 - 10:59

А насчёт основания для передачи заказчику - вопрос и вовсе провокационный (оговорюсь сразу, что говорю не о компании где я работаю  :lazy: ). Вам не знакомо такое основание под названием "dead line"? :crazy:

Просмотр сообщения

А причем тут дедлайн? Это уже ошибки планирования...
Надеюсь, мы говорим о компании, имеющей мало-мальскую СМК?
  • 0

#17 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 07 августа 2006 - 11:48

При чём тут система менеджмента качества, если у заказчика приоритет - сроки, а не качество? В только что опубликованной статейке Кокбёрна довольно чётко прослеживается о том, что методология зависит от типа проекта. Управление качеством вполне поподает в ту же категорию. Если заказчик говорит, что приоритет - сроки, и то что систему не успели как следует протестировать - не является основанием для задержки релиза - то никакая СМК тут не спасёт, и тут нужна "методология", учитывающая эту особенность проекта. В том случае, который я описываю, проблема решается просто - систему отдают в том виде, который есть (вне зависимости от того, успели ли её полностью протестировать) - пользователям, и они не дают выпустить до тех пор, пока не исправлены баги, которые ОНИ (пользователи) отметили как блокеры. При этом главный goal группы тестирования - добиться того, чтобы она (группа тестирования) находила значительно больше багов чем пользователи (ну, и, опять-таки, чтобы сроки выдерживались). А уж как этого добиться - дело группы тестирования. Задерживать релиз потому, что тестировщики не успели что-то протестировать никто не будет.

Ну и понятно, что ответственность за качество при таком подходе размазывается между заказчиком и исполнителем. Но получат по башке, если что оба - поэтому сроки иногда всё же переносятся....

Сообщение отредактировал Mike: 07 августа 2006 - 11:53

  • 0
Best regards,
Майк.

#18 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 07 августа 2006 - 11:52

Ну да. Быстро. Качественно. Недорого. Выберите любые два пункта.
:lazy:
  • 0

#19 melan

melan

    Новый участник

  • Members
  • Pip
  • 14 сообщений
  • ФИО:Дима Меланченко

Отправлено 25 ноября 2006 - 00:19

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

На мой взгляд единственный случай, когда мы сможем оценить качество работы тестеров - это когда мы будем точно знать количество багов в системе, а это уже мутационное тестирование. Т.е. делаем в система (специально) 10 багов и отдаем тестерам. Они находят 8. Эффективность - 80%.

Если говорить об оценке качества релиза, то тут скорее можно смотреть на статистику, сравнивая рализы между собой. При этом нужно четко определять для каждого найденного клиентом дефекта: в какой версии он появился, а также вводить поправку на сложность того или иного релиза.
  • 0

#20 idunin

idunin

    Активный участник

  • Members
  • PipPip
  • 116 сообщений
  • ФИО:Илья Владимирович
  • Город:Москва


Отправлено 25 ноября 2006 - 17:38

На мой взгляд единственный случай, когда мы сможем оценить качество работы тестеров - это когда мы будем точно знать количество багов в системе, а это уже мутационное тестирование. Т.е. делаем в система (специально) 10 багов и отдаем тестерам. Они находят 8. Эффективность - 80%.

Просмотр сообщения

Скажите, а подразумевается что в целом система свободна от ошибок и есть только эти 10 багов?

Просто тяжело это представить. Сначала группа тестирования говорит, что продукт свободен от ошибок. Потом в продукт намерянно вносятся 10 ошибок и снова отдается на тестирование? И уже после проверяется эффективность работы группы тестирования?
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных