It is believed most testers become one by accident or due to a shortage of developer jobs. I was destined to become one. There exists a lot more to testing than what meets the eye. We chose to become testers with some initial training which prepared us for what was in store later.
As a tester, my sole objective is to break a system in every possible way until it yields and log as many defects as can be found. We need to be diligent because there does not exist any process, technology, or methodology which will let a tester find all the defects in the code and bona fide claim that “this application/product is defect-free”. This is why we log each issue in the Defect Management Tool software as defects or bugs.
Are we Sales-men?
The Sales team of any company revolves around two fundamental core objectives –
1) Motivate the potential client to buy the product 2) Overcome their inhibitions and objections.
If we compare a tester to a salesperson and consider the developer as a buyer, the following two objectives come to my mind which is logically similar to a sales job –
1) Make developers actually WANT to fix the Defect 2) Get past their excuses and reasons for not fixing the Defect. Tester the Advocate?
Have you ever witnessed a court case? Imagine this from an Advocate’s viewpoint as he tries to field his best defense and arguments to convince the judge. When you find a defect in the product, the report alone sometimes will not be enough to motivate the developer to fix the problem. Developers frequently work within very tight schedules and prioritize the defects that they have to fix based on their own set of criteria & urgency which need not address the requirements from the testing team.
That’s why I believe a Tester should also act as an Advocate in a courtroom. You will have to convince a developer to fix the defects that leverage testing the most. If the Advocate fails to provide proof and proper arguments, an innocent life may be crushed. Similarly, if the defect report does not mention essentials and sometimes critical details like the defects which block the application path completely, the entire program may crash and cause serious problems.
If you love detective movies and the way they get to the root cause of the issue to get the bad guy, you will love your job as a Tester. This is another hidden role of a Tester.
As a tester, we need to learn from how detectives approach the crime scene. When we apply the skills of a Detective in Defect Analysis, we get the best result. Most of us unknowingly may already be doing this in our own capacity with the help of acquired skills. A systematic approach like a Detective in Defect Analysis is something that can hit the root cause of the issue rather than acting on its symptoms.
Do you view Testing as a scientific Job, as the work of a Physicist or Biologist? We need to learn how scientists create their hypotheses? The experiments they develop and conduct to prove their assumptions? When, and how do they decide the evidence collected is enough to claim a discovery? In what way do they describe their research to the community and how they defend their conclusions?
Again, I would say some of us do all this to a level where we are satisfied when a defect is accepted. But does that truly conclude our task? Shouldn’t the investigation continue till we discover the core problem? One might say again that there isn’t enough time to do this in the Software Development Life cycle as dates are pre-decided and we chase after them, but at what cost?
Should we not take some more time and do a job like a scientist to ensure that the End User will always trust our products the way people trust proven medicines.
But So tell me dear reader, WHO AM I? still developer’s or others may say that our job is quite easy, with nothing much to do and nothing to think, just have to maintain an excel sheet.