Yesterday during an online conversation, one of my blog readers expressed her concern: “Debasis, recently I have seen you posting 2 “How I Fixed” posts in quick succession. I wonder why you are deviating from your mission, considering “Software Testing Zone” is primarily a testing related blog”! I replied back quickly: “Well, why not? And no, I don’t think that I’m deviating from my mission to grow STZ as a testing-centered blog”!
If you are a regular reader of “Software testing Zone” and also wondering the same [why I have started writing these “How I Fixed” posts (first “IE 7 Operation Aborted Error” and now “MyWebSearch Spyware Removal”)], here is why…
I believe that technical investigation is one of the major responsibilities that we are often required to perform as testers. Personally, I love this aspect of testing more than anything else and I take pride in describing my role as a tester to be a “technical investigator” who helps the project stakeholders by providing important project related information that in turn guides the stakeholders in taking critical decisions. While trying to get rid of (fix) the above problems I think I did quite a bit of technical investigation to get around the problem and learned the following lessons that, in my opinion, can be helpful for a tester in her work:
a) How to maintain a cool head while being confronted with tough problems/situations.
b) How to narrow down the problem and get to the root of it. This particular skill can help testers while trying to narrow down the reproducibility criteria for hard to reproduce bugs.
c) How to engage in critical problem solving.
d) How to explore free information that is available via search engines and how to use them to your advantage.
e) How to use your observation skills to spot any subtle clues that can lead you to the error triggering condition of the problem.
f) How to use your critical thinking skills to pinpoint the problem.
g) How to use your lateral thinking skills to identify multiple possible causes of the problem.
I think each of the above lessons can also help someone in becoming a better tester. As testers, often we are required to do some research to learn more about a bug and do some investigation to narrow down it's reproducibility factors. As we all know, the shorter and crispier are the steps to reproduce certain bug, easier it is for the programmers to reproduce it and hence the chance of the bug getting fixed gets higher. Good technical investigation skills can also empower a tester to quickly nail down a critical defect that may be too subtle for a mediocre tester to spot and recognize. So overall, I think while trying to *fix* the above problems in my real life I learned important testing lessons.
Moreover as Dr. Cem Kaner says, “The best software tester isn’t the one who finds the most bugs in the software or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.” (~The Bug Advocacy) I thought, why not move one step ahead and fix the problems whenever we have the opportunity to do the same? I completely understand that as testers we seldom get the chance to fix the problems (bugs, defects, issues) that we find in the software. But while testing (problem solving) in real life I did recognize opportunities where I had the chance to hunt down the problem and at the same time try and fix it myself. Thus my recent “How I Fixed” posts took birth. At any rate, I like to solve problem that has the potential to tickle my gray matter and problems like the above proved to be worth trying. And I thought that it would be appropriate to record my approach in the form of blog posts as the documentary of the episodes!
Do you feel that this is against the mission of a blog that is supposed to be testing-oriented? Do you think that I should stop writing these posts? Do you think that I am deviating from my goals as a tester? I would like to hear you out.Happy Testing…