Skip to main content
Software Quality Assurance & Testing

Return to Answer

deleted 1 character in body
Source Link
dzieciou
dzieciou
  • 10.5k
  • 9
  • 48
  • 102

Metrics are misleading. You can catch 10 000 useless bugs, but if the one that kills a few patients in the hospital is not caught, you're dead. Well, dead in terms of career, not as much as the hospital's patients.

But metrics can be useful to convince people who believe only in them, unfortunately. If, and only if, the rationale behind the metrics is to convince your hierarchy QA is useful, then begin to think about what they want to hear. Usually, it's about money(adapt if they have other things in mind), and you can compare the cost of an early correction to the cost of a late correction. You can add also the "image" effect of being on delay.

There is a few litterature onliterature covering the topic. It can help you. But remember : the real effect is not measurable in numeric terms. Its only real usefulness is to convince people who don't move as long as they don't have numbers that QA is useful. The real bottom line is that without a QA team, in the modern software world, you're going to vanish from the market. That's why both Michael Durrant & Rsf did insist in their excellent answers that they don't need metrics. They are not useful for doing a proper job.

Metrics are misleading. You can catch 10 000 useless bugs, but if the one that kills a few patients in the hospital is not caught, you're dead. Well, dead in terms of career, not as much as the hospital's patients.

But metrics can be useful to convince people who believe only in them, unfortunately. If, and only if, the rationale behind the metrics is to convince your hierarchy QA is useful, then begin to think about what they want to hear. Usually, it's about money(adapt if they have other things in mind), and you can compare the cost of an early correction to the cost of a late correction. You can add also the "image" effect of being on delay.

There is a few litterature on the topic. It can help you. But remember : the real effect is not measurable in numeric terms. Its only real usefulness is to convince people who don't move as long as they don't have numbers that QA is useful. The real bottom line is that without a QA team, in the modern software world, you're going to vanish from the market. That's why both Michael Durrant & Rsf did insist in their excellent answers that they don't need metrics. They are not useful for doing a proper job.

Metrics are misleading. You can catch 10 000 useless bugs, but if the one that kills a few patients in the hospital is not caught, you're dead. Well, dead in terms of career, not as much as the hospital's patients.

But metrics can be useful to convince people who believe only in them, unfortunately. If, and only if, the rationale behind the metrics is to convince your hierarchy QA is useful, then begin to think about what they want to hear. Usually, it's about money(adapt if they have other things in mind), and you can compare the cost of an early correction to the cost of a late correction. You can add also the "image" effect of being on delay.

There is literature covering the topic. It can help you. But remember : the real effect is not measurable in numeric terms. Its only real usefulness is to convince people who don't move as long as they don't have numbers that QA is useful. The real bottom line is that without a QA team, in the modern software world, you're going to vanish from the market. That's why both Michael Durrant & Rsf did insist in their excellent answers that they don't need metrics. They are not useful for doing a proper job.

Source Link
gazzz0x2z
gazzz0x2z
  • 436
  • 3
  • 8

Metrics are misleading. You can catch 10 000 useless bugs, but if the one that kills a few patients in the hospital is not caught, you're dead. Well, dead in terms of career, not as much as the hospital's patients.

But metrics can be useful to convince people who believe only in them, unfortunately. If, and only if, the rationale behind the metrics is to convince your hierarchy QA is useful, then begin to think about what they want to hear. Usually, it's about money(adapt if they have other things in mind), and you can compare the cost of an early correction to the cost of a late correction. You can add also the "image" effect of being on delay.

There is a few litterature on the topic. It can help you. But remember : the real effect is not measurable in numeric terms. Its only real usefulness is to convince people who don't move as long as they don't have numbers that QA is useful. The real bottom line is that without a QA team, in the modern software world, you're going to vanish from the market. That's why both Michael Durrant & Rsf did insist in their excellent answers that they don't need metrics. They are not useful for doing a proper job.