Code has Everything, except Confidence

This post is a continuation of a talk I did recently. It’s meant to be thought-inducing, somewhat savage, and over-simplifying of certain areas. Buckle up, and read on!

The 1000 buzzwords for “Software Testing”

Over the years, as silos and scope has become more prominent, more and more names are being coined to describe a testing activity. Gone are the days when “Testing” was all-encompassing. You now have to define that you want Regression, Performance, Load, Accessibility, Visual Regression, and Exploratory testing done on each item. These could fall into the lap of different people now, or even different companies altogether. 

But it all boils down to a single word. Confidence. Without confidence, the activities have little to no value and all but real costs. But out of all of the buzzwords you can name, none directly mean code, or the requirement to write more code to achieve said Confidence. So here is the first question to ask yourself:

"Does Code Equal Confidence? Or are the activities that the code is performing providing Confidence?"

Now, I will answer it for you.

Code !== Confidence

We already cover this somewhat in our All New Code is Shit article, so I won't go over the covered ground here. With each line of custom - or copied - code, you have introduced the tightened risk of blame falling under that layer. If you are the one to write/incorporate it, you bear the ownership of it. With a new test failure, the layers of ownership have to be stepped through from the bottom up. Was it the script? The step code? The framework code? The runner code?

Coding !== Engineering

Now, there are instances where custom creations are needed, edge cases that require a different approach to the vanilla way most tooling can cope with. Let's take an e-commerce website for example, if there is no decent REST or GraphQL API to source products, this is somewhere that your requirements as a tester, and your skills as an engineer come into play.

You can define, refine, and create something new, something you own and engineer into existence, which directly benefits the rest of the quality stacks.

Test Code > Development Code

Developers, or Software Engineers are designing systems to allow the desired criterion to be met in as little 1st party code as possible. Some of the ways this is achieved is by:

• Using shared modules like npm packages

• Using created frameworks such as React or Angular

• Testing their work with tools like Jest

Their goal is to ship the most robust, but smallest, changes. So why do testers seem to be going to great lengths to do the literal opposite?

Extending lightweight frameworks such as Cypress with heavy-weight “helpers”, or muddying the lines between what a UI test should be doing (acting like the user) and other layers of testing. 

If testers took the same stance as the other engineers around them, they would be making use of the same toolsets to achieve that goal.

Prompting common AI to output 100ds of lines of - now responsible - code doesn’t seem to make a lot of sense. Maintenance, Security, Performance, and Computing all have costs, and for every curly brace and semi-colon you write, all of these go up. 

But Sam, I like to code!

So in conclusion, it's okay to be writing code, but it's also okay to leverage other people's code, which they are responsible for, to achieve a boost in productivity!

A great SDET / AQA / Quality Engineer (so many names) will be great at any area we have been over, but if they had to focus less on one, it means they can focus more on another. Do you fancy solving some of your problems, and making them ours? Try DoesQA today!