Interviewing a Testing Expert - Alan Page from Microsoft!

As per my long time plan finally I am starting a series of "Interviewing a Testing Expert" posts on my blog. In this series I would be interviewing some renowned software testers from around the globe. In this inauguratory post of this series I am going to present an interview with Alan Page from Microsoft, who was kind enough to honor me with this opportunity to interview him.

Alan Page is one of Microsoft's first Test Architects and currently chairs the test group in Microsoft's Engineering Excellence team. Among other things, Alan teaches testers how to be better testers, and he has designed and teaches courses for Microsoft's most senior testers and test managers. Beyond teaching, Alan creates and updates technical courses, working with test teams across Microsoft to help them reach their goals, and writes on his blog and elsewhere. He has been a tester for over 15 years, and has been at Microsoft since 1995. Here is what Alan has to say:

Debasis: What led you to become a software tester? What was the top reason that attracted you to the field of testing?

Alan: About 15 years ago, I got a job at a company that made music software. I was hired for tech support, but on my first day at work I found out that I was also going to be a tester (as well as the network administrator). I learned as I went for a while, but don't think I was really figured out what a tester did until a few years later.

I love problem solving – I like taking big open-ended questions (like "does this software work") and figuring out how to break it down and answer it. I've also discovered that with testing, there is so much more to learn – it's a relatively new job in the world of software, and I think there's a long way to go to get it where it needs to be.

Debasis: Did you try testing anything other than software before diving into software testing?

Alan: In a way, I test everything. It seems that I'm always challenging and questioning. My first job out of university was a school teacher. I taught band (mostly beginning band and jazz band) for 4 years. Music and teaching are both loves of mine (partially why I like teaching so much in my current job at Microsoft). After teaching, I went to graduate school to get a Masters degree in music composition. I used computers extensively both for writing my thesis (a Symphony), and for supporting papers. This was 1992, so I had to learn a lot about computers just to keep things working. When I graduated, I wasn't sure what I wanted to do. For a while, I taught private music lessons and worked as a bike messenger. I was thinking about getting back into teaching when I came across a tech support job at a company that made music software. I found out on my first day that I was also a software tester (and network administrator). I thought that would be something fun to do for a while. 15 years later, I'm still doing it and enjoying it more every day.

Debasis: Tell me 5 unknown/least-known facts about you.

Alan: I already told you a few of them above – that I have a Masters degree in music composition, and that my job previous to testing was as a bike messenger, and that before that I taught school. Here are some more:

1. I'm a bit of an oenophile. I have a modest collection of about 175 bottles, but I'm getting some more storage so I can expand a bit.

2. My favorite musician is singer-songwriter John Wesley Harding. Bonus fact: Wes played a set at my 40th birthday party!

3. I'm one of the rare Microsofties who grew up in the shadow of Redmond. My family moved to the Seattle area when I was 3, and other than college and 6 cold months in Wisconsin, I've lived in the Seattle area my entire life.

4. I speak a bit of Japanese and French. Not coincidentally, those are two countries I'd love to live in someday.

5. My first name is Donald. I've gone by my middle name for my whole life.

Debasis: What was the hardest challenge you found getting going as a tester?

Alan: Funny as it sounds, simply knowing what to do was probably the hardest thing. Like many testers, my first exposure to testing was having a piece of software handed to me and being told, "test this". Over time, we testers build up our toolbox of techniques, but a lot of us have to start from scratch. I think that even today that we could be doing a lot more to help new testers understand their role and common techniques, approaches, or patterns that can be used in different situations.

Debasis: Tell me about the most satisfying moment in your testing career.

Alan: Depends on the definition of "satisfied." One story that comes to mind is a situation many years ago, I was working with an exec who insisted that testing "owned" quality. I explained, as you'd expect, that test can measure quality, but everyone had to have a stake in quality in order to get a quality product. He kind of blew me off and said, "fine – but when push comes to shove, test is on the line for quality". I know how to choose my battles, so I continued to go about my work. The satisfying moment happened several months year later. This exec sent mail to all of his top level managers + me saying that he had a revelation and finally got it - that development, testers and program management – from management to front line workers all owned quality. It certainly didn't solve all of our problems, but it was nice to see the mindset change.

Debasis: Tell me of any situation when you had wished you were NOT a tester!

Alan: I can't think of such a time!

Debasis: Has the profession (testing) ever affected your personal life?

