Module 2 · Software development lifecycle

Agile for Testers

By the Mutqan Soft QA team · · 17 min · Beginner

Agile is an approach to building software in small, frequent increments of working product, with the people who need it involved throughout. It is defined by the four values and twelve principles of the Manifesto for Agile Software Development, published in 2001. Agile itself is not a single method: approaches such as Scrum and Kanban, the next two lessons, put it into practice.

For a tester, the biggest change from the sequential models of the previous lesson is timing: testing happens inside every short cycle, not in a phase after development. When the team builds a “save my address” feature, the tester asks, before coding starts, how many addresses a customer may keep.

Why it matters

In a sequential project a misunderstood requirement can stay hidden for months. In Agile each piece of work is specified, built and tested within days, so a misunderstanding found then usually costs a conversation and a small fix, not a redesign. But there is no test phase to absorb delays: if testing is not part of every cycle, untested work piles up and problems reach users quickly.

For the tester, Agile changes when and how you work more than the techniques you use: the same skills, applied earlier, in smaller pieces and in constant conversation with developers and the product owner.

The Agile values and principles, read by a tester

The Manifesto has two parts: four values and the twelve principles behind them. Several principles shape testing: deliver working software frequently, from a couple of weeks to a couple of months, preferring the shorter timescale; welcome changing requirements, even late in development; business people and developers work together daily; working software is the primary measure of progress; and at regular intervals the team reflects on how to become more effective and adjusts.

The four values are preferences: the item on the left is valued more, but the item on the right still has value. Each one changes a tester’s habits:

  • Individuals and interactions over processes and tools: five minutes with the developer often settle more than a long defect thread.
  • Working software over comprehensive documentation: progress is tested, running software. Testers still record just enough: acceptance criteria, notes, defect reports, automated checks.
  • Customer collaboration over contract negotiation: the product owner is reachable, so you ask “is this what you meant?” instead of arguing over a specification.
  • Responding to change over following a plan: requirements may change between cycles, so tests must be cheap to update and regression checks are largely automated.

How testing fits: early, often and shared

Three ideas describe the tester’s place in an agile team; the timeline below contrasts one story with the sequential flow.

  • Early involvement: the tester discusses a story before it is built, usually in backlog refinement; many teams call this meeting of business, development and testing views the “three amigos”. A question such as “what if the discount code has expired?” becomes an example, then an acceptance criterion, then a test.
  • Short feedback loops: automated checks run on every change, the tester explores each build as soon as it is deployable, and defects are reported, fixed and retested within the cycle, often within hours.
  • Whole team: ISTQB describes a whole-team approach, a practice that comes from Extreme Programming, in which everyone is responsible for quality and anyone with the necessary knowledge and skills may do any task. Testers help business representatives, such as the product owner, create suitable acceptance tests, and agree the test strategy and automation approach with developers. Where high test independence is needed, as for safety-critical systems, ISTQB notes the approach may not be appropriate.
Sequential: testing waits for a phase of its own
  requirements -> design -> build -> test phase -> release
                                     ^ first feedback on the requirement, weeks later

Agile: one story inside a two-week iteration
  Before  refinement  tester asks for examples; they become acceptance criteria
  Day 1   planning    team agrees how the story will be tested and by whom
  Day 2   build       developer writes code and component tests; tester prepares data
  Day 3   test        automated checks run on each change; tester explores the build
  Day 3   fix         defect reported, fixed and retested the same day
  Day 4   done        acceptance tests pass and join the automated regression suite

The agile testing quadrants

The agile testing quadrants, defined by Brian Marick and described in Lisa Crispin and Janet Gregory’s book Agile Testing and in the ISTQB Foundation syllabus v4.0, map the kinds of testing a team needs. Business-facing tests use terms a business expert understands; technology-facing tests use the terms of the code. Tests that support the team guide development; tests that critique the product measure its behaviour against expectations.

Agile testing quadrants: business- or technology-facing tests that either support the team while it builds or critique the product it built, with the typical tests of each and how they are usually run. Conceptual model
Expressed in terms ofWhat the tests do
Support the teamguide development as it happensCritique the productmeasure its behaviour against expectations
Business-facingwhat a business expert understandsQ2 · Functional tests, examples, user story tests, UX prototypes, API tests, simulationsCheck the acceptance criteria · manual or automatedQ3 · Exploratory, usability and user acceptance testingUser-oriented · often manual
Technology-facingthe code and its designQ1 · Component (unit) and component integration testsWritten by developers · automated in CI on every changeQ4 · Performance, load, security and other non-functional tests; smoke testsOften automated · specialised tools
  • Usually automated
  • Manual or automated
  • Usually manual

The numbers only name the quadrants; they are not an order of work.

The numbers are names, not an order of work. When planning a story or a release, ask which quadrants the change needs and who covers each; an empty quadrant is a blind spot.

  • Q1, technology-facing, supporting the team: component (unit) and component integration tests, written by developers and automated in continuous integration (CI).
  • Q2, business-facing, supporting the team: functional tests, examples, user story tests, user experience prototypes, API tests and simulations that check the acceptance criteria; manual or automated.
  • Q3, business-facing, critiquing the product: exploratory, usability and user acceptance testing; user-oriented and often manual.
  • Q4, technology-facing, critiquing the product: performance, load, security and other non-functional tests except usability, plus smoke tests in the ISTQB list; often automated with tools.

