Our QA department is moving towards a Continuous Integration/Continuous Deployment (CI/CD) model. We want to use Kanban to manage our automated testing pipeline and manual exploratory sessions. How do we represent "Automated Testing" on a Kanban board when it’s a non-human process? Does it get its own column, or is it just part of the card's movement through the board?
3 answers
In a CI/CD environment, "Automated Testing" should definitely be a visible stage on your Kanban board. Even if a human isn't "doing" the work, the work is still "in progress" and occupies capacity in your pipeline. If the automation suite takes 4 hours to run, that’s a 4-hour lead time. By having a column for it, you can see if items are stacking up there, which might indicate you need more server resources for parallel testing. This visibility helps you identify if the bottleneck is your code quality (manual) or your infrastructure (automated).
What happens to a card on your board if the automated build fails—does it go back to the "In Progress" dev column or stay in QA?
We treat "Automation" as a buffer. It helps us see the queue before exploratory testing starts, ensuring the testers only touch stable builds.
That’s a smart way to look at it, Dorothy. Treating it as a buffer really highlights the hand-off points where most delays actually occur.
Great question, Richard. In our flow, if the automation fails, the card is tagged with a red "Failed" sticker and moved back to the "Ready for Dev" column. However, we keep it at the top of the queue because fixing a regression is always a higher priority than starting a new feature. This prevents the "ping-pong" effect from dragging down our overall cycle time metrics.