Метрики для ручного тестирования

Товарищи, какими метриками кроме пресловутого покрытия требований вы пользуетесь при оценке результатов ручного тестирования?

Товарищи, какими метриками кроме пресловутого покрытия требований вы пользуетесь при оценке результатов ручного тестирования?

Можно сопоставлять количество пройденных тест-кейсов с запланированным количеством.
Можно также сделать разбивку по статусам пройденных тестов: сколько из них находится в статусе passed, сколько в статусе failed, сколько заблокировано или пропущено.

По дефектам: сколько найдено, сколько пофикшено (проверено и закрыто), сколько в статусе deferred. Незакрытые баги можно разбить по priority/severity.

На самом деле, метрик довольно много. Главное понять, что вы с ними хотите делать дальше. Что вы хотите понять, используя метрики. Отсюда и танцевать :)

А вам "для себя" или "для дяди-заказчика"?

...при оценке результатов ручного тестирования?

Посмотрите про defect leakage.
Стала гуглить, как сейчас модно переводить defect leakage и нашла тут же прекрасный тред про метрики.
http://software-test...um/topic/20080/ - там развёрнуто.

Немножко докопаюсь.

Почему результаты именно ручного тестирования?
Что вы считаете результатом тестирования? А то, метрика покрытия требований, например, дает информацию по подготовке к тестированию.

Товарищи, какими метриками кроме пресловутого покрытия требований вы пользуетесь при оценке результатов ручного тестирования?

попалась статья
http://www.nbuv.gov...._6/Vilkomir.pdf
вроде сюда по теме подойдет)))

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

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

Естественно.
Но как-то минимизировать это количество дефектов нужно? И хорошо бы предсказывать - сколько будет пропущено дефектов.
Т.е. иметь некий инструмент, позволяющий предсказывать количество пропущенных дефектов.
)) интересная тема, однако))).

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

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

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

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

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

Вот его статья :
http://www.aldservic...reliability.pdf


"Advanced Models for Software Reliability Prediction".

На мой взгляд - интересно!
И (мне так кажется - интуитивно) - что есть связь с метриками)).