ELEC5618 · Software Quality Engineering
Software Quality Engineering in Agile Environments
Week 9 of University of Sydney ELEC5618 Software Quality Engineering positions quality engineering inside agile development: how quality is built-in rather than inspected at the end, the Agile Manifesto and its practices (TDD, CI/CD, pair programming, Definition of Done), the Agile Testing Quadrants, the Scrum framework, and the tension between agile speed and plan-driven assurance. Assignment 2 is due this week.
What this chapter covers
- 01How agile redefines QA: quality built-in not inspected at the end; early and continuous testing; quality a shared responsibility
- 02The Agile Manifesto's four values (individuals/interactions, working software, customer collaboration, responding to change) and the twelve principles
- 03Agile practices that support quality: TDD, pair programming, continuous integration, continuous delivery, refactoring, Definition of Done
- 04Test-Driven Development: write a failing test first, then code to pass it, in short cycles → high coverage
- 05Agile Testing Quadrants (Crispin & Gregory): Q1 unit/component, Q2 functional/story, Q3 exploratory/UAT, Q4 performance/security; 'Shift Left'
- 06Agile metrics: code coverage, defect leakage, lead/cycle time, DoD adherence; velocity is a planning metric NOT a quality metric
- 07QA role shift: from gatekeeper to quality enabler/facilitator
- 08Scrum: roles (Product Owner, Scrum Master, Developers), events (Sprint, planning, daily scrum, review, retrospective), artifacts (backlogs, burndown)
Placing testing activities in the Agile Testing Quadrants
- +1State the two axes: business-facing vs technology-facing, and supporting-the-team vs critiquing-the-product. Every quadrant is one combination of the two.
- +1(a) Automated unit tests = Q1: technology-facing and supporting-the-team (they guide development and are automated).
- +1(b) Automated story/acceptance tests with the customer = Q2: business-facing and supporting-the-team. (c) Exploratory testing of the checkout flow = Q3: business-facing and critiquing-the-product (manual, judgement-based).
- +1(d) Load and security testing = Q4: technology-facing and critiquing-the-product (tool-based '-ility' testing). The overarching principle is Shift Left — test early and often, letting exploratory testing complement automation.
Key terms
- Built-in quality
- The agile principle that quality is engineered continuously through the work (via TDD, CI, reviews and a Definition of Done) rather than inspected in at the end, and that it is a shared responsibility of the whole team.
- Test-Driven Development (TDD)
- A practice of writing a failing test first, then the minimal code to make it pass, in very short cycles. It forces you to define inputs and outputs up front and yields high test coverage as a by-product.
- Continuous integration / delivery (CI/CD)
- CI is the constant integration of new code with automated builds and tests for early fault detection and fast feedback; CD extends that to reliably releasable builds, supporting reliability and performance efficiency.
- Agile Testing Quadrants
- Crispin & Gregory's model on two axes (business- vs technology-facing, supporting vs critiquing): Q1 unit/component tests, Q2 functional/story tests, Q3 exploratory/UAT, Q4 performance/security. The guiding idea is Shift Left.
- Definition of Done (DoD)
- An explicit, shared checklist of the quality conditions a work item must meet before it counts as complete (e.g. tested, reviewed, documented), making quality expectations concrete.
- Scrum roles
- Three roles: the Product Owner (owns and prioritises the product backlog, liaises with stakeholders), the Scrum Master (facilitates the process) and the Developers (build the increment). Each sprint (a timebox of at most one month) yields a potentially releasable increment.
Software Quality Engineering in Agile Environments FAQ
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.
What are the Agile Testing Quadrants?
A model on two axes — business-facing vs technology-facing, and supporting-the-team vs critiquing-the-product. Q1 (technology-facing, supporting) is unit and component tests; Q2 (business-facing, supporting) is functional and story tests; Q3 (business-facing, critiquing) is exploratory, usability and acceptance testing; Q4 (technology-facing, critiquing) is performance, load and security testing. The principle running through them is Shift Left — test early and often.
Is velocity a measure of quality?
No — that is a common trap. Velocity is a planning metric that helps a team forecast how much work it can take on; it says nothing about the quality of what was built. Quality-oriented agile metrics are things like code coverage, defect leakage rate, lead and cycle time, and Definition-of-Done adherence.
Can AI help me with agile quality engineering?
Yes. Sia can quiz you on the Agile Manifesto values, sort testing activities into the four quadrants, and walk through the Scrum roles, events and artifacts. Use it to rehearse the frameworks; it does not do graded assessment, and the University of Sydney academic-integrity policy applies.
Exam move
Learn the frameworks as recitable structures: the four Agile Manifesto values, the quality-supporting practices (TDD, pair programming, CI/CD, refactoring, DoD) with the quality focus of each, and the Scrum roles, events and artifacts. Practise placing testing activities into the Agile Testing Quadrants by naming the two axes first — this is a clean short-answer question. Commit two traps to memory: quality is built-in not inspected at the end, and velocity is a planning metric not a quality metric. Be ready to describe how the QA role shifts from gatekeeper to enabler. Assignment 2 is due this week, so connect these practices to your own project workflow as you revise. Confirm the exam format on Canvas.
Working through Software Quality Engineering in Agile Environments in ELEC5618? Sia is AskSia’s AI Software Engineering tutor — ask any ELEC5618 Software Quality Engineering in Agile Environments 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.
