ELEC5618 Software Quality Engineering

How ELEC5618 is assessed

What ELEC5618 covers

ELEC5618 runs across 13 weeks of this unit of study, moving from software-quality foundations and planning (IEEE 730, ISO/IEC 25010) through requirements specification, verification and validation, testing techniques and test plans, testing tools, and quality engineering in agile and ML/AI settings.

Half the mark is the 2-hour closed-book final exam in the formal examination period; the rest is the group-project coursework, a mid-term quiz and weekly report checks. The chapters below follow the real teaching order so your revision matches how the unit was taught.

It teaches how software quality is engineered — not just tested — across the whole lifecycle: the vocabulary of quality (error → fault → failure, the Heuristic Test Strategy Model, risk = probability × impact), the standards that govern it (IEEE 730 for SQA plans, IEEE 830 for requirements specifications, IEEE 1028 for reviews, ISO/IEC 25010 for the product-quality model), verification and validation, software testing techniques (black-box and white-box, integration, object-oriented class testing), the software test plan, testing tools built on finite state machines and Markov chains, and quality engineering in agile and ML/AI settings.

It is a concept-, process- and document-heavy unit rather than a mathematical one — the single recurring computation is cyclomatic complexity (V(G) = E − N + 2), and the marks reward stating the right standard, applying the right technique, and arguing quality trade-offs clearly.

Assessment, all managed through Canvas, is half exam and half coursework: a 50% final examination (2 hours, closed book, held in the formal examination period, covering all lecture and assignment material) plus a semester-long group project delivered as three individual write-ups (Assignment 1 = 9%, Assignment 2 = 16%, Assignment 3 / targeted project = 15%), a 5% mid-term quiz (1 hour, question released in Week 7) and a 5% weekly report check (milestone checks at Weeks 3, 5, 7, 9 and 11).

No component carries a hurdle in the unit materials, and the exam's section-and-marks breakdown is not published — confirm the exact weighting, format and any permitted materials on your Canvas Assessments page and the USyd unit outline. Because the whole unit is examined together, a strong ELEC5618 result rewards steady weekly work that also protects your Weighted Average Mark (WAM).

Worked example · free

Cyclomatic complexity of a grade classifier (the signature ELEC5618 computation)

Key terms

Error → Fault → Failure

The canonical defect chain. An error is a human mistake; it plants a fault (defect/bug) in the software artifact; executing that fault can produce a failure — the system's inability to perform its required function. All three sit under the umbrella term 'defect', and software quality engineering exists to prevent failures.

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 software) meet the user's real needs. Testing reveals the presence of errors, never their absence; a successful test finds at least one error.

QA vs QC

Quality Assurance is process-oriented — it defines and evaluates processes to build quality in, ideally free of technical/managerial/financial pressure. Quality Control is product-oriented — it monitors specific results and checks conformance to standards (it leads into V&V and testing). QC activities can sit inside QA.

Cyclomatic complexity V(G)

McCabe's control-flow metric: V(G) = E − N + 2 (E edges, N nodes) = number of predicate nodes + 1 = number of independent paths = minimum tests for full branch coverage. High complexity does not prove testing adequacy — covering all paths is not covering all path combinations.

ISO/IEC 25010:2023

The product-quality model (SQuaRE). Nine product-quality characteristics — functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety — each with sub-characteristics, plus a separate 'quality in use' model. The reference frame for stating and testing non-functional requirements.

Stub vs Driver

Test doubles used in integration testing. A stub simulates a called (lower-level) module, returning hardcoded responses — used in top-down integration. A driver simulates a calling (higher-level) module, issuing the calls the real caller would — used in bottom-up integration. A sandwich/hybrid approach uses both.

ELEC5618 FAQ

Questions students ask in each ELEC5618 chapter

What is the difference between an error, a fault and a failure?

They form a causal chain. An error is a human mistake; that mistake plants a fault (a defect) in the software; when the fault is executed the system may produce a failure — it cannot do what it should. All three are covered by the umbrella word 'defect'. Naming the right link matters in exam answers: you fix faults, you prevent errors, and you observe failures. Chapter 01 · Foundations of Software Quality Engineering

What are the software error causes I need to know?

The unit teaches a nine-category classification: faulty definition of requirements, client–developer communication failures, deliberate deviations from requirements, logical design errors, coding errors, non-compliance with documentation/coding instructions, an inadequate (disintegrated) testing process, user-interface and procedure errors, and documentation errors. In a scenario question, name the primary cause and, where relevant, a secondary contributor. Chapter 02 · Software Quality in a Company

What is the difference between QA and QC in ELEC5618?

QA is process-oriented — it defines, evaluates and improves the way the team works so that quality is built in, and it should be free from schedule and budget pressure. QC is product-oriented — it checks specific deliverables and results against standards, and it leads into verification, validation and testing. A neat way to remember it: QA builds quality in, QC checks quality out, and QC activities can operate inside a QA system. Chapter 03 · Software Quality Planning, Assurance and Control

