Month: August 2025

One of the first things I did when joining my previous organisation was pitch testing throughout the SDLC. I wanted to share the importance of testing everything that we do.

However not everyone shares that idea of continuous testing throughout the SDLC. For some continuous testing is continuously running the same tests over and over. If you don’t have them fully automated E2E, repeat them manually over and over.

Skipping over how expensive it is to focus on E2E tests, this really misses the entire point of continuous testing. Instead of continuously trying to discover more about our application and challenging everything that we are doing, all we are doing is repeating that same check… and getting the same answers.

Whilst there can definitely be value in repeating tests when you have fear of a risk of regressions (and automation makes that so much easier), the true value in testing is to be trying new things, new ideas and devising new tests.

This is partly why I think people wedded to writing traditional manual test cases are doomed to struggle with test cases. It is a slow, tedious and usually fruitless endeavour.

Testing is more than checking. We need to be continuously experimenting, learning and discovering behaviours. When looking to regression test, don’t ask “what test cases do we have?” but instead “what are the risks and concerns that I have?” Ask “what information do we need to uncover?”. Then devise tests, ideally exploratory or at least looser than rigid test cases in order to uncover the information that you need and the risks associated with that.

In a future post I intend to give a case study or two on some interesting approaches that I’ve looked at.

I originally meant to post something around this about 2 years ago – better late than never! What I won’t state is whether it was still an issue at time of writing…

I repeatedly hear the notion that developers can’t test. I’m not sure if this is because we’re protective of our role (testing has been a dying role for decades) or to excuse developers who can’t be bothered to test.

So let me be clear…

Devs can test.

In fact if I had a high risk feature that I needed someone to look at, there’s a few developers that I’d trust more than a tester I didn’t know (and some I do).

I worked as a developer for 5 years. I was alright at it. However, in that time I never forgot how to test. In fact I never stopped testing. Instead of functional test and system testing, I was unit testing and dev testing my code. I was writing documents where I’d identify edge cases and what the behaviour should be… then implementing it. When our tester was on holiday or overworked, we chipped in. The quality didn’t tumble. The world didn’t collapse.

In one of my testing roles, going back over a decade, I was bemoaning that our processes lent towards following test specs when the pass rate was ridiculously high. Instead I’d find the bugs when I wandered away from the defined test cases that I was meant to be executing and started performing what I called destructive testing (ad hoc). I was shocked to learn that the reason why these tests (nearly) always passed was because the devs try and test them first. There were possibly some automated tests in the mix as well.

What I’ve learnt is that when developers, or testers, say that devs can’t test, what they mean is developers would rather focus on writing code. Perhaps they’ve been tainted from only running the boring test specs that drive me mad. Perhaps they won’t invest time in learning about exploratory testing. However, they have to test. They will. They can.

In the coming weeks I’ll share some more detailed case studies on examples of how I’ve seen (& helped) developers perform excellent testing

As quality / testing specialists we should endeavor to include developers in the conversation. We can remain the specialists but with a little bit of support/encouragement, developers can do a solid job of testing. This all helps us build better software and for the dedicated testers, the opportunity to focus on areas where your elevated skillset can add value.

And the next time someone says developers can’t test, ask them if that means quality / testing specialists can’t write code?