“Keeping you up to date with everything software engineering!”

NEW CATEGORY: Software Quality

Software Quality | October 07, 2004 | 3 comments

We have added a new category under Software Engineering, thanks to the suggestion of Brian Di Croce, called Software Quality. I have to admit I had to look up the definition of Software Quality and Software Testing because I was under the impression they are synonyms of each other.

In the 2004 version of SWEBOK, Software Engineering Body of Knowledge, software testing and software quality have their separate chapters. According to the manual software testing is defined as:

The dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior.

According to (ISO9001-00) software quality is defined as (taken from SWEBOK):

the degree to which a set of inherent characteristics fulfils requirements.

SWEBOK separates Software Testing and Software Quality by saying that Software Testing is done by using dynamic techniques , i.e. running the program against a set of test cases, while Software Quality is tested by using static techniques, ie. those which do not require the execution of the software being evaluated but verifies that the quality requirements, defined in the requirements document, are meet.

Hence in our Testing category you will find articles on:

• unit testing
• automating test
• etc.

While in Software Quality you will find articles on:

• user acceptance tests
• defining quality requirements
• testing software quality
• etc.

---

UPDATE: I sent an email to Brian Di Croce and asked him two questions concerning Software Quality. I really like his answers I thought it would be a good addition to this post.

Does user acceptance tests fall under Software Quality?

Yes it does, but since you have a ‘testing’ category already, I will keep it there for students to relate on it easily.

For your own information: There a lot of categories attached to Software Quality. There are Auditing, Software Quality Control, Software Quality Assurance, Verification, Validation, Joint Review, etc. The goal of user acceptance testing is to verify that the system corresponds entirely (…or at least to) what was specified and required by the customer in the beginning, to compare the actual test results to the expected results, etc. That falls into the Validation and Verification processes under the Quality Assurance (Software Quality). The Verification process determines if the products issued of a phase of the development cycle respect and correspond to the conditions imposed in the beginning of that phase (IEEE-STD-610) The Validation process determines if the software respects the given requirements and specs (IEEE-STD-610). “Verification is doing the job right and Validation is doing the right job.” But as for now, there is a lot of confusion between “Testing” and “Software Quality” in the industry, but even though they are different, the software can not live without anyone of them. It’s like the Sun and the Moon. If you take one out, the Earth will not be able to sustain itself, and the galaxy might die…or crash ;)

What in your words are the difference between Software Quality and Testing?

That’s a good question! In my experience in school and the industry, I have learned that testing can and should be done by the programmer/developer before checking in his/her code (unit testing). Also the system should be tested when each component is being integrated into the system (integration testing) , and then there’s the system testing, which covers the overall functionality of the system before being delivered. Quality assurance can be like the cheese on a pizza. Basically it holds all the under parts together. It does so by providing an assurance that the system is conformed to the specs/reqs and that it has been done right, according to standards, processes, etc. For example, when an audit is called, the auditor will verify your software, see if it is OK or not. No testing is done here for now, unless there’s a problem. When there’s a joint review (or code review or pair review), the developers can gather together, and just talk over the code that’s being analyzed…no testing is done.

---

Related Links:

• SWEBOK

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

October 7, 2004 05:36 PM | Mark Pavlidis commented:

At McMaster the Software Quality Research Lab (SQRL), http://sqrl.mcmaster.ca/, has been established to “perform fundamental research, applied research, technology transfer, and contractual software quality assessments.”

SQRL’s approach to software quality is different that what you describe above. Instead of considering testing and quality as disjoint ideas, it instead considers testing as a subset of software quality. Software quality is achieved by the combination of the 4 major approaches: design, testing, inspeciton, and mathematical analysis. Usually only one of these approaches are used to tackle the task of software quality, but alone each do not provided enough accomplish the task.

October 7, 2004 07:05 PM | John Kopanas commented:

I agree that separating testing from quality can lead to a bad thing but I feel it is a natural seperation because the people responsible for doing testing and software quality tend to be very different.

Developers tend to do testing while project managers, requirements engineers and usability engineers tend to do software quality testing.

October 7, 2004 10:26 PM | Fred2 commented:

Could Software Measures (Metrics) be considered a category also? Or would it be included in Software process, Software quality, or project management?

I’m talking about things like COSMIC-FFP.. Or other measures related to software development that helps project management. I have a course about that this semester ;-)

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)