ELEC5618 · Software Quality Engineering
Verification and Validation
Week 5 of University of Sydney ELEC5618 Software Quality Engineering separates verification ('are we building the product right?' — conform to spec) from validation ('are we building the right product?' — meet user needs) and places both across the whole lifecycle. It contrasts static verification (software inspections, the Fagan method, automated static analysis, IEEE 1028 reviews) with dynamic validation (executing the program), covers black-box vs white-box testing and cyclomatic complexity, and is the week Assignment 1 is due.
What this chapter covers
- 01Verification ('build the product right' — conforms to spec) vs Validation ('build the right product' — meets user needs); testing shows presence of errors not absence
- 02IEEE 1012 V&V across the lifecycle; independence (IV&V); integrity levels (major/moderate/low)
- 03Static verification (inspect without executing) vs dynamic verification (execute with test data)
- 04Fagan inspection: roles (author, moderator, reader, inspector, scribe) and stages (planning → overview → preparation → meeting → rework → follow-up)
- 05Inspection checklist fault classes: data, control, input/output, interface, storage-management, exception
- 06Automated static analysis: control-flow, data-use, interface, information-flow, path analysis; more valuable for weakly typed languages
- 07Black-box (specification-based) vs white-box (structural: statement/branch/path coverage) testing
- 08Cyclomatic complexity V(G) = E − N + 2 = predicate nodes + 1 = number of independent paths
Cyclomatic complexity of a shipping-cost method
- +1Nodes: N1 entry/read; N2 decision weight > 20; N3 base = 15; N4 base = 8; N5 merge before the next decision; N6 decision isMember; N7 fee = base − 2; N8 fee = base; N9 return (exit). N = 9 nodes.
- +1Edges: N1→N2; N2→N3 (true); N2→N4 (false); N3→N5; N4→N5; N5→N6; N6→N7 (true); N6→N8 (false); N7→N9; N8→N9. E = 10 edges.
- +1Apply the formula: V(G) = E − N + 2 = 10 − 9 + 2 = 3.
- +1Cross-check: predicate (decision) nodes + 1 = 2 (weight > 20, isMember) + 1 = 3. Both agree, V(G) = 3.
- +1Minimum tests for full branch coverage: three cases that exercise both outcomes of each decision — (weight = 25, isMember = true) → base 15, fee 13; (weight = 10, isMember = false) → base 8, fee 8; (weight = 25, isMember = false) → base 15, fee 15. All four branch outcomes are covered by these 3 cases.
Key terms
- Verification
- Evaluating a product or component to check it conforms to its specification — 'are we building the product right?'. It is about correctly and fully implementing what the spec says.
- Validation
- Evaluating whether the specification (and the software) captures the client's real needs and intended use — 'are we building the right product?'. Testing is the only validation technique for non-functional requirements.
- Static vs dynamic verification
- Static verification analyses a representation (requirements, design, code) without executing it — software inspections and automated static analysis. Dynamic verification executes the program with test data and observes behaviour.
- Fagan inspection
- Michael Fagan's formal defect-detection method with defined roles (author, moderator, reader, inspector, scribe) and stages (planning, overview, preparation, inspection meeting, rework, follow-up). It is for detection, not correction, and must not be used for staff appraisal.
- Black-box vs white-box testing
- Black-box (specification-based) testing designs cases from the spec and expected behaviour without knowing internal structure. White-box (structural) testing derives cases from the code, aiming at statement, branch or path coverage.
- Cyclomatic complexity
- McCabe's control-flow metric V(G) = E − N + 2 (E edges, N nodes) = predicate nodes + 1 = number of independent paths = minimum tests for full branch coverage. It does not by itself prove testing adequacy.
Verification and Validation FAQ
What is the difference between verification and validation?
Verification asks 'are we building the product right?' — does the software conform to its specification. Validation asks 'are we building the right product?' — does the specification (and the software) actually meet the user's needs. A system can pass verification (matches the spec) yet fail validation (the spec was wrong). Remember too that testing reveals the presence of errors, never their absence, and a successful test is one that finds at least one error.
What is a Fagan inspection and who does what?
A formal, structured defect-detection review of code, specs or designs. The roles are the author/owner (produces the work and fixes defects), the moderator/chairman (organises and facilitates), the reader (paraphrases the work at the meeting), the inspector (finds errors and omissions) and the scribe (records defects). It runs through planning, overview, preparation, the inspection meeting, rework and follow-up, and it is explicitly for finding defects, not fixing them or appraising staff.
How do I compute cyclomatic complexity?
Build the control-flow graph (nodes for statements/decisions, edges for flow), then use V(G) = E − N + 2. Cross-check with 'number of decision nodes + 1' — they should match — and note that V(G) also equals the number of independent paths and the minimum number of tests for full branch coverage. It tells you how many tests you need, not whether the code is correct.
Can AI help me with V&V and cyclomatic complexity?
Yes. Sia can drill the verification-vs-validation distinction, walk a Fagan inspection's roles and stages, and rebuild a control-flow graph with you to compute V(G) step by step, checking your edge and node counts. Use it to learn the method; it does not do graded assessment, and the University of Sydney academic-integrity policy applies.
Exam move
Nail the one-line distinction first — verification = build it right (conforms to spec), validation = build the right thing (meets needs) — with an example where a system passes one and fails the other, because it is examined repeatedly. Then make cyclomatic complexity automatic: draw the control-flow graph including every merge node, apply V(G) = E − N + 2, cross-check with decisions + 1, and write one test per independent path. Keep a compact list of the Fagan roles and stages and the inspection fault classes (data, control, I/O, interface, storage, exception) for short-answer questions, and be ready to say why static analysis helps more in weakly typed languages. Assignment 1 is due this week, so apply the white-box and inspection techniques to your own code as you revise. Confirm the exam date and format on Canvas.
Working through Verification and Validation in ELEC5618? Sia is AskSia’s AI Software Engineering tutor — ask any ELEC5618 Verification and Validation question and get a clear, step-by-step explanation grounded in how ELEC5618 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
