It seems to me that these two areas have a lot in common. For example, both processes are focused on investigating the results of misconduct, as well as its causes and effects, along with related records-keeping and documentation practices. A year ago, I got an offer for the role of QA Manual Engineer at inDriver. But before that, I spent seven years investigating criminal cases at various law enforcement units and agencies. During my service, I worked with a wide range of criminal offenses, from serious crimes that endanger a person’s life and health to economic crimes of an interregional nature. At my last job, my job title was: “Senior Investigator of the Investigative Division for Combating Organized Crime of the Investigative Directorate of the Ministry of Internal Affairs of the Republic of Sakha (Yakutia)”. Now my job is to set up regression testing, write mobile UI autotests, and take care of many other things designed to speed up the process of delivering new features to users without any loss in product quality. Launching an investigation Just as a criminal investigation begins with inspecting the crime scene, the bug report begins with a description of the environment where the defect was found. In this way, we collect some solid and reliable data. Then, using that data as a basis, and applying a deductive approach, as well as our knowledge about the environment or the product, we can narrow down the area of investigation, and start planning further moves and develop our assumptions. Developing an action plan Once we get the raw data, we are faced with information diversity. Now it is important to draw up an action plan. Time is our number-one resource here. It would hardly be a good idea to check all values from -2,147,483,648 to 2,147,483,647 in the name input field with a view to locating the defect. Similarly, the investigator does not have the ability to question all of the town’s residents or send every single household utensil or item for molecular genetic testing. To resolve this problem, the QA engineer applies test design techniques focusing on boundary values, equivalence classes, and pairwise. In contrast, investigators will apply tactics and combinations that make it possible for them to plan their further steps as effectively as possible. Making our first assumptions Suppose we receive a murderreport to the effect that we had a crash in our app. From my experience as an investigator, I know that almost 90 percent of all murders are linked in one way or another to the victim’s husband, wife, relatives, friends, or neighbors. It’s the same story with the app…we are guided by product knowledge: let’s say we pull out a sniffer, and check out the outgoing requests and the answers we get. So far, nothing interesting: all the family members have alibis, and the response from the server contains “200.” Everything seems to be in order here. Also, we know that a person of sound mind wouldn’t commit murder without a reason. Based on that, we can narrow down an unlimited list of suspects to those with whom the victim was associated financially or had work-related or some other contacts. Similarly, in the app we can identify the release version from which the defect begins to propagate, and develop our assumptions about what changes in the code could have caused the bug to appear. Pulling up the logs Next, we try to establish all the events that preceded the crime in order to track down some incriminating evidence: We watch footage from video cameras. We interrogate neighbors to find out if they heard the sounds of a struggle or saw any suspicious persons. We establish who the victim spoke with on the phone shortly before the crime was committed. When dealing with a defect, we also collect evidence: We capture logs in Android Studio or XCode. We check the server logs. In the process, we find out that a man NullPointerException entered the apartment shortly before the crime was committed. Neighbors identified him as a local small-time hoodlum with a criminal record who regularly got drunk and was feared by all the tenants of the building. Checking the evidence at the crime scene Let’s suppose that, once the incriminating evidence is produced, the man confesses to the crime. The investigation doesn’t end there. We have to make sure that it was him who committed the crime, and that his confession of guilt is motivated by remorse, rather than the fear of spoiling the investigator’s mood. For this purpose, the evidence is verified at the site of the crime, where the accused perpetrator is required to reveal the full details of the crime and recount any circumstances that aren’t known to any party who is not involved in the commission of the crime. Thus, by identifying a stable scenario for the reproduction of the defect, we obtained conclusive proof that we had found the right party we were looking for. Completed criminal investigation = Bug Report Once all the circumstances of the crime have been established, it is not the investigator’s job to rectify the defect. He organizes collected evidence into the criminal case file, draws up an indictment, and submits it to the court of law. The decision on sentencing, on how to fix the bug, or on whether to declare this bug an innocent feature is made outside of the testing process. Establishing the reasons for the crime In order to prevent similar offenses in the future, the investigator must establish the circumstances that contributed to the commission of the crime under review and take relevant action. He or she must establish, for instance, the reason why no steps were taken previously in response to reports about the perpetrator’s conduct, or why the measures taken against him failed to prevent the crime. The same is true in the case of testing: when a bug is detected on PROD, it wouldn’t hurt to identify the factors that contributed to its appearance: Inadequate test coverage. Merge without test coverage. Poor problem formulation. Inadequately defined requirements. Corner cases not checked by a QA specialist. An insufficient amount of time allotted for testing and development purposes. Low professional qualifications of development team members. Frequently changing requirements. Conclusion Obviously, the jobs of an investigator and a tester are not the same. Some common features notwithstanding, there are still significantly more differences than similarities between them. But if for any reason you find yourself confronted with a desire to radically change your career trajectory, you can find suitable courses from our partner, and this is possible. Even in a completely different field, you can find activities that require a similar mindset — and that will make it a little easier to achieve the goal you have set yourself. Also Published Here
