Why a test column on boards is a problem

I often see on boards columns like “Open”,  “Dev” or "In Progress" (but still just being for developers) and next to them “Test” or “QA.”. And ticket moving through it and handovers happening between columns. Developers stop working once they are done (with a first version) and testers just start once they got the ticket handed over. Sequentially working on it instead of doing it in parallel where doable.

In this article, I explain why I see this structure as a problem, how it can cause issues if enforced, and what possible alternatives exist.

This is an updated version of an already existing article. Also available in German.

You 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.

The notion that testers can only begin after development has started is based on the misconception that testing is reduced to mere interaction with the product. Like an executable (of a very final version) to exist would a precondition for any testing work.
As if no preparatory work were possible, or as if interaction with the product could not take place in parallel with development (e.g., at various intermediate stages).

A command-and-control mentality may be another root cause. This is not conducive to constructive collaboration and rapid feedback.

Some models of actual workload

This are some simplified models of what I observe regular. Reality is way more complex.

When is a ticket changing from the Dev to the Test column by this distribution of the work???

=> Test after Dev is a problem

Testing benefits from preparation

Gathering information, planning (e.g. coverage and approaches), preparing test data and tools and many other are tasks in testing which can be done/started without an actual product - before or while 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.

=> Test after Dev is a problem

Testing can be integrated into development

Here are two examples from my daily work where I’ve collaborated closely with developers, and we couldn’t even say for sure which column a ticket was currently in.

1. Pair / Ensemble testing with developers on their computers. They showed me the application, and I advised them on what to try. During these sessions, my colleagues made code changes and, when necessary, rebuilt the application so they could test it again immediately.
2. I can build and deploy the product locally myself. With this setup, developers send me code changes at short intervals (git push & pull), which I then test within minutes—often while we’re on the phone or chat.

=> Test after Dev is a problem

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.

=> Test after Dev is a problem

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. And often, especial when coming from the customer, they describe mostly symptom and don't give a good manual of how to reproduce and exact details.

A tester 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.

=> Test after Dev is a problem

Single ticket for multiple people

Somehow you just a have single ticket, but multiple people (can) work at in parallel. Maybe you use sub tasks, but you use them per sub topic and not per task / craft.
The people can be only developers, testers or a mixture of both. To which column would you put such ticket, especial at the mixed case?
And e.g. in Jira a ticket can only have a 1 assignee

=> Test after Dev is a problem

Summary

Testing and development are tasks that can generally be carried out in parallel. Just because no code has been written yet doesn't mean that testers have nothing to do.

Also they both are a feedback loop:

Testing informs (at least) development and (at least) development gives testing something to interact with.

This loop can be run several times in a few minutes.
Feedback is sooner better than later. If developers have already switched contexts, it takes them longer to get back on track.

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. 

Alternatives

Here are some ideas what to do instead.

• 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.
• 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.
• 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.

Others say the same - further articles

There are multiple people advocating the same goal.

• Bart Vanherck: You don't need a test column
• Ben Linders: Deliver Faster by Killing the Test Column
• Daniel Knott: Delete The Test Column
• Katja Obring: Kill That Test Column
• Wayne Roseberry:
  • A "testing" column represents testing as a monolithic black box. It says nothing of what the testing work is or offers any notion of how long it ought to take.
    I like the way session-based test management breaks testing into visible, easy to schedule activities. I prefer testing being a mix of either be an assumed part of doing the development work, or the testing sessions on the schedule as explicit activities with their own card moving across the status columns.
• Ben Fellow
  • The test column often doesn't make much sense when the dev column isn't even the "dev" column, but "in progress", like testing doesn't mean the task in still in progress. It makes even less sense when you consider development still goes on in the "test" column due to bug fixes or further changes. If anything, the test column should be at least "testing and potentially some more development still".
    Removing work items from the board altogether and reducing status columns to just "Todo > WIP > Done" with sub-tasks for all activities related to the work item is so much better, and allows multiple different activities assigned to different people in a team that can be completed at the same time.

What would you add? Contact me how you want to. I would like to read any opinion.

Published on LinkedIn