Digging in the mud

As a software tester, I often feel like being an archeologist. I am analyzing bits and pieces that are found in requirements, use-cases, user-stories, emails, phone calls, balcony talks, meetings, defects, etc. I am collecting all these wide spread pieces of information and try to put them back together as accurate as possible. Unlike the two men in the excavation, I like to do this kind of job. When the connected pieces turn into a nice picture in my head, I am gluing them together in the form of well documented test cases or - if it is a really large "dinosaur" - in a final report that contains all information needed. I do it mainly for me, but I also do it for other stakeholders so they don't need to to through the same laboursome process when someone has the same questions.

The other analogy to a tester is the explorer who collects facts, numbers, painstaking noticing observed behavior or numbers gained from measures. The explorer then groups the data and analyses the collected material trying to find patterns that allow for interesting new findings that either confirm or refute assumptions made upfront. These conclusions are then (hopefully) used to make accurate decisions elsewhere (and also at your own desk).

Yet another analogy is the one of a fed. Testers are regularly cluttered with fake information. Of course, we also get accurate information, but it's all mixed in a bucket and we need to sort it out. Unlike a criminal who tries to protect himself using lies, we may get information that has either not been accurately analyzed or was invented to stop others from further asking and investigating. We, the testers, get information that is based on assumptions and it is our job to question everything. Some nice guy once stated "testers question everything, this includes authority". 

There is also some analogy to medical practitioners. The patient gets interviewed by the doctor whose goal is to identify the root cause of the suffering. The software-under-test is the patient, while the tester is the doctor who checks the sick patient. When successful, the doctor identifies the root cause and solves the problem by prescribing selective medicine for treatment. The tester does similar things. She raises a defect and describes the symptoms as accurate as possible. If the examination reveals a problem that is not within the doctor's specialized field, she may delegate additional examination to be made by someone who is more specialized in the area where the doctor assumes a problem. The tester assignes the ticket to a developer or DevOps engineer for further investigation..

In case you have more examples of such analogy, simply post a comment to this blog or drop me a message at Linked-In or whatever channel you like.