The Quality Police: Testing like a Law Enforcement Officer

I am new to software testing, but I am not new to the ideas behind it.

I was a police officer for ten years, and then about a year ago, I became a software tester. This was the biggest change I ever made in my professional life, and I wouldn’t have made it without help and support from my wife, who is also a tester. 

My first question when stepping into the testing world was whether I was made for this. The answer came when I found out that testing is simply the process of evaluating a product by learning about it through exploration and experimentation. If testing is just questioning and investigating, I knew how to do that.

Software is like people: It tries to show you only the “pretty side,” but as soon as you start asking questions, that pretty side changes, and the truth is revealed. James Bach suggested that I would gain confidence more quickly in this field (and find my own “signature” style of testing) if I made an explicit inventory of parallels between my old and new careers. Soon, I discovered there are many similarities between testing and police work.

Testing and Police Work Are Highly Exploratory

Every day as an officer, I was exploring the world. Police work is focused on what is happening right now, and exploring human reactions to different changes and situations was part of my job. People react in strange ways even though nothing is communicating that reaction. A police officer needs to be ready to detect, predict, and prevent a crime, as well as reproduce the steps that were made before and after the crime was committed. My mind had to be sharp all the time, and I had to listen to everyone who mattered.

I remember one Sunday around six in the morning, when my colleagues and I were patrolling. We noticed some people waving at us to get our attention. We stopped the car and went to see what was going on. It turned out that there were two rival gangs fighting. As soon as they saw us, they stopped. We immediately thought this was too easy to handle, and it made us even more suspicious: Why did they just stop? This is like seeing a critical error message announcing that the app has crashed, but then the message disappears and the app seems fine.

We looked closer and saw that one of the guys was sweating heavily, so we decided to arrest them all even though the fight was over. We wanted to analyze the reason behind this in more detail. We then learned that one of the participants in the fight was a wanted man; he had escaped the authorities for six years until we came along. The gang members stopped fighting in the hope we would not look at them too closely.

This experience can easily be transferred into testing. When exploring software, shallow testing is not always enough; to find the source of the real danger, you need to put in more effort. The software itself cannot speak. It will not tell you the places problems might occur. Most of the time it will not give many clues about how it will behave, and if you can’t remember the steps that led you to discover a problem, it will try to hide its weakness from you. So working as a team and sharing your investigatory progress with your colleagues is crucial.

Testers and Police Officers Know That Changes Can Cause Problems

As a police officer, I had to be aware of new legislation or other events of public interest that could impact my activity. Sometimes a change can make things unclear or can confuse everyone.

For instance, one law was revised to “A driver needs to carry two proofs of ID with them at any point when driving a car.” The first time I read this, I wondered why. It didn't make any sense to me. But I couldn’t ignore the law, so I had to obey it and ask for a second form of ID every time I stopped a driver. The change in the legislation caused me to add “test cases” to my routine verification of a driver in traffic.

Similarly, for some people, their facial expression is going to betray them (I have the abilitiy to “read” a face), and software is almost the same. Even though I was able to transfer this skill, with code I need to be even more skeptical. When looking at it, my first questions need to be “Why” and “What if,” but the interrogation process doesn’t stop there. We need to keep bombarding the software with questions, assumptions, and scenarios, and maybe it will “break” at some point. 

Gathering information about a constantly changing world and asking questions about those changes were crucial parts of my job, and as a software tester, they still are—now, it takes the form of regression testing.

The Work of Testers and Police Officers Is Based on Facts

Every single behavior has a reason behind it, and that reason needs to be discovered, observed, and reported. It doesn’t matter if it seems trivial or complex, because you cannot know from the beginning what piece of evidence will prove useful down the line. This is true for both police officers and testers.

It’s not possible to find the real criminal—or the real problem in your code—without seeing the whole picture. This means why and where the crime occurred and why a certain person was involved. For example, if I had to go to court to present evidence that someone committed a crime, I had to gather all the information that made me say with certainty that I found the person responsible, as well as how my work factored into finding the reason why he did it.

In testing, after finding and reporting a bug, someone confirms that the problem exists and that it might “bug” someone. Being accurate and clear when reproducing a life event or bug report is imperative. An unclear view of the problem can change the final decision in an unexpected way.

Testers and Police Officers Must Perform Systematic Analyses

When working as a police officer, I often had to create schematics of car accidents. The schematic would normally be a graphic depiction of where and how the accident happened. There were clear rules for how to symbolize that a car was hit in the back, on the front, from the righthand side, etc. These schematics needed to be clear so that if any of my colleagues would need to reopen the case or follow up on it, they would have no problems understanding and “reproducing” the situation.

It’s the same in testing. Once I find a bug, I need to report it, and discover how it is influencing the software and why it is doing it. Once this process is over, it doesn’t mean that my work is done. I need to check that the fixed bug is correctly implemented afterward and that it is not a danger anymore. I found that testing is easier when I keep it simple: Reproducing the issues I find are easier to follow when I present my bug reports in a clear and straightforward manner.

Testing and Police Work Require Discipline

Filing all the papers and reports at the end of an investigation can be a little boring, but just as I need to have a clear picture of an issue, the accredited body needs that picture, too. They need all the documentation available in order to move forward with the case.

I dedicated ten years of my life to a job that taught me how to think, how to act and react in different situations, how to engage with people, how to read people’s intentions, and how to behave. I use all those same skills today as a software tester. Testing is similar to police work in many ways—but it is much less stress!