How to measure quality in a software development project?

Quality is one of the four key project constraints, which need to be planned and controlled by a project manager during the entire project lifecycle. In order to plan and control it the PM, first of all, has to understand how to measure it. What are possible and most effective methods of measurement of quality in a software development project?

asked Apr 6, 2011 at 10:33 7,050 4 4 gold badges 29 29 silver badges 51 51 bronze badges Possible methods are googlable. What are you hoping to accomplish with this question? Commented Apr 6, 2011 at 20:57

The "hooks" for measuring are very dependent on the specific methodology. Are you talking about one of the lean/agile approaches, a "traditional" approach, or something else?

Commented Apr 7, 2011 at 4:27

I'm surprised that no one really emphasized 'requirements' in most answers bellow? The requirements will establish your 'limits' or 'range' for what's expected and acceptable. Your measured quality will be practically entirely based on those requirements. As most have pointed out, it is subjective. In one case one person may see an action as 'good enough' and another as 'not good', but if your requirements quantified it properly, then and only then could a measure of quality be established by comparing actual results to the stated requirements.

Commented Feb 15, 2013 at 21:24

6 Answers 6

Depending from circumstances, you can use different techniques to evaluate the quality of a software product:

Completness: What part of the needed features are actually implemented
Asking users: What is the feeling of typical users about the software?
Metrics: Some metrics can give you a good idea about the quality of the code
Process: The use (or not) of certain processes is a good hint about the quality of a development process. Bugtracking, automated tests, versioning tools.
Bug detection: As BillThor explained, bug detection rate is a good indicator

615 1 1 gold badge 5 5 silver badges 14 14 bronze badges answered Apr 6, 2011 at 14:19 Alexis Dufrenoy Alexis Dufrenoy 2,172 1 1 gold badge 14 14 silver badges 24 24 bronze badges

If you are talking about quality in terms of correctness and stability after release, then bug defect rate is the easiest way to measure it. The problem with this metric is that it only works after you've released it. It's already too late.

Even though it's too late, I'm going to suggest this is still the best measure. You can at least change your development practices to improve it for the next release.

That's what happens with project development. You do what you think is necessary in regards to quality, ship it, take your lumps, and improve. This is why it's important to have experienced developers and testers. They've already taken their lumps.

Some practices we rely on to address quality:

Automated integration tests.
Unit Tests.
Acceptance tests for every story (we use user stories for requirements)
Feature Level Tests (testing groups of stories)
Code reviews (all our code is reviewed using a tool)
Risk tracking
Manual testing for each story, immediately after it is implemented.
Automated performance tests.

Many of these practices have come about as corrective measures after we learned we could do better. It's an iterative process. We change every release.

answered Apr 6, 2011 at 14:20 Jeffrey Faust Jeffrey Faust 161 1 1 bronze badge

Unit Testing will also determine if the bug is in the implementation or spec. In other words, if code coverage is approaching 100% and all tests are passing, then the problem is obviously in the understanding of the solution.

Commented Apr 7, 2011 at 18:33

@John: to an extent. Even if code coverage touches every line (100%), you will never have 100% path coverage. And unit tests, by design, ignore integration issues, where many bugs can lie.

Commented Apr 7, 2011 at 18:42

As it was described above quality is very wide and subjective matter. What comes to my mind is for example:

a) meeting customer needs - if you have comfort to collaborate customer you can measure it by demonstrating your product to him, and have excellent feedback about this aspect of quality.

Lot of aspect is significant here starting from product robustness through implementation of most needed features finishing on usability of product and comfort of work for customer. All aspects are more or less included in feedback.

Hard to think about any tools that can measure this aspect of quality :). This is where Agile approach with short iteration and frequent user feedback might improve quality (satisfaction) a lot.

b) low level of bugs - as single measure that shows you how well requirements were turned into code. This value can be measured and there are lot of tools that can help you. (JIRA, Bugzilla)

c) code quality - not related directly to level of bugs - but rather to difficulties in later modifications of code and product maintenance. This is more 'fragile' aspect of quality and you definitely needs a tool to measure it:

Cobertura (http://cobertura.sourceforge.net/) - unit test coverage tool - generally the more automated tests the easier to do anything with code without breaking it
PMD (http://pmd.sourceforge.net/) - static code analysis tool - the more readable is code the easier is to modify it

This aspect might be also described as Technical Debt (http://en.wikipedia.org/wiki/Technical_debt)(kind of compromise that were done on account of code quality, to be able keep deadlines for example)

d) another aspects might be scalability, performance, high availability there are also some general and also very specialized tools to help measure such aspect of products. Let me mention only :

Grinder (http://grinder.sourceforge.net)
Jmeter (http://jakarta.apache.org/jmeter/)