“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.

13 thoughts on ““Finding bugs in an organisation”; why I’m frustrated with the tester role recently

    1. I fully agree with you and having similar experiences.

      So far I haven’t seen a development approach/ framework which really takes care that people collaborate for a good product.
      And I’m not sure if any framework can do this.
      To me lots about the values, the conviction, that people stand for and enforce. Or not.
      People with the right values will create (context driven) their own approach to collaboration.
      Currently I doubt you just can take something like this else where and “just implement” it at your company.

      The best at Scrum are for me good agile coaches when they make people, specifically the management, develope such values.

      My alternative phrase to “finding bugs in the software” would be “finding problems”. Bugs exist only in already written code. Problems can exist everywhere, fixing them prevents bugs in code – similar to your “finding bugs in Pendleton organizations”.
      Sure, this is more minor.

      Kind Regards
      “Testing at the wrong end”
      Sebastian
      @SebiSolidwork from Twitter

  1. This is a great write-up that truly shows a tester’s frustrations with ‘the system’. Until our organisations a true solution to this, we cannot imagine a true shift in people’s mindset about testing.

  2. I appreciate your perspective, as even as an Automation Engineer I can definitely relate to your experience. However, I believe those setbacks or contradictions you describe are more or less expected because changing an engineering culture will always be gradual. As you said, stakeholders will see the value and acknowledge the new testing initiatives, but in my experience an actual change in all moving parts and getting everyone to the new mindset takes years. Sometimes it happens long after you moved somewhere else (if it ever happens).

    And since I’m also walking this path of a half-baked shift testing left initiative, my advice? is to also try to shift where you focus your testing. If a proper integrated env for a project or feature is still weeks ahead, you might be able to do some isolated component testing somewhere where it gives early value. This even applies to the Frontend. Having technical background will simplify things here, but if that’s isn’t the case you just need to find one developer that can buy the idea and help you setup whatever you need.

  3. now I work with one out of 5 feature teams building a new platform. Ummm 🙂 same struggles. I am believed, but priorities are not always on the same things I worry about.
    Like, I say that we have data issues, and it’s not a problem. Suddenly after 2 months its a top issue and need to be solved asap 🙂

  4. After many years of (software) testing I’ve come to the realisation that there is only so much a tester or even a test department can do. The whole bloody software development process is at fault. Even when there is a general desire do things more “Agile”, business pressures reintroduce bad working practices. All the talk of reducing crunch, planning better next time, is discarded faster than a New Year’s Resolution.
    Really, the management team (and the organisation as a whole) never really believed in the new practices and didn’t want to work differently than they were accustomed to.

    This brings me on to bug prevention, which was being talked about in the 1980’s. So few organisations actually put the effort in to prevent problems. What frustrates me about much of the new focus on Automation testing, is that it’s still mainly deployed at end of the development pipeline. A huge amount of expense, time and complication to “catch bugs”. It’s like replacing humans with robot Firefighters instead of finding ways to prevent fires.

    Testers have never been held in high regard. There are many reasons for this, which I won’t go into now. But regardless, from your experience it’s an almost impossible job to push lasting change, even if it’s just a redefined job role for yourself. Sometimes it’s easier to quit and go somewhere else.

    Some of my ex-colleagues now sit in an advisory position in their various companies, sort of testing consultants. They rarely test in a way that most companies would expect, i.e., sitting with a device in their hands, entering bugs into Jira. Instead, they perform static testing – read and comment on documentation, designs. Discuss potential pitfalls in meetings. Train developers, other team members (and teams) to effectively test their own code. Help design testing tools etc etc.

    Don’t give up 🙂

  5. I fully share your frustration. Unfortunately, my experience for quite some years in testing positions was that the role itself is not taken seriously and you can keep jumping out of your skin as much as you want, in my case it didn’t help. After last try (when I realised that I really need to actively apply anger management strategies on myself so that I don’t spill aggression around) I ended up changing the title. Now I’m in advisory position.

  6. I think you are seeing the right thing. But I would add the following things:

    1. The false promise of Agile. Like I experienced it Agile is often sold as a promise to the management/company that “we can change anything at any time”. This is obviously wrong and it leads to what it is in the end: chaos. Therefore, you have sloppy requirements engineering, lack of decision (even during development) plus “We have to push that in, business wants it/depends on it”. This leads to a decrease in quality which is then projected on the QA roles.
    2. The “tester”/QA. All too often an organisation thinks it has solved the problem of assuring quality by deploying a dedicated role in company. You can have 100 QA people of any kind and 10 developers but the outcome will still be s**t if nobody cares except the 100 QA people. If the culture doesn’t allow for quality (aka management sees its own responsibilities here) it won’t happen. The consequence can be what you described in your blog post. Add to this that a tester is one person but quality happens everywhere in the company: the culture, the business decisions, the requirements, implementation, ops etc. One role can’t cover that.

    Things like this are causing doubts in me if I really going to do this role in the long-term. So far, at the moment, the company I am working for really cares and that compensates for the points I described and that are partially also present here. Especially point 2 is frustrating and overwhelming about the “tester” role. It is just too much to cover or take care about it.

  7. Amazing rant 🙂 I agree completely – finding bugs in the code is boring, I always get to see “bugs in organisation” much sooner than some other people but it is tough to act on it because you A) don’t know who to address to start solving the issue, B) no time or “stick to your own team bugs!” or C) “you’re way out of your league, boi!”.

    Now I know how to call it – finding bugs in organisation. I might even rename my linkedin profile, ha! Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *