New answers tagged

0

Identify base stories. It is very important to identify one or multiple base or reference story against which you would do relative sizing of the backlog. This story is picked from current product backlog or a different story which we have done earlier. But what is important is the understanding of this sory is same among everyone on the team. Team should ...


0

Firstly unlike traditional methodologies where the QA estimate may be separate to the developer estimate, when working in an agile way you will want your software testing estimates to be combined with your developer estimates, producing one estimate per user story. The most common way to do this estimate is using story points where your estimates is a ...


1

I've never used metrics in this way, however, you can build a case with some care and a lot of data mining. First find out the average time cost per bug found by customers. You're going to need to find out how much time is spent in diagnosis, fixing, devising workarounds, and pushing patches, and average over the total number of bugs (this will never be ...


0

Do you have the opportunity to compare two projects delivered one with and one without the QA effort? If projects are comparable you should realize that bugs reported by customers are less both as amount and severity. If not, your QA team could not be set up as it should. Non conformities or variances reported by customers are a huge price to pay not only in ...


0

This is sort of a slippery slope sort of thing to get in, because if you measure by amount of bugs...that's not always accurate. But in some cases it is difficult for managers/etc... to really see the value of QA. Especially in cases where people expect a completely bug free system or otherwise "QA is failing to do their job". The easiest thing to remember ...


1

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 ...


4

By the success of the company. Buy-in for QA will need to come from the top rather then the justification being looked for in data. You will, over time, be able to point to things like some major bugs prevented from reaching customers performance issues anticipated and planned for unusual bugs discovered for certain conditions more new customers more ...



Top 50 recent answers are included