What is the difference between functional and non-functional requirements?

Functional requirements describe services the system provides — what it does in response to inputs. Non-functional requirements are constraints on how well it does them — reliability, security, performance, usability, portability and so on. Requirements should say what, not how, and every non-functional requirement needs a measurable target so it can be verified. Chapter 04 · Software Requirement Specification and Use Cases

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. Chapter 05 · Verification and Validation

What is the difference between equivalence partitioning and boundary-value analysis?

Equivalence partitioning splits the input space into classes that should behave the same and tests one value per class, cutting redundant cases. Boundary-value analysis then adds cases at the edges of those classes — just below, on, and just above each boundary — because defects cluster there. You normally use them together: partition first, then pick boundary values within and around each partition. Chapter 06 · Software Testing Techniques

What goes into a software test plan?

Scope (which package and basis documents), the testing environment (sites, hardware, people, training), the test details per test (identification, objective, cross-references, class and level, case requirements, data to record) and the schedule (time for preparation, testing, correction and regression). The IEEE 829 key contents add items such as features to and not to be tested, pass/fail and suspension criteria, deliverables, staffing, risks and approvals. A good plan is organisation-wide and starts alongside the requirements. Chapter 07 · The Software Test Plan

What is the difference between a Moore and a Mealy machine?

Both are finite state machines; they differ in where the output comes from. A Moore machine's output depends only on the current state, so it changes when the state changes. A Mealy machine's output depends on both the current state and the input, so it can change on a transition even without changing state. Otherwise they share the same states, inputs and deterministic transitions. Chapter 08 · Tools for Testing: FSMs and Markov Chains

How does agile change the QA role?

It moves quality from an end-of-line inspection to something built in throughout, and it shifts the QA person from a 'gatekeeper' who signs off at the end to a 'quality enabler' who writes test cases with developers, automates regression and integration tests, drives exploratory and usability testing, and joins backlog grooming and sprint planning. Quality becomes a shared responsibility of the whole team, supported by TDD, CI and a Definition of Done. Chapter 09 · Software Quality Engineering in Agile Environments

Why does classical testing not fully work for ML/AI systems?

Because the model's behaviour is probabilistic — the same input can produce different outputs — so you cannot simply assert an expected output the way you would for deterministic code. Quality also becomes multi-dimensional and the dimensions conflict (safety vs helpfulness, accuracy vs latency). You still test the deterministic system around the model, but the model itself is evaluated statistically with datasets, online experiments and human eval. Chapter 10 · Quality Engineering for ML/AI Systems

What are the five CMM/CMMI maturity levels?

Level 1 Initial (ad-hoc, unpredictable), Level 2 Repeatable (basic project management, repeatable on similar projects), Level 3 Defined (standardised, documented, communicated processes across the organisation), Level 4 Managed (statistical control of process and product quality with quantitative targets) and Level 5 Optimizing (continuous, data-driven process improvement). The key jump to remember is 3 → 4: from standardised processes to quantitatively controlled ones. Chapter 11 · Designing an Agile Cycle & Process Improvement

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). Chapter 12 · Exam Revision & Course Integration

How to study for the exam

Treat ELEC5618 as a standards-and-technique unit and rehearse it weekly alongside the group project, rather than cramming before the closed-book final. Build a one-page map of the standards and what each governs (IEEE 730 = SQA plans, IEEE 830 = SRS, IEEE 1028 = reviews, ISO/IEC 25010 = product quality, ISO/IEC/IEEE 29119 = testing) because fast recall pays off across the paper.

Drill the exam-critical distinctions until you can state each in one line with an example — QA (process) vs QC (product), verification ('building it right') vs validation ('building the right product'), defect testing vs validation testing, stub vs driver, Moore vs Mealy.

Practise the two techniques that carry method marks: cyclomatic complexity (draw the control-flow graph, apply V(G) = E − N + 2, cross-check with decisions + 1, list the independent paths and write one test per path) and black-box design (equivalence partitions plus the boundary set {lo−1, lo, interior, hi, hi+1}).

For the qualitative topics — the nine error causes, the ISO/IEC 25010 characteristics, the People CMM / CMMI levels, the Agile Manifesto and testing quadrants, and the ML/AI three-layer quality stack — rehearse writing short, structured 'The system shall…' requirements and clear trade-off arguments, because that is what the short-answer and scenario questions reward.

When a step won't click, ask Sia to explain that single step a different way and set you a fresh practice question in the same style; it teaches the method and checks your reasoning, and it never substitutes for your own graded work. Confirm the exam date, room, weighting and any hurdle on Canvas and the University of Sydney exam timetable.

Your AI Computer Science tutor for ELEC5618

Stuck on a hard ELEC5618 question? Sia is AskSia’s AI Computer Science tutor — ask any ELEC5618 Software Quality Engineering question and get a clear, step-by-step explanation grounded in how the course is actually taught and assessed. Read this whole study guide free, then take your hardest questions to Sia.