Five Questions With Joshua Williams
Joshua Williams has been a tester throughout his twelve-plus years at Microsoft. That time has seen him working on globalization, testing drivers, and leading the USB support test process, on more architectures and versions of Windows than you probably care to hear about. He has worked with and on various automation frameworks and process improvement exercises as well, which experience is one reason he coauthored the recently published A Practical Guide to Defect Prevention. (See my review elsewhere on DDJ.) His primary focus nowadays is finding ways to help testers better enjoy their work, a mission I wholeheartedly support!
Here is what Joshua 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?
JW: I had been working in the back room of computer stores for a few years as the "fix-it guy". When I did my first interview loop to start at Microsoft, a test lead asked me to do some tests on an application he then loaded up for me. I am sure I didn't do it all correctly, but I found some problems, and passed the interview. I started by testing hardware compatibility. It was a conceptual leap for me to move from "making the machine work" and "pleasing the customer" to a testing mindset. Obviously pleasing the customer is still important, but in testing we strive to find, understand and log problems, not just find workarounds so we can get the customer up and running. It's the discipline of digging into the problem and getting it fixed that was the change. And it turns out, it's rewarding, too, just in a different way.
DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
JW: After all the technical work, the code, the bug reports, etc., I would have to say that effective communication can make or break your career. I have made plenty of mistakes, and most of them were trying to get the right message across. Communication with your counterpart developers, the program managers, your lead or your employees can create trust, or it can erode it. Sometimes the unintended message is not just a result of what you say, but of how you say it. There are a wide range of strategies people take up when they communication with others. Some people get aggressive, some grow more passive. Your goal is to deliver the message you have in a way that you accomplish your design, not just to say the words. This matters in all kinds of scenarios from defect reports all the way to defending a bug before the release management team. It especially matters when leading a team. Communication can be tough to master, because it isn't a hard skill, but it often carries more weight than your technical know-how.
DDJ: What is the most interesting bug you have seen?
JW: There was this bug that only occurred because of a mix of power management and removable storage. It was interesting to me because it demonstrated how even good test teams can wear blinders. I am confident that the removable storage team did a full battery of tests, probably achieving incredible code coverage results with their testing of removable storage. The same is true of the power management team. But, they never got together. It isn't anyone's fault, but then again, it's both their faults. Should storage drivers and functionality include power management testing? Should the power management test team have a huge array of different kinds of devices and removable media? Where does the responsibility of one team end and the other begin? There aren't perfect answers to these questions. This kind of challenge is part of what makes testing as a career fun: it's not all black and white. To be effective, we have to look outside our boxes, and see the world a little more like the customer does. Only by doing so can we understand how to best test.
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?
JW: Some of the best testing I have ever been a part of was a single SDET and a single SDE focusing on a specific feature in a tightly-coupled feedback loop. They made the most progress because they both shared the same goals: make the feature and the tests great. They both contributed to both goals, even though they owned only one each. This was great because they could communicate openly and honestly. They put away their egos and worked together. The "Quality" wasn't left to the SDET; they both owned it. Not every project will work out like that; but the core principle doesn't change: put away your ego and remember that everyone is responsible for the quality of the product.
DDJ: Is there anything else you would like to say?
JW: People need to read. Testers need to study other disciplines and understand what other companies are doing. I am lucky to be in a group of avid readers, and it has really pushed me to read more. I have really enjoyed reading books on business theory and process management from industries outside software. It has been remarkably educational and eye-opening in how I view quality. I would challenge testers to read. And, they can start with a book that I contributed to: A Practical Guide to Defect Prevention, with more info at www.defectprevention.org. It has a lot of info about software development, but also has a lot of info about things we have learned from other industries.
[See my Table Of Contents post for more details about this interview series.]