Testing = slow? Yeah, that's by design, you dipshit.

Can you tell I'm mad? Here goes:

Software testing is always done within constraints, the biggest ones usually being time and budget. Arbitrary deadlines usually put the most pressure on testing, and the allure of taking a shortcut by expediting testing has surely been observed by many of you, my dear readers.

This often takes shape in the form of managers breathing down your neck, asking "what's taking so long", "why is testing so slow", "can we save time somewhere?".

This, frankly, is dumb. Testing is slower than businesses want, for a reason!

Let's go back to the basics: why test?

What is the point?

Ostensibly, most companies spend money on testing because not doing any of it carries too much risk. Apparently enough risk to warrant the expenditure. But yeah, this expenditure "hurts" because you never know whether it was needed or no. If testing is done and not much trouble was found, in hindsight you could have skipped it. If testing has been done, but problems still happen, then what the hell did those testers do?!

This is one of the core problems in testing that I, and no one else, can solve.

But, it has been tried, by evil people. The Factory School wants you to believe that there is a magic testing process™️that will assure that your software is working as intended. Test plans and test cases are created, according to ISO standards.

This is good marketing because this is exactly what business leaders want to hear.

It's also a trap for testers. We cannot deliver on this promise. You cannot associate yourself with a certain quality standard, the absence of bugs, the completion of testing. You shouldn't assure anything. You shouldn't sign off on a release. When shit goes down in production (and it always does to some degree, especially in this LLM coding era), you are now the scapegoat.

Automation hype started fr

The method of the Factory School is now the most widely known test approach, even among non-testers, and this was the first strike against good testing. Then came DevOps.

I'm not against DevOps at all, but we shouldn't be blind to its problems. We now got a testing culture that was all about automation (to a larger degree than it was before).

Automate everything, including testing. A test that's not in a pipeline might as well not exist.

But yeah, this is a pipedream. Not everything can or should be automated in testing. I still found loads of problems when I focused on integration testing. But....this type of testing that I was still doing, dinosaur that I am, is slow.

The focus on speed ramped up. Did it pay off, to some degree? Sure did!

At my client at the time, we could release the backend services multiple times per day, and that was largely possible because we had a nice pipeline full of automated tests that gave a sense of security. The word "sense" is doing heavy lifting here because sometimes it still went wrong! No matter. Quick rollback, quick fix, new attempt. It was less costly to make mistakes because it was often quite easy to fix. Combine that with canary releasing and good observability and I'm not surprised at all that the business was very happy with the state of things.

But.

BUT.

For bigger, newer projects that added new functionality which required code to be written across multiple systems this is not good enough. You still need good old fashioned testing that truly focuses on finding problems.

This type of testing is slow.

Testing cannot prevent problems from occuring in production, nor can it prove that the product is bug free, and yet we start our mission to do as much of that as we can anyway. This is not a "follow this checklist" type of work. To do this well you need skills.

Risk analysis, domain knowledge, technical knowledge, test design knowledge, communication skills, to name a few things. It takes time to do all the tasks that are needed for deep testing. It's also highly rewarding and fun (if you like thinking, at least).

And when you inevitably find problems, the team needs time to fix those.

This might threaten the deadline of the project and this is when managers start breathing down your neck.

Look, buddy. I'm trying to do my work here. You wanted testing done for a reason (I think?), and now you're surprised that it takes the time it takes? You want me to take shortcuts? As a context-driven tester, I am highly aware of my constraints. I'm doing away with as much fluff as a I can by not spending tons of time on creating artifacts. But, I'm not keen on tossing away all my work standards because of bad project management on your part.

Testing slows you down, on purpose! It's methodical, meticulous. I thought that's what you wanted. The slowness is not a flaw! Software is a credence good, highly dependent on reputation. Skip or shortcut on testing enough times, and you'll piss away all the goodwill you have among your user base.

Uno reverse, bitches

Sometimes, the call is coming from inside the house.

The test community is divided into 2 camps (no, not literally, this is just how I see it). There are testers who are fully focused on the "pipeline work", developers-light. They also obsess over speed, and automating everything in testing.

And there are testers like me, who want to do deep testing work in the space that cannot (or should not) be automated.

Testers in camp 1 wouldn't blink an eye and say that "testing shouldn't be a bottleneck". They also think that testing is slow.

I say: this is bullshit. How can testing be a bottleneck if we aren't responsible for making the decision to release yes or no? Uno reverse: release that shit, I dare you. You don't need my work, it's optional! But I thought you wanted this optional work because you felt responsible for the end product?! Whatever man, enjoy the issues and technical debt, you'll find me sipping an Aperol Spritz on the beach because I am no longer interested in working for you.

Responsbility = dead?

The speed obsession only got worse now that everyone with half a braincell thinks they can code with the help of LLM's. The zone is flooded with shit.

No wonder the "testing is the bottleneck" people are crawling out of their mom's basement.

Who takes responsibility for this mess? It cannot be testing. It's incredibly naive to think that testing alone is enough to remedy the speed at which sloppy code is added to codebases. Remember, testing IS NOT about quality, people who are coding are doing the quality bit! Followed by people who have decision power over releasing the product in the state it's in.

Testing on its own doesn't even do anything, it only provides information. If this information is ignored (or not found because "testing would slow us down too much"), nothing will change.

Responsible software development requires credibility, we are in the business of providing credence goods. You cannot get any gains from this focus on speed if you do not take testing seriously and accept that this TAKES TIME.

I am still waiting for someone to slap me in the face so I can wake up from this horrendous dream, but this seems to be the reality now.

Too many people have lost their goddamned minds.

I only scratched the surface with this post, as this is just the tip of an iceberg that would lead me to write about: technical debt, governance debt, accountability displacement, and so much more. But I'm gonna call it quits now and cuddle a tree or something. Later!

Inspiration for this blog came from this excellent article: If No One Pays for Proof, Everyone Will Pay for the Loss. I highly recommend taking the time to read it.