Quality police and why it is a mess

For long term development, as Quality assurance analyst... you do research. By so you are to become proficient and tackle issues that you haven't thought of.

A software tester's job is to verify software, find bugs and report them so they can be fixed. An effective software tester focuses on the software product itself and gathers empirical information regarding what it does and doesn't do/work. This is a big job all by itself. The challenge is to provide accurate, comprehensive, and timely information, so managers can make informed decisions, DOD’s (Definitions of Done).

When testers fall in the role of being the quality police they start by enforcing quality standards and identifying developers who are not following procedures. They end up doing what they can to punish developers which they feel that are producing inferior work. Although this might not sound bad, many Agile QA's approve to the sentence that:

"The quality police role traps testers into being less effective as testers, discouraging communication, reducing trust, and causing delays."

Sometimes trying to keep the level of quality high as a standard can get you, as a QA, in a Quality Police Frenzy. 

Starting to follow this path is almost a quick switch in your brain if you don't work a bit with your mindset. Some testers adopt the attitude of being in this role on their own initiative, others do so at the prompting of their managers, stakeholders or the advice of authors and consultants. As a short description as Quality Police enabler you start blaming everyone, finding "the black sheep in the herd", focusing more on who delivers "bad products", wrongly executed scripts, or not good specs, documentation etc. This fixation can go so extreme that it can effect the entire production team. 

Here you can find what every QA should do when they find themselves scavenging for the most indescribable/annoying/killer bug in a Quality Police role:

- you are not the only one that tries to keep the quality level up in your company. 

In fact product managers, consulting teams, stakeholders, developers push towards that, but also towards progressing with the team. *Continues development* is a smart and beautiful memento to hold on to.

- a bug is just a bug

It's not the end of the world if a bug is not fixed. As long as you aware of the impact level that the issue and you notified the lead/ or person in charge about it, and of the location of the issue (depending on the company/office/group structure you're working in) and you address it accordingly, you are fine. Many testers have the impression that sometimes they are ignored. I can identify with that, it happens, but by creating tickets you are addressing the issue, labelling and following them afterwards works also. (Check here for bug reporting tips). Don't forget to add the ticket to the right board!

- quality assurance label

As a tester you are not in charge of the whole quality level of your company. Managers should not expect of their testers to “assure quality”. If the managers truly want an independent group to audit the work of developers, that shouldn’t involve direct feedback from testers (of course the group can also audit the tester’s work). As a tester you should focus on the product, not the people. Everyone should take responsibility for the quality of their own work. 

- developers need discipline

As we all know for QA is easy to find patterns. If you're seeing loads of bugs, you might think there should be more unit tests, formal code inspections, defining requirements upfront, better management..... be careful!!!! You're already falling deep. It's easy to think this way, particularly easy when you've seen with your own eyes (maybe?!) this practice to work efficient elsewhere. And then you ask yourself: Why don't they get it right?, why don't they write what I've asked (e.g. more specs!) . If you like so much to manage, you're convinced that you know how to run development, maybe you should think of getting into a product management position. You can get sanctimonious and if you're not being followed or listened to you might get the impression that your bubble is gonna burst. 

- developers are the ones with the problems

If you've made the mistake of signing on an impossible task, like ensuring there are no bugs, then you may be particularly motivated to find a way to deflect the management's attention towards developers’ problems. Testers which tend to apply fast the quality police role are the ones who didn't kept up with the software trends, lack abilities or lack skills. They also can get away with it in organisations with a lot of blaming. It’s easy to quote standards, criticise people for not following them. These people give the testers the reputation of being useless in companies. 

Good testing means getting clear information from developers about their understandings of Customer expectations/requirements and DOD’s. At the end, if you think about, it is hard enough to get this info from your fellow devs when you have a cooperative relationship. When a developer realises, that you plan to use his/ hers working docs to find faults, bugs etc. he/she will cut off communication, share less info and will be less inclined to discuss with you. Afterwards testing for you will hurt… deeply… because practically you don’t have someone to help you with docs, requirements etc.

The relationship between developers and testers should be one inclined towards quality delivery of the product/service. Even if you find tons of bugs the project can still survive, by addressing them correctly. But if the communication goes wrong, as in quality police roles taken too seriously, you break up the faith the developers have in you and the team practically. Better is to not share your recommendations, for how programmers ought to develop, until you’re asked.

Hope you enjoyed this article!

Cheers,

Daniela