Kanban for Testers

Why it matters

Started but unfinished work costs effort, delivers nothing yet and hides defects nobody has looked at. Without limits, developers keep starting stories while finished code queues in front of testing; feedback arrives days late, and testing looks like the bottleneck although the cause is upstream: too much work was started.

Kanban makes this visible and fixable: the board shows where work waits, WIP limits stop queues growing, and flow metrics replace feelings with facts. Because the team finishes work before starting more, Kanban also supports the whole-team approach of ISTQB CTFL v4.0, where quality is everyone’s job, not a stage at the end.

Visualise the work, limit WIP, manage flow

Teams often sum Kanban up as three habits: visualise the work, limit WIP and manage flow. The Kanban Guide groups the same ideas into three practices: defining and visualising a workflow; actively managing the items in it, which means controlling WIP, keeping items from ageing unnecessarily and unblocking blocked work; and improving the workflow.

• Visualise: each column is a workflow state, and the team writes down where an item counts as started and where as finished. Explicit policies say what a card needs before it moves, such as "enters Test only when deployed to the test environment". The Kanban Guide collects these decisions in the Definition of Workflow, which also states how WIP is controlled and a service level expectation (SLE): a forecast, based on past cycle times, of how long an item should take from start to finish.
• Limit WIP: WIP is the number of items started but not finished, and a limit per column or per board caps it.
• Pull, do not push: start an item only when there is a clear signal of capacity, such as a free place under the limit. A full column downstream means help there, not start something new.
• Manage flow: spot cards that stop moving, remove what blocks them and finish the oldest first. Change one policy or limit at a time and check whether flow improved.

Testing as a column vs quality built in

A first board often reads Backlog, Develop, Test, Done, and it encodes a handover: a developer calls a card finished, moves it to Test and starts the next story. Test becomes a queue, and a defect sends the card back to someone now busy elsewhere.

Building quality in means testing happens in every column. Kanban prescribes no columns, so these are policies the team agrees:

• Ready: the card has testable acceptance criteria, and the developer and tester have agreed the main test ideas.
• Develop: unit and API checks are written with the code, and the tester explores early builds.
• Test: the column has a WIP limit, and anyone on the team can pull testing work or pair with the tester.
• A defect found on a card is fixed on that card before it moves on; a defect in finished work becomes a new card.
• Done: finished includes tested, as the Definition of Done does in Scrum.

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

Flow metrics: WIP, cycle time, lead time, throughput

The Kanban Guide names four flow measures. Each needs only a card’s start and finish dates, which a tester can read from the board history.

The measures are linked. Over a reasonably stable period, average cycle time is about average WIP divided by average throughput (Little’s Law). With 10 cards in progress and 5 finished a week, a card takes about two weeks; with 5 in progress, about one week. Limiting WIP shortens cycle time without anyone working faster.

• WIP: items started but not finished, counted at one moment.
• Cycle time: the elapsed time from when an item started to when it finished.
• Work item age: the time since an unfinished item started. A card older than most finished cards, or older than the SLE, needs help today.
• Throughput: the number of items finished per unit of time, for example per week.
• Lead time is not defined in the Kanban Guide. Many teams use it for the span from request to delivery, including the wait before work starts; others treat it as cycle time. Agree start and end points before comparing numbers.

Try it: Date Difference Calculator

Worked example: unblocking a test queue

Three developers and one tester work without WIP limits and finished 12 cards in the last four weeks: a throughput of 3 a week. On Monday 11 cards are in progress, six in Test, the oldest 29 days old (board below). WIP has stayed at about this level for weeks, so Little’s Law points to an average cycle time of about 11 / 3 ≈ 3.7 weeks.

"The tester must test faster" is the wrong conclusion: the queue in Test is a symptom of starting too much. The team responds:

• It sets limits of 4 for Ready, 3 for Develop and 2 for Test. The board starts over its limits, so nobody starts a card until it is back under them.
• While Test is full, developers pair with the tester on the oldest cards, add missing API checks and fix defects on the cards where they were found.
• In this example, four weeks later about 5 cards are in progress and throughput is 3 to 4 a week, so Little’s Law now points to an average cycle time near 5 / 3.5 ≈ 1.4 weeks.

BEFORE  (no WIP limits; 3 developers, 1 tester)
Ready   | Develop | Test              | Done
S-50    | S-44    | S-31   age 29 d   | 12 cards in the last 4 weeks
S-51    | S-45    | S-33   age 25 d   | throughput: 3 per week
        | S-46    | S-35   age 22 d   |
        | S-47    | S-38   age 18 d   |
        | S-48    | S-40   age 15 d   |
        |         | S-42   age 11 d   |
WIP = 5 + 6 = 11 cards  ->  average cycle time ~ 11 / 3 = 3.7 weeks

AFTER  (WIP limits in brackets)
Ready [4] | Develop [3] | Test [2] | Done
Policies: - while Test is full, nobody starts a new card: help finish one
          - a defect is fixed on the card where it was found
          - a card is Ready only with agreed acceptance criteria and test ideas

Frequently asked questions

References

• The Kanban Guide (May 2025)Orderly Disruption Limited and Daniel S. Vacanti, Inc. · 2025Kanban as a strategy for optimizing the flow of value: defining and visualizing a workflow, actively managing items in it, improving it, and the four flow measures — WIP, throughput, work item age and cycle time.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Foundation Level Agile Tester (CTFL-AT)ISTQBISTQB's foundation-level extension on testing within agile teams; ISTQB is retiring it (English exams until 6 May 2027) in favour of CTFL v4.0 and CTAL-AT.