Drop the test column. Now what?
Why teams pushback, and what to replace it with
When teams start talking about removing the test column, I find that there can be quite a varied response to it. From people wanting to drop it immediately to others thinking that it’s reckless and will cause confusion.
Which is understandable, most teams have an “In Test” column. Why is it a problem now? It gives the team a clear signal where work is up to, what still needs attention and where things are queuing up.
The problem is that the column can reinforce testing at the end of the development process, and that testing is someone else’s responsibility (testers).
The thing is, the column is not good or bad, it’s more about what it signals to the team and what to do if it disappears. Because if you drop the column without replacing the signal, the team will lose visibility of work, but if you keep it, you reinforce end-of-the-line testing.
In this post, I want to look at some of the common pushback teams raise, what is often sitting underneath it, and what to put in place instead.
For paid subscribers, I’ve shared a practical companion to this post that goes deeper into six better signals than a test column, including what each one helps prevent, what it helps reveal when work starts to stall, and how they support coordination, shared ownership, and flow. Read it here: What to use instead of an “In Test” column
Common pushback
1. We’ll lose visibility of where work is
The pushback here is that the “In Test” (or any column for that matter) gives you a very quick way to see where work is, so by removing it, how will you know where work is up to? But having this column often reinforces the view that testing happens at the end, not throughout the development life cycle.
What could you do? Agree on what “good visibility” would look like if there is no column. For instance, ticket ageing, blockers, what is left to prove, etc. Add a lightweight checklist within tickets so status isn’t tied to columns. Remember, tickets are a record of a conversation, not a replacement for them.
2. At least the column shows us where the bottleneck is
The pushback here is that removing the column will now hide the constraint and make it harder to see, and it will make them normal. But this also reinforces the idea that testing is a tester's problem, not a team one.
What could you do? Set Work in progress (WiP) limits on the “In progress” column. If tickets are ageing for longer than a set amount of time, agree on how the team will approach the problem. For instance, they could swarm on the work, look to slice work smaller, how things can be descoped or what can be parked while the current work is completed. Make “stuck work” a team default to tackle.
3. Our automation is not strong enough yet
The pushback here is that the team's tooling and automation aren’t good enough to ensure every ticket is ready to ship without manual checks. The “In Test” column is programmatic scaffolding while the tooling comes about. But what often happens is that scaffolding becomes the building. Adding the pressure to deliver means the team never gets the time to build the tooling, or the sole SEIT is left to build it (while juggling other tasks) and never manages to keep on top of it.
So manual verification remains the default method to gain feedback on the product. However, removing the test column can act as a catalyst for faster feedback with shared team ownership. Usually, the developer on the team works with the SEIT to build the infrastructure and tooling needed for rapid automated feedback. But if only the column has been removed without the acknowledgement that the engineering team must do this work, then all you will get is confusion and friction, not progress.
What could you do? Track capability growth on a ticket basis to show progress in building out tooling and automation. Run small experiments that build capability over time rather than trying to go for a one big bang approach. Set the precedent that quality (and all tooling and automation that support it) is a team responsibility, not the sole responsibility of SEIT/Testers, and therefore requires engineering support.
4. We still need a coordination point for handovers
The pushback here is that the column helps people coordinate what work needs to happen and when. This is especially true when people work different core hours or in remote teams. The other argument is that the handover will still happen, but it’s no longer visible, making it harder to tackle.
This is very likely to happen when the “finish together” conversation has not happened before removing the column. Where the precedent is set that completing work is a team responsibility, not an individual one. If work is in progress, everything should be done to keep it moving, no matter who started it or who continues to work on it. Pairing and team swarming on tickets should be considered the norm. Pairing should take into consideration the working hours of the pair, where one person always stays with the ticket for continuity and helps the returning pair get back up to speed - again, documentation is a record of the discussion, not the discussion.
What could you do? Develop team “finish together” behaviours such as: No solo ticket work unless explicitly called out and warned against, testers in kick-off planning, pairing on risky bits, PR review expectations, and a shared release confidence check before tickets are considered Done.
5. Removing the column will not actually change behaviour
Pushback here is just because you dropped the test column doesn’t mean anything changes. But if you don't do so, nothing changes either. The idea of dropping the test column (amongst many other reasons) is to align workflow with intent - testing is a team responsibility and happens throughout the development process.
What could you do? To encourage different day-to-day habits, include prompts in refinement/kick-off sessions, such as risk, test approach, and automation expectations. Keep them lightweight as a nudge for the team to make sure they are considered and owned by the whole team.
6. Manual testing is still real, so we need somewhere to show it
Pushback here is that dropping the test column is about eliminating manual testing completely from the dev cycle. It’s not, it’s about spread testing and the responsibility to do it throughout the dev cycle.
Having the column also helps the team acknowledge that they still have some manual testing to do. E.g. exploratory, accessibility, integration, release candidate testing and needs to be handled. Dropping the test column could give the impression that this is no longer needed. Without a visible signal, manual work can become hidden work. The risk here, though, is that keeping the column can create the impression that this is how testing is handled in the team. Everyone still feels they have that “safety net” of manual testing at the end, and that all tickets will always have some eyes on it, which could cause people to be lax with their dev testing.
What can you do? Name manual work explicitly (exploratory, accessibility, integration, release candidate testing, etc.) and capture it as tasks within the ticket so it stays visible without becoming a phase.
What is usually underneath the pushback?
The patterns I’m seeing suggest there are broadly three debates underlying these concerns.
1. Improve the system first
This group is concerned with workflow coordination and is thinking about how work moves across the board. This usually comes from workflows that look like:
Development -> Manual verification -> Done
From that perspective, the test column is useful because it helps them coordinate their work. The preferred approach here is to improve the system of work first, then drop the column.
2. Drop the column first
This group is concerned with shared ownership of quality. They are trying to break down the existing behaviours around testing as a phase at the end of the development lifecycle and ultimately want to encourage shared ownership of testing. This group want to shift to a desired system that would look something more like:
Collaborative development + Automated verification + Exploratory testing -> Done
The preferred approach here is to drop the column first to force the behaviour change.
3. Replace the signal
This group is thinking about the flow of work. They recognise that the test column provides a signal to the team, but not always the best one. What matters more here is helping the teams find better signals. Signals that show where work is slowing down and what can be done to alleviate it.
The preferred approach here is to drop the column to kickstart experiments about how the team focuses on finishing work as a team, rather than as individuals, who stick to their roles.
This is where the restaurant analogy from my queueing quality post comes in. I’m not arguing about the “In Test” columns but about queueing work and improving feedback speed.
So what do you do?
The reality is that most teams need a bit of improve the system and drop the column. Because if you wait to improve the system before dropping the column, end-of-the-line testing cultural habits will linger, with no impetus to improve. But if you just drop the column, you’ve lost the signal about how work flows through the team, and if you don’t replace it, the team loses visibility and control over the system.
Replace the “In Test” column with better signals
Teams that successfully remove the column usually put better signals in its place. For example:
Definition of Done checks so it is clear what must be true before work is complete
PR-level automation gates so feedback happens earlier in the development life cycle
Work-in-progress (WIP) limits so the team sees overload sooner
Test tasks inside the tickets so verification stays attached to the work
Tester and developer pairing on higher-risk work
Cycle time and ageing work so that stuck work becomes visible before a queue forms
Read the deep dive of these better signals here: What to use instead of an “In Test” column
These signals do a better job because they help with three things at once:
Workflow coordination
Shared ownership of quality
Flow visibility
These signals help teams be more proactive about building quality into their processes, but also reactive to when that quality slips.
Close
So, should you just drop the test column and hope for the best? No.
If you remove it without changing how the team works, the same habits usually reappear elsewhere: labels instead of columns, hidden handovers, late manual verification, automation outside the build pipeline, and teams starting more work before finishing what they already have in flight.
But keeping the column has a cost, too. It reinforces the idea that testing happens at the end, that it is someone else’s responsibility, and that work should move in phases rather than flow through the team.
What we need instead are better signals. Signals that show when work is slowing down, where confidence is missing, and what the team should do next.
That is part of the work of a quality engineer.
Not owning testing as a phase, but helping the team understand how quality emerges through the system, where it gets delayed, and what needs to change to improve flow and feedback.
Because the goal is not to manage columns better.
It is to stop queueing quality at the end.
If you want the practical follow-up to this, I’ve put together a deeper guide for paid subscribers on what to use instead of an “In Test” column. It breaks down six better signals teams can use to coordinate work, share ownership of quality, and spot queues earlier, plus what each one helps prevent and what to watch out for: What to use instead of an “In Test” column.