Kill the test lane

Hylke de Jong
Jun 6 · 4 min read

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

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.


wehkamp-techblog

We'll try to keep up and post on the stuff we're doing and discovering. Interesting in working @wehkamp? Check out https://werkenbij.wehkamp.nl/

Thanks to Dirk Peeters.

Hylke de Jong

Written by

automating test stuff @wehkamp

wehkamp-techblog

We'll try to keep up and post on the stuff we're doing and discovering. Interesting in working @wehkamp? Check out https://werkenbij.wehkamp.nl/