Expert Testers

First, a quick Hello. You can read my bio for all the details, but suffice it to say I’ve been testing at Microsoft for a while. My present job is to train the new SDETs joining Microsoft. A lot has changed over the years here at Microsoft. To paraphrase a famous quote: To know where we’re going, we must know where we’ve been. I thought I’d share a list of ten ‘firsts’ in my career at Microsoft. They are in rough chronological order. The catch is I include what I learned in each of them. Let’s get started at the start.

First Interview. I was a nerdy kid with programming experience on punch cards. I had the right word on my résumé that matched the experience they needed, so that got me in the door. My first interviewer sat me in front of the keyboard, mouse, and monitor. I said “Cool, interactive!” He sighed, and then decided on another tactic. He handed me one of the Highlights magazines in his office. If you aren’t familiar with them, it’s a kids magazine. On the back is a picture that at first glance looks normal. On closer inspection you’ll notice things that are wrong. He asked me to do the puzzle: identify what was wrong. I was smart enough to know that the purpose of his question wasn’t that easy. So, I started by saying: “I’ll use present day Earth as a reference. Based on that, the ‘wrong’ things are…”

At that point he took the magazine away from me and we chatted for the rest of the hour. Did I fail? Nope. In fact, I had inadvertently asked one of the most important questions of the time: “Where’s the spec?”

Lesson #1: It’s the person and their abilities that counts, not necessarily the experience. We all know that now. If we see an innate test ability in a person, we can teach them how to formally test software or service. I’ve gambled on a few of the folks I’ve interviewed, and they’ve all worked out just fine.

First Recall Class Bug I missed. Anyone remember Microsoft Opus (Word for Windows 1.0)? Well, I was one of the reasons we had to ship Bill The Cat (Word for Windows 1.1). I was responsible for testing the Word Perfect text converter. It allowed us to read and write to their file format. I manually verified character and paragraph formatting was preserved, file properties were properly updated, and so on. I was still new to networked PCs and shared printers, so I didn’t really ask why there was an extra sheet of paper between the printout separator page and my document. After we shipped, this extra page was brought to our attention by one of our larger customers. It turns out our converter created a mild corruption in the document on import. Everything looked fine on the screen, but that corruption caused an extra blank page to print. The large customer printed a LOT of documents, so this bug was going to cost them a lot of money. We quickly patched this bug (and others, thankfully mine wasn’t the only one), and shipped the updated version.

Lesson #2: Question everything. If in doubt, ask.

First Business Trip. Some of our Word text converters were written by a third party company. When we found a bug, we would email it to them. They would fix the code, and then mail a disk with the new code back to us. The other company didn’t have FTP. This long turnaround time was causing problems as we neared code complete, so I traveled to their corporate office with three ‘luggables’ (the laptop of the day) and sat in a conference room for a week. As I found a bug, I would write it on a 3×5 card, hand it to the developer, and he would hand me back a disk with the card(s) attached that were fixed in that version. I would run the fix through our tests (no unit tests back then), and repeat the process.

Lesson #3: Quick turnaround is important. If you work with people onsite, get up and go talk with people in person. There is a reason for open workspaces like cubicles. If the people are offsite, use instant messaging, phone, and email to keep in contact. The act of getting up and networking was recently identified as one of the Personal Effectiveness vital attitudes and behaviors of senior engineers here at Microsoft.

First great manager. I’ve worked under Jeanne Sheldon from time to time over the years. She is now a Corporate Vice President, but when I was hired she was a Test Manager. She taught me the importance of the Test discipline. It didn’t matter whether you were in the Beizer, Juran, or Deming camps of testing (those were the arguments back then). We were there to test the product, verify it matched the spec, and help prevent bugs. The way we did it didn’t matter as much.

Lesson #4: A good tester is a good tester. Our common goal is a better product for the customer.

First big decision. There are two defined career paths at Microsoft: individual contributor (IC) or management. My lead at the time asked me if I wanted to be a test lead. I talked with her about it, talked with my mentor, and I talked with some of my growing circle of friends at work .

Back then managers had very little time to have hands on the product. Most of their time was spent in meetings. I tend to fall asleep during meetings, so the IC path was looking good. Also, politics wasn’t my game. I acknowledged it was there, but it wasn’t my game. I decided to follow the IC path.

Lesson #5: Build up your network of people, inside and outside of your company. You can’t know everything. Keep your network active. Use your network to help you make decisions, answer questions, and so on. And reciprocate and help people in your network when they ask for it.

Tune in for part two, coming soon!

Filed under: Careers in Test |