No, not the was-a-Minnesota Viking is-a-Minnesota Supreme Court judge! Alan Page is a Test Architect on Microsoft's Engineering Excellence team. Among other things, this means Alan teaches testers how to be better testers. Not just newbie testers, either; Alan's class for senior testers is ever in high demand. Beyond teaching, Alan's job has him creating and updating courses, working with Test teams to reach their goals, and writing on his blog and elsewhere.
Alan has been a tester nigh on fifteen years. The last eleven of them have been at Microsoft, where he beat on various flavors of Windows, from Windows 95 to Windows CE. Now that he is with Engineering Excellence he is not directly responsible for testing any specific product but rather is charged with helping all of Microsoft test better. [Insert your favorite Microsoft-bashing joke here...] Here's what Alan 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?
AP: Nearly 15 years ago I took a job at a startup to do tech support (they wrote the music software that was included with most sound cards at that time). On my first day they put me in an out of the way room so I could spend some time learning their software. After a few hours, someone poked their head in and said "by the way, you are our new network administrator". A few hours later, someone else poked their head in and said "forgot to tell you before, but you are also in charge of our software testing" ' At first, I just poked around. I found a lot of bugs, but I think it was just because the products were buggy. At first, I primarily tested the "happy paths". Later, I learned MS Test (precursor to visual test). We had an MSDN subscription, and the beta of version 1.0 was available then. I remember finding cool boundary bugs without knowing anything about boundary analysis or equivalence class partitioning. As I remember, for most of the dialogs, I just tested every value. I don't remember what I did with parameter combinations.
Although I've always been thought of as a good tester, in hindsight I realize that I never really started figuring out what software testing was all about until years later. I started as a tester at Microsoft in 1995, but it was a few years after that before I started putting all the pieces together. '
DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
AP: I am continually surprised about much there is to know. Around 1999 or so, I started reading a lot about testing and quality assurance. I went through the classic phase of thinking I knew all about a subject to realizing that I didn't know much at all. The more I learned, the more I realized how much more there was to learn. Because different authors have different approaches and opinions, once I read through several books I found that I was able to form my own opinions on testing and quality. I'm still trying to learn more, and I'm always working my way through books and research papers " trying to learn as many different ways to look at a problem as I can. '
DDJ: How would you describe your testing philosophy?
AP: Have as big of a toolbox as you can, and choose the right tools for the job. Perhaps it's an overused comparison, but I think of testing techniques and methodologies as woodworker's tools, and the act of testing as the woodworking. A novice woodworker may just have a few knives and chisels and won't be able to achieve a high level of detail. A master woodworker, however, may have dozens of chisels, knives, saws and trowels to work with. The choice of tools, along with their experience can result in a much more ornate piece of work than the novice is capable of accomplishing. A master tester needs the same things " lots of techniques they can apply, and the experience to know which techniques to apply to a specific situation '
DDJ: Is there something which is typically emphasized as important regarding testing that you think can be ignored, is unimportant?
AP: A peeve of mine is testers who say they "like to break stuff". Breaking stuff that was already broken isn't a valuable skill for testers. However, finding a problem, analyzing it in order to find the root cause, and using the information from the analysis to find similar issues is important.
DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
AP: To keep building that toolbox. Testing is going to get harder. More developers are writing unit tests (or using TDD); software engineering teams are doing more around defect detection and early prevention. What this means for testers is that most of the "easy" bugs are going to go away. There will still be plenty of bugs, but testers are going to need to be able to apply multiple testing strategies in order to find them.