When you need a test column on your board
I worked in different Scrum teams for nearly a decade (and still do) and found myself doubting the usage of a test column on Sprint boards more and more.
I see others having this doubt too and therefore I share here my experiences.
You need (can use) a test column on your ticket board when
… only one task can be carried out at a time at that ticket. Development XOR testing.
But this misconceptions reduces testing to the pure interaction with the product.
Sure, for that you need something from developers. At least code, often it is a binary.
But even that is not a reason for a test column in addition to a dev column.
Some models of actual workload
This are some simplified models of what I observe regular. Reality is way more complex.
They are sufficient to tell my story.
When is a ticket changing from the dev to the test column by this distribution of the work?
=> a single In Progress column is sufficient
Testing benefits from preparation
Gathering information, making and discussing first plans, preparing test data and tools and many other are tasks in testing which can be done/started without an actual product - while, or even before, the code is written.
What are good reasons to postpone this until the development of the first version is done? Aside from a lack of time.
It would be a waste of time and being a risk by extending the feedback time for the developers.
=> a single In Progress column is sufficient
Testing can be integrated into development
I have pair-tested with developers ON THEIR PC, on their feature branch, sometimes not yet committed code changes. They even made code changes during this session and rebuild the application.
Sometimes developers gave me code changes in short frequency which I all tested withing minutes, often in a live session.
Typically with git push (they) & pull (I) and myself building the application.
=> a single In Progress column is sufficient
Testing can be done in parallel to development
It happens frequently that I interact with the product while in parallel developers still code by to basic scenarios:
- They start fixing bugs while I continue testing.
- I start testing not yet fully developed features where we agree on that I should just look at specific places. Early feedback. I test while the developers code.
=> a single In Progress column is sufficient
What about tickets?
All above is true no matter how your work is organized.
Bug tickets - Testing is here first (and also last)
Bug tickets in general about that someone found a problem, aka tested, and reported that.
Someone has to find out the scenario and causes, then developers (try to) fix it and finally it needs a test of the fix (and maybe some more loops).
Would this ticket start in a test column and the switch back to dev? …
Test needs to act first.
=> a single In Progress column is sufficient
External bug reports
Often external/others bug reports lack a information and describe problem very poor, making it hard to reproduce and know what needs to fixed.
Test needs often to act before the development.
=> a single In Progress column is sufficient
Single ticket for multiple people
Somehow you just a have single ticket, but multiple people (can) work at in parallel. You do not use sub-tasks.
This multiple people can be only developers, testers or a mixture of both. To which column would you put such ticket, especial at the mixed case?
e.g. in Jira a ticket can only have a 1 assignee
=> a single In Progress column is sufficient
A ticket with sub-tasks as instances
E.g in Scrum are often Stories used with sub-tasks.
- Either you have dedicated sub-tasks for development and testing:
- => a single In Progress column is sufficient
- And/or multiple people working on the sub-tasks:
- => a single In Progress column is sufficient, see the paragraph before.
Summary
Testing and development are ongoing tasks which can be done in parallel.
To which degree is up to your context.
Also they both are a feedback loop:
Testing informs (at least) development and development gives testing something to interact with.
This loop can be run several times in a few minutes.
Feedback is sooner better than later. Especial when developers are likely to switch do a different task.
Every ticket in a issue tracker is a (simplified) model of a more complex reality.
Especial only one assignee possible is often far from reality of team work.
By my experience people proposing separated development and test column are advocating most times from a perspective of command & control which is basically distrust.
What would you add? Contact me how you want to. I would like to read any opinion.
Published on social media : Twitter, LinkedIn
Further articles
- Katja Obring argues to Kill That Test Column with some further details.
This article was sourced by this question at twitter to which I gave some answers.