"Finding bugs in an organisation"; why I'm frustrated with the tester role recently

I’ve felt a certain frustration with filling the software tester role lately and finally it clicked why. I’ll use this post to explain my feelings. I’ll try to structure it so it doesn’t come across as too chaotic, but please feel free to ask a question if you feel my explanation doesn’t make sense.

I’m now ten years into my career as software tester and the way I see it, if you find most meaning in the role by finding bugs in the software, you’re missing the point. You see, by the time the code has been written a lot has already happened and you’re putting yourself in a position that’s easy to ignore. You’re putting yourself at the end of the process. [This is also what frustrates me in the testing == automation hype train, it’s all focussed on testing code. Boring, bruh.]

This wasn’t my revelation, obviously, but this is what people mean when they talk about “shifting testing left”. They mean: As a tester, get involved as early in the process as possible. You can talk about risk before any code is written, you can help test business ideas to see if they’re even worth building, you can ask questions, you can use Behaviour Driven Development to help the business think about different scenario’s, etc. But most importantly: you get to inspire the people around you with the testing mindset and if the people in your team learn from you they can do more for testing themselves. This has the added benefit that the testing tasks aren’t the responsibility for one person, the tester, but for everyone. If you subscribe to the T-shaped model of capabilities, a tester in the team still has the most testing knowledge, but other people in the team can also learn more about testing. This is the lofty ideal, at least.

So, here I am, trying to put this amazing utopia into practice and here’s where I run into problems. You see, I 100% think that there’s way more value in “finding bugs in the organisation”, as I would call this approach, but it’s also riddled with problems and challenges that frustrate me. This way of testing is highly dependent on other people seeing the value of it and supporting you.

First of all, you quickly run into problems as soon as you start working on features that require multiple teams to integrate software before it starts delivering value and said teams aren’t feature teams but teams formed based on layers in the stack. So you’ve got a frontend team, a mobile app team, a backend team and a database team. This is a nightmare from a testing perspective. In my example, I’m part of the mobile app team. I can’t help but feel responsible for testing the entire chain because the user isn’t helped if the app looks great for feature X, but the API fails spectacularly. So, applying the lofty ideal of shifting testing left, I raise this concern as quickly as I spot it. I organise a risk session with relevant people, I raise awareness of things we have to do, I say that some user flows are hard to test, I point out when we make assumptions, etc.

And then, in my experience, what happens a lot is: Crickets. Tumbleweed. Nada. Nothing. Niets.

People are completely blasé about it. I feel like they don’t truly believe me. They listen to me, some are mildly interested, some make noises of shared concern like “hmm, yeah”. But mostly, nothing much of note happens. And I end up feeling like the crazy person, the crazy tester who is too sceptical, too negative, too sensitive for all the things that can go wrong that other people can sweep under the rug with the deadly words “this is an edge case”.

Do you get my frustration? Because, also based on experience, what happens then is that I have to spend a lot of time waiting until the code is finally there in all required systems so I get to do a chain test and I find all sorts of terrible bugs that could mostly have been avoided if people would have taken my concerns seriously. I’ve delayed a project by weeks once because I found a terrible bug in the database that could have been found by a goddamn unit test (a negative value when it wasn’t allowed). All because I deliver a dose of reality at the end of the process. In even more painful irony, this even harms how people perceive testing: as a nuisance that delays projects. But those same people actively ignore my input when there’s still time to pivot. Blows my damn mind every time this happens. Do you get why I can be grumpy and cynical?

Hilariously, I often get a lot of verbal praise for the way I try to do software testing. People are like “Oh, I see what you’re doing and I really appreciate it. This is the way testing should be done. You really see the bigger picture”. The thing is, these words are starting to mean zero to me. Back it up with actions. Truly support me! But, this would require an organisational change in the way work is done.

The big elephant in the room is the way (Scrum) teams are set up in so called “agile work environments” in Corporate IT. Developer productivity is still the holy grail. Work is split up so every individual developer is kept busy and this often means that there’s a lot of work in progress. What would help testing to be included properly is for one team to have the capabilities to create an entire user flow from end to end. This is what is known as a feature team. The team should work closely together in an ensemble and they should be able to create all necessary changes in the database, API, frontend, app. And the team should focus on one thing at a time. This clashes big time with productivity and efficiency mindsets that managers have because in my proposed way of working there are going to be times when the team is stuck, there are always dependencies. They are waiting for an answer to a question, for example. This is painful and by many people it would be perceived as a waste. “All these expensive developers sitting around not coding?! Gosh!”.

But the commonly accepted way of working that has been prevalent in all my experiences, keep every individual developer busy and split the teams in layers of the stack, comes at a cost too, that apparently not many people see. The pain of waiting is still there because integration testing is pushed back. I’ve met some developers who share my view and they feel this pain too, but they still get to ignore the pain more easily because they can spend a lot of time coding so they can forget about the wider context for a bit. I guess this is why some testers make the switch to test automation engineer? You can ignore the larger problems and feel happy coding away at a solution. I’ve got to admit, I can enjoy this too. Every thing you solve with code gives a feeling of satisfaction (at least, for me it does). But, one way or the other, I’ll be confronted with the larger context again, the holistic view and I’m back to feeling frustrated. I can’t un-see this, you know. I can’t un-see how weird we have set up the way or working and how bad it works for testing.

As long as IT leaders don’t support me in shifting testing left and as long as they don’t utilise the power of letting a group of people with the required capabilities build software, one thing at a time, the power of shifting testing left is largely lost, I’m afraid. So I’m sitting here, feeling frustrated and like I can’t seem to do it right.

In case you feel compelled to react to this rambling piece, I ask you to please focus on the problem the way I perceive it. Do you think I’m onto something here? Do you feel I’m missing something? I don’t want to talk about solutions at this point, I want to dig deeper first.