Alan: Well, my wife was a tester on the Windows 98 team at Microsoft. We originally met in 1997 or so, and she later went on to work for a vendor that made Japanese computer software. We met again almost 7 years ago (she was onsite at Microsoft), and were married 6 years ago. She's still a good tester, but stays at home with our kids these days.

Debasis: What do you think are the most essential skills that make a great tester?

Alan: Problem solving skills and critical thinking skills are huge. You need to be able to work with ambiguity and break down a big problem into solvable parts. You need to have a passion for learning and be able to understand what you're testing from top to bottom when necessary. You need the ability to see what you are testing from the 10,000 foot view as well as the micro level depending on the situation – then use the best tool/approach for the given situation.

Although it's not a skill, you should never get to a stage where you feel like you have everything figured out. As soon as you let yourself become stagnant, you're done. If you're not getting better – and actively working at getting better at testing and advancing the science and craft of testing, your value diminishes quickly.

Debasis: Tell me about the most fascinating bug that you have encountered in your entire testing career.

Alan: They're all fascinating in their own way. When I was on the Windows 95 team, one of my responsibilities was testing networking functionality on Japanese systems. On Win9x (and 16 bit versions of DOS and Windows), Japanese Kanji characters were two bytes long. The first byte was in a specified range – indicating to any program (correctly) parsing the text that the next character was the second half of a double-byte character, and that the two characters should be considered to be one character. As you can imagine, there were tons of problems found testing these characters - everything from general failures to cursors that could appear in the middle of a character (both of these scenarios being quite common). Also interesting was that the "trail byte" – the second half of the character could be a character that normally couldn't be in a file name. One such character that was a valid trail byte was the 0x5C character – commonly referred to as the backslash ('\'). As you can imagine, characters with this trail byte were prime test collateral for network testing. Among the bugs I discovered was one, where given the right circumstances, copying characters with this character as the last character in the filename to a Japanese Windows NT system caused the NT machine to crash. I remember reproducing it 4 or 5 times in a row to make sure it was really happening. This was cool to me at the time for two reasons. One was that crashing an NT machine was supposed to be hard (I suppose it was). It was also fun to find a bug in a shipping product. It was fixed shortly after, but I don't think a customer ever hit this particular issue.

Debasis: How do you see software testing as a career, lets say after a decade? What would be the biggest challenges for the field and what would be the biggest advancements?

Alan: Software is going to get more complex, while at the same time, people are going to expect more from it. If you think back 10 years, Windows 98 was shipping and my parents were just getting around to buying their first computer. 10 years from now, software will be accomplishing things we only dream of, and it will be running, making millions of decisions for us 24 hours a day. Software will be part of everything from traffic lights to home electronics and control systems, cars grocery carts, books, phones…you name it, and all of these devices – running software that allows these systems to interact in a safe and predictable manner. Furthermore, as software moves off of the desktop and into devices that we interact with, our expectations will go up. It's sad how we, as computer users, allow software to fail by creating workarounds or rebooting. We need to get software to a point where we just expect it to work and it does.

The big challenge is coming up with a way to make sure we design quality into the products in the first place and where bugs are the exception. Today, "finding bugs" is too easy. In the future, I want to get to a stage where testers finding bugs is a rare event that causes extreme concern rather than being an "everyday occurrence".

Debasis: What single thing would you tell every newbie who is struggling in the early stage of building software testing career?

Alan: You can't ignore the fundamentals, but you need to find a way to balance theoretical knowledge of testing with a practical, effective approach. I think many testers bury themselves in textbooks or courses on testing and attempt to apply what they've learned in possibly inappropriate ways. Of course, many others discard the fundamentals completely and rely primarily on guesswork to learn the craft. Success in testing, as in many careers, depends on balance. Learn the fundamentals, and learn where they do and don't work. Experiment and learn. Challenge yourself and show success.

Debasis: Is there anything else you would like to say?

Alan: Thanks for giving me the opportunity to answer these questions. Feel free to throw out answers that you may not like :}

Honestly it was great to know Alan better via this interview. It made me realize that I had not known him enough even after reading him for so many years until this interview [and this explains why I have NOT edited a single word from his answers]. Once again, thanks a lot Alan for taking your time and honoring my readers and me with this interview.

Happy Testing...

Share on Google Plus

About Debasis Pradhan

Debasis has over a decade worth of exclusive experience in the field of Software Quality Assurance, Software Development and Testing. He writes here to share some of his interesting experiences with fellow testers.