Language matters

It's crazy to me how many tech people don't understand the entirety of the software delivery landscape at all. Especially developers often suffer from having a very narrow lens through which they watch the (work) world around them. It's like they have blinders on, preventing them from seeing a bigger picture.

As a tester, I do not have that luxury. And I'm tired of hearing the same language from developers, over and over.

Let me give some examples. These are all comments sourced from one Ars Technica article, btw.

Bottlenecks

Ah, the good old bottleneck point of view.

If a task is worth doing, then it isn't a bottleneck.

We spend time on requirements because apparently, it's worth it.

We create an architecture because without it, there's no agreement on how to structure the code or how to divide the responsibilities of the code.

We integrate code because without it, there's no product. But sure, integration brings risks so it takes more time.

Which brings me to my area of expertise, testing. We test because we see risk. If there's no risk, there's no need to test. By all means, skip it if you think it's taking too long. Enjoy the rewards of that decision, I guess.

But saying that these things are a bottleneck is just dumb. It makes you come across as an unsympathetic asshole. Especially if everything but the work YOU are doing is the bottleneck.

Am I saying that we should not inspect the pace of our work? Or that some things can be skipped? Or that some things might be crossing into the realm of gold plating? For testing, this last bit is doubtful as time has always been our biggest "enemy", but no: I'm not saying either of these things.

All I am asking is that you stop calling worthwhile tasks in the creation of software a bottleneck. This language is harmful.

Using "AI" for stuff you don't like

The good thing is that incredibly mid developers always out themselves like this: they like writing "the real code", but then they grumble about the fact that they "have to" write those stupid unit tests.

Say no more: you only care about yourself. It's clear, buddy.

Do you think I like everything about testing? Because believe me, there's a lot of boring stuff I have to do during good and deep testing sessions, often because testability is very bad across the board. Thinking of what I would like to test is easy, setting up the software in the desired state is often way harder than it should be. Patience truly is something you have to cultivate, as a tester.

If, as a developer, you don't see why unit tests might be important and/or you can't get the fuck over yourself to do these tasks that are worthwhile, get a grip.

There are exactly zero jobs where you only get to do stuff you want to do. It's just that, for developers, this world almost existed, and it created a bunch of petulant children. You don't realise how much you have been coddled as a group, it seems.

Well, those days are over with this "AI" crap going on, anyway.

I have a suggestion: why not write the unit tests WHILE you are coding the solution, like TDD intended? This way it might actually teach you something.

Moaning about becoming "QA"

No worries buddy, QA doesn't exist so "AI" doesn't magically turn you into one.

Here's another developer who doesn't understand testing. Testing has nothing to do with quality, zero. I don't care how many angry "Quality Assurance" people I'll get in my inbox by saying this, but as a context-driven tester I am NOT in the business of quality.

Testing should stay in the risk-business.

We see risk, we investigate it. And believe me, that is interesting work.

Btw, there's another layer to this developer misunderstanding testing. They probably think that "QA" is about checking code for faults. That is a tall order, especially in the age of LLM-generated crap. That would depress the actual shit out of me too.

That's why I can take solace in the fact that for me, the script is exactly flipped. I can't ever prove that code is "good enough quality", so I am not even going to try.

Instead, I am letting risk guide my choices on where to investigate. This is in addition to developers setting up automation in testing, that lives in the CI/CD pipeline, btw.

A tester's job is to support the business in making informed decisions about the product. I'm not saying that this isn't a depressive prospect these days as many businesses have fully swallowed the "AI"-pill and don't really give a damn about risk anymore, but that's a topic for another day.

So please, watch your language

Testing isn't a bottleneck, stop calling it that. There are no bottlenecks, only choices to make on where to spend your time.

Unit testing might be a task that seems uninteresting to you, but by stating that, like it's a fact, tells me you have a shallow understanding of the topic. Plus, that you only care about doing stuff that you want, like you are a toddler.

Testing is also not QA. QA doesn't exist, it's a product of the Agile and Factory School claiming that testing can be complete and "prove" a certain level of quality. This has been the dominant paradigm for a large part of the testing community, sadly. The only thing I can say is: not all of us support this paradigm. There are different ways of looking at testing, and thinking about testing.

Language matters. Use precise words. See the bigger picture.