Software Quality in Software Engineering: Metrics, Testing and Worked Examples

Learn the vocabulary and calculations behind software quality, from McCall's factors to basis-path testing and service availability.

Prashant Jain

KnowledgeGate AI educator

Updated 16 Jul 20265 min read

Most students can say that quality means software works, then lose marks on the precise vocabulary. Software quality is a testable set of factors, distinctions and formulas. This guide teaches that set, works through defect density, cyclomatic complexity and availability, and exposes the usual traps.

What software quality actually means

Pressman's three-part framing defines quality as conformance to stated functional and performance requirements, documented development standards, and implicit expectations of professional software. A product must therefore meet its purpose, follow the agreed process and behave dependably.

Functional quality asks whether software meets its specification and performs required tasks with few defects. Structural quality asks whether its code is maintainable, testable and sensibly organised. Correct output can coexist with poor internal design.

Quality models organise these properties. McCall groups the “ilities” by operation, revision and transition. ISO/IEC 25010, which succeeded ISO/IEC 9126, supplies a separate model. Use the official ISO standard for its exact current list.

Software quality factors you must be able to name

The core factors have distinct meanings:

  • Correctness: conformance to requirements and objectives.

  • Reliability: probability of failure-free operation for a stated time and environment.

  • Efficiency: performance relative to time and memory resources.

  • Integrity: protection against unauthorised access or modification.

  • Usability: effort to learn, operate and understand the product.

  • Maintainability: effort to locate and correct faults.

  • Flexibility: effort to modify the product for new requirements.

  • Testability: effort to test the product's correctness.

  • Portability: effort to move software to another environment.

  • Reusability: ability of components to serve another application.

  • Interoperability: ability to exchange data or work with other systems.

McCall groups them into three memorable views. Product Operation contains correctness, reliability, efficiency, integrity and usability. Product Revision contains maintainability, flexibility and testability. Product Transition contains portability, reusability and interoperability.

A three-column tree titled "McCall software quality factors". Root node "Software Quality" branches to three boxes: "Product Operation", "Product Revision", "Product Transition". Under Product Operation list Correctness, Reliability, Efficiency, Integrity, Usability. Under Product Revision list Maintainability, Flexibility, Testability. Under Product Transition list Portability, Reusability, Interoperability. Clean labelled boxes, no numbers.

Correctness means conformance to specification. Reliability is the probability of failure-free operation under stated conditions and time. They are not synonyms, a favourite one-mark trap.

Software metrics: measuring quality with numbers

Metrics replace impressions with repeatable numbers. Size metrics include LOC, KLOC and function points. Quality and design metrics include defect density, cyclomatic complexity, coupling and cohesion.

Module X has 45 defects in 15,000 LOC. Module Y has 12 in 3,000 LOC. Defect density is defects divided by KLOC:

  1. Module X size = 15,000 / 1,000 = 15 KLOC.

  2. Module X density = 45 / 15 = 3.0 defects per KLOC.

  3. Module Y size = 3,000 / 1,000 = 3 KLOC.

  4. Module Y density = 12 / 3 = 4.0 defects per KLOC.

Module Y has fewer total defects but more per KLOC, so this metric rates Y lower. A smaller raw count is not automatically better.

Aim for low coupling and high cohesion. Cohesion from best to worst is functional, sequential, communicational, procedural, temporal, logical and coincidental. Coupling from best to worst is data, stamp, control, common and content. Content coupling is worst.

Cyclomatic complexity: a worked example step by step

Read score. Set grade to "Pass" if score >= 50, else "Fail". Run while i < 3, incrementing attempts and i, then test if grade == "Pass", print and end.

McCabe's equivalent methods are:

  • V(G) = E - N + 2P, where E is edges, N is nodes and P is connected components.

  • V(G) = number of predicate nodes + 1 for a single connected flow graph.

  • V(G) = number of enclosed regions + 1.

