One of the best things as a software tester is working with developers. One of the most frustrating things as a software tester is working with developers. The frustration stems from the fact that developers and testers often have completely different thought models around what testing is and isn't.

These differences never get spelled out because we all assume that the other party knows what testing is. This post is my attempt to verbalise the frustrations as I have experienced them.

Even though I will use harsh language at times, this post is not meant to personally affront developers. It's just that the situation regarding who has had to change their behaviour to accommodate the mainstream belief around testing has been very lopsided (not in favor of testers), and that's what I'm fed up with.

The T in DevOps stands for Testing

For as long as I've been a tester, developers have looked down upon what they call "manual testing". It's seen as simplistic, repetitive work. As if a tester using the application shuts down their brain and behaves like a robot.

With the rise of the DevOps way of working, the general belief among developers has been that you should put all your tests in a pipeline. Testers that use the application "by hand" (lmao) are something to get rid of. All testing can and should be automated, so you have fast feedback loops.

This is the first hint that testing is gravely misunderstood. The baby has been thrown out with the proverbial bathwater here.

The result of this is that a lot of testers have had to morph into half-arsed developers. SDET's, Quality Engineers. There is now a class of testers who have fully absorbed this belief about "all testing should live in a pipeline", which is truly wild to me.

I've tried going down that path, having been a DevOps Engineer at one point in time, but it just didn't sit well with me. I kept doing testing as I truly saw it deliver value as an extra job next to my new set of tasks as DevOps Engineer because only automating testing seemed so silly to me!

In order for my unease to make sense, we have to go back to an old favourite blog post of mine. Del Dewar's Testing and Checking Synergy

In the process of software development, we are searching for information. This information can confirm or deny that we're going in the right direction (solving problems that the business wants to be solved, to put it succinctly). This information comes in three domains: known-knowns, known-unknowns, unknown-unknowns.

In an ideal world we know all the facts, but in the messy world we live in we only know some. So this is our reality:

Guess in which domain testing as developers see it lives? Yup, in the known-known domain. You can only write an assertion when you have a known outcome. So this is the part of testing that is being largely ignored by a lot of developers: everything else! The best part, the most important part!

At the time (10–8 years ago, sometimes still), there was some commotion in the testing community about calling test automation checking instead of testing. Personally, I think it would have helped to create a distinction because I am still dealing with the ramifications of people not understanding what testing truly is to this day.

Guess what the main mission of testing actually is? Finding problems that threaten the value of the product. Sometimes, these problems surprisingly live in the known-known domain (even requirements are just a model, folks! And all models are wrong, but some are useful). But more often, you have to willingly go into the domains of the unknown. It's not possible to consciously go in the unknown-unknown domain, finding issues there is often done by the users or with a bit of luck/serendipity.

The human is the central point of testing

However, this still leaves a huge part to explore with testing: the known-unknown domain. Btw, you can still use automation here, I call it throw-away test automation because it doesn't live in a pipeline and the code can be ugly as hell. You can use scripting, data injection, what have you, to improve testability to get to your goal faster. But the core of this type of testing is: the human who is doing the actual testing. The essence of it cannot be automated, cannot live in a pipeline.

The tester is responsible for searching for problems in a risk-based, systemic manner. The tester is responsible for reporting what they did and why. The tester has to tell the compelling story of their test decisions, and stand by it.

These are the tasks that make testing so interesting and valuable to do, so excuse me for feeling extremely pissed off that the tech industry has largely ridiculed this type of work! Has made testers feel lesser, not "technical" enough.

On a local scale I have showed developers around me that there were (sometimes huge) problems in the code they produced, but on a large scale the DevOps viewpoint and Factory School viewpoint have "won". You can also see this reflected in job offerings for testers. Almost no one asks for a context-driven tester, they all ask for half-arsed developers to churn out test cases in a pipeline.

The core of testing (and development!) is that it's centred around humans, not the tools. The roots of what we do are centred in psychology, sociology, emotion. Software is made for humans, so why would it make sense to have as few humans as possible testing the application during development? That's highly irresponsible!

However, I think this explains why it's ridiculed because the last thing a tech bro would do is to admit that their profession isn't rational or technical.

Because the situation has been so lopsided for years (testers had to adapt, while developers have been coddled. Although I guess the coddling era is now over with the LLM bullshit), I ask developers this: it's time for you to learn more about what testing truly is. Not all of it can live in a pipeline. Testing isn't about covering lines of code, confirming what you know.

It's actually the opposite: it's about showing that there are still problems that should be solved. (Gah, I hate how this "it's not x, but y" sentence structure has made it sound like an LLM wrote this post. I assure you that I don't touch LLM's with a ten-foot pole!).

If I've made you think, I have this simple request. Subscribe to my website and slowly learn more about testing from the perspective of someone who has done this for 15 years.

Let's go to this situation, shall we? Developers and testers should have at least a part of a shared internal model around what testing is and isn't. It's time for developers to be less wrong about testing, and to update their internal models.

Bonus: a more nuanced take on DevOps from a tester

Even though I dislike DevOps from having erased testing even more than was already happening, it did change the way I test.

I no longer had to guess what was happening in production, observability made me spot problems the users ran into. I changed my test strategy more often when I had this power available to me!

It "cured" me of my frontend focus. I got way better at API and backend testing. It felt good to delete so many useless UI-tests, man!

Releases were almost non-events. We were releasing tens of times per day. We could do canary-releases, exposing only a small subset of our users to a new backend version, and use the observability tools to spot if there were problems.

What didn't change with DevOps? The fact that system integration testing was done by almost no one. Except by me! Too many people think if you test every component well on its own, the integration of those components is risk-free or whatever?

Guess where I often found the most terrible of problems. Yeah.... Real fun to be a mobile tester, yet you are the one to uncover a bug 5 systems deep in the chain that could have been solved by a unit test! Great work, y'all! And then product management was mad at me for "delaying the project". No matter that this bug would have been a huge problem if we pushed it to production, freaking idiots! Yeah, these kinds of situations are almost a given for testers to experience: finding the problems that matter, and then dealing with people who'd rather shoot the messenger than look reality in the face, can't win sometimes! Still love this profession, lmao.