Five Questions With Jim Moore

Jim Moore is a Principal SDET (i.e., experienced tester) at Microsoft who has, in his words, "made a career out of dealing with ambiguity". Jim has been a tester since joining Microsoft ten years ago in the Interactive Media Group where he tested multimedia applications such as Audioman. Next came a stint on the DirectX team, then he helped ship Media Center, and he spent some time working with static and dynamic analysis tools on the Windows Code Quality Team. That set of experience garnered him the position of Test Architect with the Windows Engineering Tools And Release group. Sounds like fun!

A few months ago Jim moved over to the Internet Explorer team where he is focusing on site and application compatibility. In his spare time he writes mobile games and plays "an excessive number of softball games". Here is what Jim has to say:

DDJ: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?
JM: First job as a Tester was as a contractor for Microsoft writing script for multimedia web controls. At that time (1996), it was all about cranking out volumes of scripts and filing as many bugs as I could. I learned quickly the value of clear repro steps...I also learned that filing the most bugs also meant having to verify all those fixes :)

DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
JM: Learning that people have PhDs focusing on Testing methodologies or that there’s a whole scientific community working on core testing issues that involve a lot of squiggly line formulas, Theorems, and research papers that read like theses about medical discoveries. I just didn’t realize that testing had its own academic corner of the Computer Science Universe.

DDJ: How would you describe your testing philosophy?
JM: Test is there to measure quality. Test flicks the light switch and counts the number of roaches, Devs are responsible for chasing them down and killing them. Also, If I found it, the customer will find it. In other words, any bug I find (as defined as ‘something unexpected’ or ‘something undefined’) no matter how weird or unlikely, is as valid as any bug that our customers find. But it then becomes an argument about quality vs. schedule vs. feature set, one of those is going to lose.

DDJ: What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?
JM: Testers to know: Know your customer. Try to understand how a defects impact on your customer. If you can’t think of any reason, remember, you are the first customer and you were impacted.

Testers to do: Champion for the customer. Be thorough, creative, and relentless, but also know which battles to fight. Push for adequate time in the schedule for testing.

Devs to know: That testers are paid to assume you didn’t do a perfect job and to pick the nits.

Devs to do: Learn the patterns of your own mistakes and don’t repeat them. While coding, try to anticipate bugs testers will find. Also, challenge the PM on the spec to make sure all ambiguity is clarified and that they haven’t defined any impossible angles.

DDJ: Is there something which is typically emphasized as important regarding testing that you think can be ignored, is unimportant?
JM: Bug count. Bug count is not to be ignored, but is often over-relied on as a metric of Test performance. Bug count alone does not define a good or bad tester. But for sure a good tester will enter a high count of quality bugs. Pay attention to bugs your customers are finding, each of those that were not found by Test deserves root cause analysis.

DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
JM: Two things:

• Time: As components get more complex, configuration matrices expand, and rush to market schedules are marched to, testers will continue to struggle with getting enough time allotted for adequate testing.


• Automation vs. Ad-Hoc(usage) testing: There’s a balance between automating tests and allowing time for ‘real-world’ testing, finding that balance will continue to be a struggle. If it were possible to define all possible actions your customers are going to take, it’d then be possible to ‘fully automate’...at least to a degree that protects your customers.

DDJ: Going meta (to channel Jerry Weinberg), what else should I ask you? What would you answer?
JM: What type of person chooses being a Tester over being a Dev?

Testers are folks who like to tinker, experiment, and have passion for the customer (they are the people who, when confronted with some issue in any given app, say, "WHY ARE THEY DOING THAT!?!?!?!"). They mostly favor breadth vs. depth.

Devs are folks that like to drill deep on a problem, own the architecture, and create the solution. They mostly favor depth vs. breadth.

DDJ: Is there anything else you would like to say?
JM: There is no grand unified theory of code quality. But there is a mostly known set of product requirements and those are best defined by your customers.

Posted by The Braidy Tester at 07:30 AM  Permalink