The graph has N = 8, E = 10 and P = 1. The first if, while and final if give three predicate nodes.

  1. Edge formula: V(G) = 10 - 8 + 2(1) = 2 + 2 = 4.

  2. Predicate formula: V(G) = 3 + 1 = 4.

  3. Region formula: three enclosed regions plus the outside region gives V(G) = 3 + 1 = 4.

All methods give four linearly independent paths, so basis-path testing needs at least four test cases. The value also upper-bounds the branch-coverage test count here. Larger values mean harder testing and maintenance.

A labelled control-flow graph for the worked program. Node 1 "start/read score" points to node 2 "if score>=50". Node 2 true points to node 3 "grade=Pass" and false points to node 4 "grade=Fail". Nodes 3 and 4 point to node 5 "while i<3". Node 5 true points to node 6 "attempts++; i++", which loops back to node 5. Node 5 false points to node 7 "if grade==Pass". Node 7 true and false both point to node 8 "end/print". Annotate N=8, E=10, P=1, decision nodes=3 and V(G)=10-8+2=4.

QA versus QC, and verification versus validation

Quality Assurance (QA) is process-oriented, proactive and preventive, covering standards, audits and reviews. Quality Control (QC) is product-oriented, reactive and detective, covering testing and product inspection.

Verification asks, “Are we building the product right?” Reviews, walkthroughs and inspections check conformance to specification. Validation asks, “Are we building the right product?” Execution checks the user's actual need.

An informal walkthrough is author-led. A Fagan inspection is formal, with defined roles and a defect log. Both are static verification. The one-mark rule is that verification is mostly static, validation is dynamic, and testing sits under validation and QC.

Software reliability and a worked availability example

Software reliability is the probability of failure-free operation for a specified time and environment. MTTF is mean time to failure; MTTR is mean time to repair. Some texts use MTBF for mean operating time between failures, while others define the full cycle as MTBF = MTTF + MTTR. Follow the question's convention.

Here MTBF means 300 hours of operating time, and MTTR is 12 hours. Availability is uptime divided by uptime plus downtime:

  1. Total cycle time = 300 + 12 = 312 hours.

  2. Availability = 300 / 312 = 0.961538....

  3. As a percentage, 0.961538... x 100 = 96.1538...%, or about 96.15%.

Halving MTTR to 6 hours gives 300 / 306 = 0.980392..., or 98.04%. Faster recovery improved availability without changing the failure interval. If MTBF means the full cycle, use availability = MTTF / MTBF.

Jelinski-Moranda and Musa are reliability-growth models. Do not invent constants; calculate only when a question supplies a model and parameters.

How exams and interviews test software quality

Software Engineering is not in the current GATE CS core syllabus. The official UGC NET Computer Science syllabus and recent PSU or teaching-recruitment notifications have specified it. For any attempt, use the conducting body's applicable official syllabus or notification for inclusion, weightage and wording.

Questions ask you to compute V(G), rank coupling or cohesion, separate QA from QC and verification from validation, match an “ility”, or calculate defect density and availability. In interviews, high complexity means more paths and harder testing, often calling for refactoring.

Flow-graph counting uses the vocabulary in Graph Theory: Euler and Hamiltonian Paths, Coloring and Connectivity. Mishandled locks turn concurrency defects into quality failures, making Process Synchronization and Semaphores: Race Conditions, Peterson's Solution, Wait and Signal a useful companion.

The short version and where to go next

Software quality is a named set of factors. Measure it with defect density, complexity, coupling and cohesion. Remember V(G) = E - N + 2P = predicate nodes + 1. Keep QA apart from QC, verification apart from validation, and availability tied to uptime and repair.

For Software Engineering with core CS for placements and technical recruitment, use Computer Science Fundamentals for Placements by Sanchit Sir. For GATE planning, start with GATE Guidance by Sanchit Sir. The GATE CS Subject Notes hub connects the remaining deep dives.

Redraw the eight-node graph and derive V(G) = 4 all three ways. That is the skill a numerical question checks.