The paradigm shift in preventing bugs vs. catching them later

The notion of preventing bugs vs. catching them later, is not a new idea. This methodology has been around since the dawn of time. But has it really been in practice through the years, within companies who employ dedicated software testers?

The notion of “shifting testing left”, is a popular expression nowadays, but what does this really mean and how does it impact teams and testers in the new agile world of software development? In particular, the context of trying to prevent bugs vs. trying to catch them later.

Alan Page had a great tweet awhile ago about this paradigm shift in the perception about testing finding bugs:

I love this quote and this really should be the thought patterns for teams now. What is needed for today’s testers and teams, is this mindset shift to help make this happen and to shed some misconceptions about testers and testing in general.

If I hearken back to the glory days of waterfall, one of the greatest values of a tester was their unique ability to catch and prevent bugs from escaping into production. Developers would complete their work and the issue would be assigned to a tester to ‘assure the quality’ of the work that was done. Testers would delve deep into the issue trying to find bugs at all costs. Testers would be lauded for their abilities, and in many cases promoted, by finding bugs before they escaped into production and ‘save the company’ from embarrassment and the perception of a lack of quality and attention to detail by their customers.

I remember trying to prove myself by finding and logging copious numbers of bugs. I remember performance reviews listing the number of bugs found and also getting raises and promotions to ‘senior’ or ‘lead’ based on this. I remember being a developer for a few years and being warned to try and avoid assigning your issues to certain testers, as they would catch more problems then some of the others and cause more headaches and rework.

Thank goodness times are a changin’!

One difficulty for management is justifying having dedicated testers. It was easier back then, because they could point to the reams of bugs found and print out reports and talk about it in meetings. It is much harder now, as teams are raising less bugs and in some cases no bugs at all, since they fix them right away and do not waste time with bug repositories and the wasteful churn that occurs when doing this.

So, how do we value our testers?

I’ve blogged in the past about the purpose of our testing: https://testingfromthehip.wordpress.com/2016/06/14/what-is-the-main-purpose-of-our-testing/

… and also the value we should be providing our teams: https://testingfromthehip.wordpress.com/2016/01/08/am-i-really-a-valuable-member-of-my-team/

As managers, talk to your teams and find the value your testers are providing. Reward them for preventing issues from occurring, for helping deliver features that your customers love, for having meaningful quality and testing discussions prior to work starting, for pairing with developers early on, for bringing quality processes to your team that improve how you are building software.

As testers, don’t measure yourself with your ability to find bugs. We shouldn’t ever want to find any bugs. If you do, have discussions with your team about how to prevent the same thing from happening again and finding and fixing the gaps that allowed it to happen.

It can be rewarding to find bugs no doubt. But, share as much as you can about what your testing strategy is and how you are going to test. Don’t feel the need to keep that ‘ace’ in your back pocket to look clever later and find bugs.

Don’t be that guy/gal!

 

 

Advertisements