I need to pre-fix this by saying that this is in response to someone in my current organisation pointing to a post by Anne-Marie Charrett about advocating for less testing.

So what is this about?

This is around less testing making your development process more robust.

Question: Would you actually think more about the way that you’re writing code and going to deploy it, rather than relying on something that is, usually, poorly maintained and not going to catch anything other than some potentially outdated regression issues?

What are you actually testing and do you keep your regression check suites up to date? Who can honestly say they go in and update them as often as they should? No one can really tell you what coverage this gives or even what level of coverage they provide either (at least to a greater or lesser degree).

This issue is only exacerbated by the teams not actually performing or understanding the benefits of good quality engineering in the first place; which would use something like TDD or ATDD that would enable the whole of the team to trust in the lower levels tests, and a lot more, in the first place. Unit and contract testing, if done well and kept up to date, would be the best way to tackle a lot of this and would, or should, lead to fewer, higher level/UI automated checks. But this is the thing, it all comes down to trust and understanding.

Who are, and who should be, the ones driving that though?

Maybe this is the role of a Quality Coach – though I want to go into this in a more detailed post in the very near future. If you’re interested in the role of Quality Coach, I would suggest reading more about it from Anne-Marie Charrett here.

Once you need less, you will have more

Anon

An experiment

I tried this exercise with a group of developers and testers that I used to work with. We attempted to drive increased awareness and improve quality in the way they were going about coding and testing by banning running our regular automation suite during a bug bash, to see if this improved the overall quality. It actually led to a lot of moaning, worrying that they’ve not done it right and “won’t know until the automation has been executed” (and passed) statements, and overall, not seeing the point in doing this. I personally think this speaks volumes about how much trust we have throughout the team(s) as to either the processes or relationships we have between the testers and developers.

The Testing Pyramid

With its creation in 2009, the “Testing Pyramid” reflects that the need for fewer UI/end-to-end checks (as these are supposed to be all automated in this case) “should” be the norm, however, this still isn’t the case. This would lead to more trust and more time spent by the whole team and not just the testers, especially if testing is still right at the end of the process (no matter how agile we might say we are!), on other testing and quality tasks. Whether this is improving and understanding what we do and do not cover in our automation check suites, or giving time to much-needed exploratory testing, both would benefit from the time the team could get back here.

Safety or trust?

Some of this, as pointed out by Anne-Marie, is probably down to Psychological safety within the team; and what faith they have in their testing at lower levels. I would also suggest that this could be increased if they had more faith in their higher level checks as well, leading to more time to actually be able to test the product and not have to go through all the automation looking at why it failed, rather than finding new bugs and making time for exploratory testing which leads to better quality and products overall.

/B