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 / QA column on boards more and more.
I see others having this doubt too and therefore I share here my experiences and some alternatives

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:

1. They start fixing bugs while I continue testing.
2. 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 LinkedIn

Alternatives

Here are some ideas what to do instead.

• People oriented:
  • Note in the ticket all people who are working on it.
    • You can add a state by a word or icon to show who is still working and who is finished.
• Task oriented:
  • Add a list of tasks in the ticket and add names to them. Here goes the same for state.
  • Use sub tasks and assign them. They have already a state field. I suggest to have a simple workflow here.
• Some ideas what task you could add for testing:
  • • Prepare X, Test Y, Review/Debrief Z
      • When testing covers multiple, separate topics and people you can add multiple test sub task.
    • When using Session-Based Test Management (Wiki, Article) you can create a sub task for every session
    • Need to prepare data ? Need to develop or enhance a tool? Need to learn the product? Need to … whatever? Add a task.

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.