ELEC5618 · Software Quality Engineering
Exam Revision & Course Integration
Week 13 of University of Sydney ELEC5618 Software Quality Engineering pulls the whole unit together for the 2-hour closed-book final: it re-threads the exam-critical distinctions — QA vs QC, verification vs validation, defect vs validation testing — and the standards map (IEEE 730, IEEE 830, IEEE 1028, ISO/IEC 25010). The revision session walks the practice-exam question styles, and the targeted project closes with a video submission and live Q&A. Because the exam covers all lecture and assignment material, this chapter is where you connect requirements → V&V → testing → tools → agile → standards into one map.
What this chapter covers
- 01Consolidated review threads: SQA standards classification (process vs management), the error → fault → failure chain and nine error causes, the three quality activities (planning / assurance / control)
- 02Verification 'building it right' (conforms to spec) vs validation 'building the right product' (meets user needs) — the single most-examined distinction
- 03QA (process-oriented, build quality in) vs QC (product-oriented, check quality out); defect testing (find defects) vs validation testing (show requirements are met)
- 04Component vs integration testing; test-case structure (data, expected result, reports); black-box vs white-box thinking
- 05Practice-exam question styles: write functional requirements under an ISO/IEC 25010 sub-characteristic; remove ambiguity from an NFR; apply P-CMM; static-flow fault classes; cyclomatic complexity V(G) = E − N + 2; test-management-tool reporting
- 06Standards quick-reference grid: IEEE 730 (SQA plan), IEEE 830 (SRS), IEEE 1028 (reviews), ISO/IEC 25010 (product quality), plus IEEE 829 / 1012 / ISO 29119 as supporting references
- 07End-to-end SQE lifecycle: how planning, requirements, V&V, testing, tools, agile and process improvement connect across the semester
- 08Format: a mix of multiple-choice, short-answer and a scenario-based question with sub-parts, 2 hours, closed book — confirm the exact marks split on Canvas
Write testable functional requirements under an ISO/IEC 25010 sub-characteristic
- +1State what the named sub-characteristic means so the requirements are aimed correctly: Adaptability (under Flexibility) is the degree to which the product can be adapted to new or changing hardware, software or usage environments without changing the product itself. So the requirements must be about configuring/extending the search, not just running it.
- +1Write the first testable 'The system shall…' statement mapped to Adaptability: 'The system shall allow an administrator to add a new searchable data source through configuration only, with no change to the application source code.' It is functional (a capability), atomic and verifiable.
- +1Write a second, distinct requirement under the same sub-characteristic: 'The system shall let an administrator enable or disable a search filter field via a settings screen, and the change shall take effect on the next search without redeployment.' Again atomic, testable and clearly about adapting the feature.
- +1State the verification for each — this is what makes them testable: for R1, configure a new data source and confirm results from it appear with no code change; for R2, toggle a filter in settings and confirm the very next search reflects it without a redeploy. Each has an observable pass/fail outcome.
Key terms
- Verification vs validation
- Verification asks 'are we building the product right?' — does it conform to its specification. Validation asks 'are we building the right product?' — does the specification, and the software, meet the user's real needs. A system can pass one and fail the other.
- QA vs QC
- Quality assurance is process-oriented — evaluating and defining processes to build quality in, independent of technical/managerial/financial pressure. Quality control is product-oriented — systematically checking specific results against standards, which leads into V&V and testing. QC activities can sit inside QA.
- Defect testing vs validation testing
- Defect testing aims to find defects (a successful test discovers at least one error); validation testing aims to show the requirements are met and build confidence. Testing reveals the presence of errors, not their absence; debugging (locate → repair → retest) is a separate activity.
- Cyclomatic complexity V(G)
- A white-box metric for the number of independent paths through a program: V(G) = E − N + 2 for a control-flow graph with E edges and N nodes, which also equals the number of decisions + 1. It sets a lower bound on the tests needed for branch coverage.
- Standards map
- The core standards examined: IEEE 730 (SQA processes / the SQ Plan), IEEE 830 (SRS structure and good-SRS characteristics), IEEE 1028 (software reviews and inspections), and ISO/IEC 25010 (the product-quality model). IEEE 829, IEEE 1012 and ISO/IEC/IEEE 29119 are supporting references.
- Error → fault → failure chain
- A human error introduces a fault (defect) into an artifact; when that faulty code executes on the wrong path it produces a failure (observable deviation from expected behaviour). The nine error causes (faulty requirements, design, coding, documentation, etc.) classify where the error entered.
Exam Revision & Course Integration FAQ
What are the most examined distinctions in the ELEC5618 final?
Three pairs recur across the multiple-choice and short-answer questions: verification (build it right — conforms to spec) vs validation (build the right thing — meets needs); QA (process-oriented, build quality in) vs QC (product-oriented, check quality out); and defect testing (find defects) vs validation testing (show requirements are met). Be able to give each in one line plus a short example where the two come apart. Alongside these, know the error → fault → failure chain and the standards map (IEEE 730 / 830 / 1028, ISO/IEC 25010).
What does the ELEC5618 exam look like?
It is a 2-hour closed-book exam in the formal examination period covering all lecture and assignment material. The revision session works through a mix of multiple-choice, short-answer and a scenario-based question with sub-parts. The unit outline does not publish an exact section-and-marks breakdown, so treat the question-style list as a revision guide and confirm the precise structure, weighting and date on Canvas and the USyd exam timetable.
How should I revise the practice-exam question styles?
Rehearse each style as a method, not a memorised answer: write functional 'The system shall…' requirements under a named ISO/IEC 25010 sub-characteristic; remove ambiguity from a non-functional requirement by splitting it into atomic, verifiable statements; apply P-CMM features/levels to a scenario with advantages and disadvantages; list the fault classes a static flow analysis detects; draw a control-flow graph and compute V(G) = E − N + 2 with the independent paths; and describe the reporting functionality of a test-management tool. Doing one of each end-to-end is worth more than re-reading slides.
Can AI help me revise for ELEC5618?
Yes. Sia is an AI tutor trained on how ELEC5618 is taught and assessed at the University of Sydney; it can quiz you on QA vs QC and verification vs validation, walk you through a cyclomatic-complexity graph step by step, and check whether your requirements map to the right ISO/IEC 25010 sub-characteristic. It explains the method rather than doing graded assessment for you, and the University of Sydney academic-integrity policy applies.
Where can I find past exam papers or practice for ELEC5618?
Start with the Week 13 revision session and any practice questions posted to the unit's Canvas site, plus your own lecture notes and assignment feedback. This guide's worked examples and topic maps mirror the question styles the revision lecture covers so you can self-test. There is no separate hurdle on the final in the unit outline, but confirm the current assessment rules, any practice papers and the exam timetable on Canvas.
Exam move
Build one integration map for the whole unit: requirements (IEEE 830) → V&V (verification vs validation) → testing (defect vs validation, black-box vs white-box, component vs integration) → tools (FSM/Markov) → agile and process improvement (CMM/CMMI) → standards (IEEE 730/1028, ISO/IEC 25010). Then drill the three exam-critical pairs — QA/QC, verification/validation, defect/validation testing — until you can give each in one sentence with an example where they diverge, because these dominate the multiple-choice and short-answer marks. Work each practice-exam style once from a blank page: a set of ISO/IEC 25010 requirements, an ambiguity rewrite, a P-CMM application, a static-analysis fault list, a cyclomatic-complexity graph with V(G) = E − N + 2, and a test-tool reporting answer. Keep a one-page standards grid for quick recall. Because the targeted project closes this week with a video and Q&A, rehearse explaining your quality decisions aloud. Confirm the exact exam date, structure and any rules on Canvas and the USyd exam timetable.
Working through Exam Revision & Course Integration in ELEC5618? Sia is AskSia’s AI Software Engineering tutor — ask any ELEC5618 Exam Revision & Course Integration 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.