Try it: Test Scenario Generator

Worked example: one story through an iteration

Story: “As a shopper, I want to apply a discount code at checkout, so that I pay less.” In refinement the tester asks: can one order use two codes? What happens with an expired code? Are codes case-sensitive? The answers become acceptance criteria with examples, and the team plans the testing by quadrant:

  • Day 3: exploration finds that removing an item after applying the code keeps the old discount. It is fixed and retested the same day, and the scenario joins the automated Q2 checks that run on every change.
Story: apply a discount code at checkout

Q1  developers     unit tests: 10% of 200.00 -> 20.00
                   15% of 99.99 -> 15.00 (the agreed rounding)
Q2  tester + devs  acceptance tests from the examples, automated:
                   SAVE10 on a 200.00 SAR basket -> total 180.00 SAR
                   expired code -> rejected with the expiry message
                   second code on the same order -> rejected
Q3  tester         30-minute exploratory session: remove items after applying
                   the code, back button, two browser tabs, Arabic layout
Q4  tester + devs  many wrong codes in a row -> rate-limited (own test env only)
                   response time of code checks under campaign load

Try it: Acceptance Criteria Generator Try it: User Story → Test Scenarios

Common mistakes

  • Reading “working software over comprehensive documentation” as “no documentation”. Keep what the team will need again.
  • Waiting until a story is completely finished before testing it, which turns each iteration into a small waterfall.
  • Taking “whole team” to either extreme: assuming testers are no longer needed, or that the tester alone owns quality.
  • Treating the quadrants as a sequence (Q1, then Q2…) or as a quota that every story must fill, whatever the risk.
  • Re-running the whole regression suite by hand every iteration instead of automating the stable checks.

The QA perspective

Much of a tester’s influence on an agile team comes before execution: in refinement and planning, ask for examples, edge cases and the risk of each story, and say so when a story cannot be tested as written. During the iteration, test the first deployable build rather than the finished story, and share findings in the daily conversation.

Record what the team will need again: examples, exploratory session notes, new automated checks and open risks. Defects fixed the same day are often handled by conversation; anything deferred or found later goes into the tracker. In the retrospective, raise process problems such as stories reaching testing on the last day.

Practice exercise

Plan the testing for a reorder story

Your task

You are the tester in refinement for this story, before any code exists: “As a registered customer, I want to reorder a previous order in one tap, so that I can buy my usual groceries quickly.” Draft acceptance criteria: each delivered order in the history has a “Reorder” button that adds all its items to the cart at today’s prices.

Steps
  1. Write four questions the draft criteria do not answer.
  2. Write one or more test ideas per quadrant, and who would do each.
  3. Mark which ideas you would automate and which stay manual.
  4. Name one planning agreement that keeps testing from piling up on the last day.
Show the model answer
Model answer

Questions: What happens to an item that is out of stock or no longer sold? Are the items added to a cart that already has items, or is the cart replaced? Do quantity limits on promoted items apply? Can cancelled or returned orders be reordered?

Q1 (developers): unit tests for copying order lines into the cart. Q2 (tester with developers): acceptance tests from examples, such as 3 ordered items giving the same 3 at today’s prices, or one discontinued item giving 2 items and a message naming it.

Q3 (tester): exploring a very old order, two devices at once, and the out-of-stock message in Arabic and English. Q4 (tester and developers): response time for a large order, and a check on the team’s own test environment that changing the order id cannot reorder another customer’s order.

Automate Q1, Q2 and the order-id check, which must run on every change; keep Q3 manual; run the Q4 response-time check with a tool before release. In planning, agree to deploy the basic reorder path first, so testing can start on day 2 or 3.

Frequently asked questions

Is Agile the same as Scrum?

No. Agile is the set of values and principles in the Agile Manifesto. Scrum is one framework that applies them, with its own accountabilities, events and artifacts; Kanban and Extreme Programming (XP) are other approaches agile teams use. The next lessons cover Scrum and Kanban from a tester’s point of view.

If quality is the whole team’s job, do agile teams still need testers?

The whole-team approach means everyone shares responsibility for quality, not that testing skills stop mattering. Many agile teams include testing specialists who design tests, explore, coach others and point out blind spots. Some contexts, such as safety-critical systems, also require more independent testing.

Do I need tests in all four quadrants for every story?

No. The quadrants are a thinking tool, not a quota. A small text change may need one Q2 check and a quick look; a new payment flow may need all four. Decide by risk, and use the quadrants to make sure the decision is deliberate rather than an oversight.

References

Tools

Practise with Mutqan tools

Test Scenario Generator

Generate high-level test scenarios covering functional, negative, security, usability and compatibility angles for a feature.

Test Design

Risk-Based Test Generator

Score features by likelihood and impact, then generate a prioritised risk-based test plan.

Test Design

Go deeper

Your progress on this topic

Part of the QA Roadmap

Before this topic