Curiosity killed the task
I was reminded today why two of the traits of a great tester are curiosity and a willingness to share information
We run test cases we run after every build to confirm that the build is good enough for deeper testing. This “Build Verification Test” failed in the lab, and I had already verified that the issue didn’t occur in my local VMWare Workstation image, so it seemed likely that there was something different in how I was testing and the BVT. I went upstairs to the lab to dig into why a particular service couldn’t be removed.
I sat down and got my bearings and was looking over the logs and current state of the machine when Robert, a tester I’d worked with when we were defining and implementing DCOM security settings compatible with Microsoft Windows Server 2003 SP1. He doesn’t usually see me in the lab, and asked what was going on. After a very brief conversation, Robert mentioned that the problem might be related to another issue he’d reported in the same build in which a process sometimes hangs. The two seemed likely to be related since the most common reason that a service won’t uninstall is that it cannot be stopped, and his process and my service are related.
Sure ’nuff, after some quick tests, I was able to confirm that my issue was a side-effect of his issue.
An insecure tester would have declined to offer any information in order to avoid being incorrect or rebuffed.
A merely competent tester would have ignored me and efficiently gone about his or her duties, effectively quelling any curiosity.
Robert saved me several hours of research because he was curious and because he was willing to share information. He not only earned his pay today, he also helped me earn mine, and that’s what teamwork is all about.
