Kill the test lane

Transitions are hard. Contrary to what some people might want you to believe, humans don’t adopt well to change. When encountered with unforeseen or changing situations we try to adapt by grasping on to elements we feel comfortable with and that are not affected (we think) by the changes. A lot of organizations have been moving towards a more Agile approach when it comes to software development. That’s quite a big chance from the waterfall methodology most people are accustomed to. It’s no secret that, especially in the earlier stages of the transition, most sprints are just mini waterfall projects compressed into 2 weeks sprints. That’s fine. Over time, when teams get more mature and realize what Agile is about, the mini waterfall sort of disappears and the true benefits of Agile become clear.

However…

… as so often seen, testing is getting a different treatment. One of the area’s where this is most obvious is when looking at the scrum boards of teams. The outlines are always pretty clear: on the left we have a to do lane, and all the way to the right we usually see a done lane. The interesting bit is in between. There are many variations but usually there’s an in progress lane, in review, pull request created and something like ready for PROD or whatever. And then there is the test lane…

I think I hate the “in test lane” even more than burn down charts, velocity sheets and spreadsheets with all other kinds of “useful” metrics. Very often the test lane becomes the last straw teams can grasp on to in light of all the changes they need to deal with. “At least we have testing to hold on to.” Yeah, only you don’t. If there’s one thing that is impacted radically by switching from waterfall to Agile, it’s testing. It always amazes me how little people seem to realize this.
Having a test lane is opening the gates to all kinds of false assumptions and terrible behavior that have nothing to do with proper testing or test automation within an Agile team. So, let’s take a closer look at what I’m talking about.

Testing is not a phase

Having a separate test lane implies that testing is a phase during development. While true in the old waterfalls days, within Agile, testing is a continuous process that is done on multiple levels during various stages of development. Testing even starts before code is written by going over a user story during refinement and talk things over. You can already prevent a lot of bugs by just asking the developers what their approach to a certain story would be. That way you can tackle a lot of (false) assumptions. Besides this, there’s also unit and integration testing during the creation of a feature, some regression testing after the feature is finished and probably also some acceptance testing when a feature is deemed ready. And there are many, many more forms of testing that we don’t even talk about here for the sake of simplicity.
All these tests are performed during various stages of development. Because of that, only very little of the testing will accidentally coincide with the in test phase anyway, making it a useless thing to have on your scrum board.

Testing is not just the tester’s responsibility anymore

A separate test lane encourages bad behavior. I’m not saying this is always the case, but in my experience it makes it way too easy to fallback into a certain approach about software development and quality control. Developers eventually are just going to put stuff there of which they are not even sure it works. Let the tester figure it out.
First off, it’s not the job of the tester (or anyone in particular) to sign off on things.
Secondly, having a gatekeeper in place to check everything for you, results in just building things following a mini waterfall trajectory. There is no incentive for a developer to try to truly work in small iterations. User stories and features should be small, simple, maintainable, controllable and testable. Having a safety net in the form of a test lane counters all these. It doesn’t matter if the feature becomes really big or a developer is not really sure what the impact of the changes are. Put it to test and see what happens. The test lane has waterfall written all over it and it really shows when you start analyzing how it impacts development.
And don’t get me started on test lanes that get flooded at the end of the sprint when everybody all of a sudden has their story “ready” or when the tester is a week off.

Gain confidence the right way

The main purpose of testing is to gain confidence in the product the team is building. “We’ve created something and we’re fine with shipping it” That’s the goal of all testing. This starts way before a single line of code is written and it continuous after the build is released to production. An Agile approach is all about small iterations and continuous improvement. Therefore, testing should also be a continuous process in which every team member plays his or hers part.

Having a test lane goes against that. It’s a relic from the waterfall days, and as such, it encourages a waterfall way of working. It will actively hinder your transition towards a true Agile way of working.

The sooner you get rid of it, the better.

Thank you for taking the time to reading this story! If you enjoyed reading this story, clap for me by clicking the 👏🏻 below so other people will see this here on Medium.

I work at Wehkamp.nl one of the biggest e-commerce companies of 🇳🇱
We do have a Tech blog, check it out and subscribe if you want to read more stories like this one. Or look at our job offers if you are looking for a great job!