Метрики. Что? Где? Когда?

Все, что касается управления качеством...

Модератор: YuriY

Метрики. Что? Где? Когда?

Сообщение YuriY » 09 фев 2008, 23:08

Леша!
Мог бы ты рассказать что-нибудь о существующих метриках для оценки различных процессов и т.п. в тестировании?
В шаблонах тест-планов встречается пункт "Критерий завершения тестирования". А для него нужно использовать метрику. Посоветуешь что-нибудь?)
А еще для чего и какие метрики кто знает?)
Я ж по адресу вопрос задал, правда?)
YuriY
Senior
 
Сообщений: 124
Зарегистрирован: 30 янв 2008, 01:18
Откуда: Kharkov

Re: Метрики. Что? Где? Когда?

Сообщение Dimon » 11 мар 2008, 14:40

Здравствуйте коллеги, приятно видеть знакомые имена...

yurock писал(а):Леша!
Мог бы ты рассказать что-нибудь о существующих метриках для оценки различных процессов и т.п. в тестировании?
В шаблонах тест-планов встречается пункт "Критерий завершения тестирования". А для него нужно использовать метрику. Посоветуешь что-нибудь?)
А еще для чего и какие метрики кто знает?)
Я ж по адресу вопрос задал, правда?)


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

А если и можно то должны быть метрики, которые поясняли, что для данного проекта есть "хороший".

Рядом с метриками стоит также терми measurement.
Для вычисления некоторых метрик и нужны разные измерения, всякого рода показателей.

Типичным примером метрики,
является, что:
1. критических дефектов не должно быть,
2. допускается не более 2 важных дефектов.
Измерением в данном случае и явлестя непосредственно количество дефектов критических и важных.


P.S. первое тест сообщение
Технологи технологиями, но работать все равно будут люди.
Да здравствует разум, да cгинет маразм.
Dimon
Junior
 
Сообщений: 22
Зарегистрирован: 11 мар 2008, 14:29
Откуда: Kharkov

Сообщение lesha » 13 мар 2008, 00:22

В моем представлении метрики - это что-то более активное... и оценивает сам процесс тестирования, а не результаты.. Метрика "критических дефектов не должно быть", как мне кажется мало что говорит конкретного.
Мне кажется боее показательная является такие метрики:
1) Динамика занесения тестировщиком багов: количество и приоритет багов в день, интервал между багами.
2) Количество закрытых (проверенных) багов в день.
3) Изменение количетсва открытых багов.
и т.п.

Возможно я не прав :) Готов, что-то прочитать по метрикам...Посоветуете литературы?))
lesha
Junior
 
Сообщений: 31
Зарегистрирован: 30 янв 2008, 12:19

Сообщение wishaway » 13 мар 2008, 17:17

Каждый использует разные метрики...

Стандартные метрики (кому стандартные, а кому и не очень):

1) Плотность ошибок
а) количество ошибок на строку кода
а) количество ошибок на функцию
а) количество ошибок на интерфейсную единицу (экран, web страница etc.)

2) Качество исправлений - это фактически измерение соотношения кривых фиксов к успешным фиксам. В итоге получаем число. Это число можно (и нужно) соотношать только с отдельным программистом и/или тестировщиком.

3) Время на исправление - метрика, показывающая динамику, отражающую время, которое прошло от момента записи ошибки в БТ и до момента исправления данной ошибки. Обычно меряют по всему проекту, усредняя время по каждой ошибке.

Ну и т.п. :)
Regards,
Dmitry Markov
wishaway
Junior
 
Сообщений: 27
Зарегистрирован: 13 мар 2008, 13:23
Откуда: Kharkov

Сообщение МандарЫнка » 10 апр 2008, 11:55

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

мы собираем метрики чтобы вовремя суметь скорректировать процесс тестирования.

Используем метрики изменения дефектов в разрезе времени, версии, статусов и критичности. исспользуем также метрики покрытия тестами.
уверена, список можно дополнять, но в рамках наших проектов этого более чем достаточно чтобы как-то эти метрики потом исспользовать.
МандарЫнка
Junior
 
Сообщений: 25
Зарегистрирован: 10 апр 2008, 11:49

Сообщение YuriY » 14 авг 2008, 23:37

Вот здесь нашел инфу о метриках - статьи, шаблоны и примеры репортов:
www.westfallteam.com/software_metrics,_ ... ethods.htm

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

А еще у меня такой вопрос:
Команда тестировщиков выполняет тестирование некоторого приложения, состоящего из N функциональных модулей.
Руководитель группы хочет как-то контролировать достаточно ли тщательно выполняется тестирование, чтобы избежать ситуаций когда, грубо говоря, тестировщик по каким-либо причинам проставил большинству тест-кейсов статус "Passed", пропустив существующие ошибки (из-за усталости/неопытности/невнимательности...).
Я предполагаю, что для решения этого вопроса руководитель может отслеживать количество найденных багов по модулям. Если известно, что модуль содержит сложный функционал и по идее должен содержать довольно много багов, а найдено их было мало, то можно предположить, что стоит перепроверить за тестировщиком, например, выполнить несколько "успешно пройденных" тест-кейсов или "потоптаться" рядом с ними, чтобы понять - то ли программист молодец, то ли тестировщик расслабился.

Есть ли смысл в таком мероприятии или я усложняю?)
YuriY
Senior
 
Сообщений: 124
Зарегистрирован: 30 янв 2008, 01:18
Откуда: Kharkov

Сообщение charo » 15 авг 2008, 21:20

yurock писал(а):А еще у меня такой вопрос:
Команда тестировщиков выполняет тестирование некоторого приложения, состоящего из N функциональных модулей.
Руководитель группы хочет как-то контролировать достаточно ли тщательно выполняется тестирование, чтобы избежать ситуаций когда, грубо говоря, тестировщик по каким-либо причинам проставил большинству тест-кейсов статус "Passed", пропустив существующие ошибки (из-за усталости/неопытности/невнимательности...).
Я предполагаю, что для решения этого вопроса руководитель может отслеживать количество найденных багов по модулям. Если известно, что модуль содержит сложный функционал и по идее должен содержать довольно много багов, а найдено их было мало, то можно предположить, что стоит перепроверить за тестировщиком, например, выполнить несколько "успешно пройденных" тест-кейсов или "потоптаться" рядом с ними, чтобы понять - то ли программист молодец, то ли тестировщик расслабился.

Есть ли смысл в таком мероприятии или я усложняю?)


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

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

У бывалых тестеров такого фактически не бывает, а если бывает, то они себя сами накажут лучше меня :).
If I can see it, it's a failure.
charo
Junior
 
Сообщений: 19
Зарегистрирован: 18 июн 2008, 12:46
Откуда: Днепропетровск


Вернуться в Управление качеством | Quality Management

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

cron