Let me start with a snippet of conversation from one of the meetings I attended…
One of the managers while discussing a certain topic said, "We should release our product with utmost quality". Another manager responded to this statement by asking this question, "How do you measure quality?" The first manager replied, "My definition of quality is a satisfied customer"….
Interesting, "Quality of a product is satisfied customer" - This statement is so true, but at the same time it's so vague. Can you really measure quality of the product based on customer satisfaction? In the Agile world, the customer might not use the product until enough features have been implemented. And by the time customers start using the product, it might be too late to determine the overall quality of the product.
So the question is, how do we measure the software quality of an Agile project?
In my opinion, there are various metrics that can be collectively used to determine the quality of the code and measure customer satisfaction.
- All stories should meet the "Done Done" criteria each iteration. "Done Done" means
- Development complete with Unit Tests.
- QA Done with Automated Integration Tests.
- Documentation Done along with updates to Wiki.
- Each story meets Acceptance Test criteria.
- Ensure there are no critical issues at end of iteration.
- Set organization wide code coverage metrics that all teams adhere to. Ex. Code Coverage should be 85% or more.
- Monitor number of defects found by the Quality Assurance team and by the Customers.
- Monitor regression test results for every fix being delivered - this should be almost negligible if unit tests are implemented correctly.
How do you measure quality of your product?
4 comments:
There is some really good discussion on this thread at: http://groups.yahoo.com/group/scrumdevelopment/message/41282
All you have concentrated on is a couple of aspects of external quality. The satisfaction of requirements without visible defects. Without considering internal quality, you will end up with a big ball of mud, an unmaintainable nightmare that still satisfies requirements and passes all tests without visible defects, but you wont be able to modify it easily, and the bugs you do have will be found by the customer rather than testing, will be hard to diagnose, and even harder to fix.
I suggest having a look at the ISO 9126 software quality model for a more balanced, complete view of software quality, both external and internal.
The next step would be finding out a bit about technical debt, and how to measure and manage that.
Then there is the matter of measuring quality in a legacy situation: when you face a mountain of technology debt, how do you manage change in a way that increases code quality while staying within financial and deadline constraints?
Very informative post. Its really helpful for me and beginner too. Check out this link too its also having a nice post with wonderful explanation on software quality over the internet which also explained very well...
http://mindstick.com/Articles/59234515-f8c7-4dea-81a4-a8aca67c0807/?Product%20Quality%20Measures%20for%20Testing
Post a Comment