Testing is dead, long live testing.

Off the back of an incredibly useful conversation with Dan North this week (Check out his website here https://dannorth.net/) we touched on testing.

At my current employer they took a decision last year to remove the role of test engineer entirely from the development teams and whilst I don’t want to get into the why’s of that decision (Because I simply wasn’t here at that point) it did raise an important discussion point with me following the meeting with Dan.

I may be about to make a statement that many disagree with in saying this but I believe the role of ‘test engineer’ as we see it today doesn’t have much of a shelf life left in it. The same thing happened to Test Manager a few years ago as agile began to be adopted by more and more development teams. To give a bit more clarity to this statement I mean the role of manual focussed test engineers doesn’t have much longer to run, particularly in an agile organisation.

10 years ago many large development functions could afford to have a system, integration, UAT and non-functional set of teams to perform their testing. It wasn’t quick, but then it didn’t need to be in a silo based waterfall set-up where one team handed work over to the next team. When your lifecycle operates in months rather than days or weeks it simply doesn’t matter that testing may require a month or more to be completed.

That wasn’t to say that testing didn’t get squeezed. It did. I was there when my own teams would have weeks shaved off the end of their test window to accommodate a right to left plan that demanded a release on X date regardless of the quality or level of confidence testing had provided.

Now with agile deeply embedded into many organisations it simply isn’t feasible to have a dedicated pool of people solely focussed on large scale manual testing. Automation isn’t necessarily the answer to this either (see why below) but shifting more of the testing to earlier in the lifecycle is both proven to be cheaper in the long run for detecting bugs and ensures the quality conversation is had much earlier when issues can be discussed and addressed without causing a crisis later.

So where does this leave manual testing?

It absolutely still needs to be done, but it needs to be done in a smarter way. Supported by automation (But not entirely dependent on it) by test engineers who are multi skilled and multi-disciplined who are coming at the testing from a user’s perspective rather than a developers. So whilst I entirely support the idea of developers doing more testing of their code this must be balanced with the ‘my baby isn’t ugly mentality’ that all developers will have fallen into at some point. When you’ve created a piece of code you’ve put blood, sweat and possibly tears into it. To then be expected to find defects in your code is a big ask and I’ve met very few developers who can perform this honestly and consistently.

As Dan pointed out to me this week this is where agile tends to fall down in addressing this issue. Agile was created by developers, for (Dare I say it) developers. Testers weren’t really a consideration, which is why you see many flavours of development teams trying to strike a balance between development and testing using an agile approach. So a developer will not test a piece of code (Whether its there’s or someone else’s) in the way a test engineer can. They won’t spot the issues a user will spot as easily or as quickly.

And so, what about automation?

It’s helpful, and should be one of the tools any test engineer holds. But it isn’t the answer to everything. Automation is for the low change, low impact areas of the code. You’ll still always need a human element involved.

So for me test engineers need to move more towards a role where they are able to both conduct automation where it’s needed alongside a well versed users ability to spot the bugs automation or a developer won’t see. This means strong user experience skills, probably significant UI knowledge, a basic level of development knowledge and strong test skills. I know of teams that are working towards this model but I’m yet to see any that have nailed it entirely. For me this will be the next convergence of roles in IT. The time of many hat test functions is coming to an end, it’s simply a matter of making sure we have the skills to be ready for the change.