The Lure of Testing

People talk a lot about how they got into testing (I was told I was a tester on my first day at a tech support job), but for those of us who have been in testing roles for a substantial amount of time, I think it’s equally important to think about why we have stayed in testing or in quality related roles. I think for some, it’s simply because they like it and haven’t seen a need to change. For others, including myself, there are moments from our career that anchored us in testing or quality roles.

I’ve told this story verbally a hundred times, but don’t know if I’ve shared it here – at least not explicitly. For me, there was a moment when I re-fell into testing; the time I knew where I’d always be in a quality focused role. Here’s my story.

I joined Microsoft as a tester – first as a contractor, and then as a full time employee. I tested, and wrote some automation and tools to help to help me test better. I also studied and practiced coding a lot. I read Maguire’s Solid Code, and I learned how to write safe and maintainable C code. By the time I’d been at Microsoft 5 years, my title was Software Development Engineer, and I was maintaining the windows debugger, debugging and fixing code in the windows 9x kernel and writing code more than I was testing. I still worked in the test organization, was still involved heavily in test strategy and test design, but I was a respected coder on the team.

About a year later, while running a large test team in embedded Windows, my manager volunteered me to take over a chunk of feature development. At the time, we both thought my growth path was apparent (software development), and I had a solid reputation, so I took over development responsibilities for an entire feature. We were several months away from shipping (it’s still weird recalling a time when we shipped every few years), and I was responsible for implementing half a dozen features and fixing ~20 or so bugs.

I. Love. Fixing. Bugs. I’ve always enjoyed digging and debugging and figuring out the exact reason why bugs occur, and then testing the crap out of fixes to make sure it’s the right fix. To this day, I really enjoy fixing bugs (I fixed at least 100 small bugs in XBox One networking and blu-ray), and have bug fixes in almost every product I ever worked on at Microsoft.

The features were another matter. I got them all done, and also wrote tests for all of my work. I practiced code craftsmanship, and think to this day, that the code I wrote would stand up (the product, Windows CE, is long forgotten). But, except for one feature (daylight-saving time clock update), I found feature implementation to be far less interesting than debugging an testing. While the features required some learning and some investigation, I found the feature work to be much more rote-like than the open ended-ness that I found in trying to solve testing problems.

We shipped the product, and I was offered a development lead position. I was flattered, but said no. It had never been more obvious to me that the challenges in testing were the types of challenges I wanted to be involved with directly. Feature development is not my strong point, and my interest in it pales to my interest in solving testing problems. Since then, I’ve continued to straddle the line between development and testing a lot (e.g. see the bug fixing comments above), but my focus of heavy study and practice since then has been software quality. It’s been 16 years since I made that choice, and I haven’t regretted it once.

Of course, testing today is much better than it was back then, and my role (QA Community Leader, or Agile Test Manager, or ????) is much different, the the essence is the same. The problems I am lucky enough to get to solve are some of the hardest problems in software engineering. I get to be creative, I get to be a leader, and I get to learn every single day. The industry has changed, customers have changed, and I have changed – but I’m happy with my career choices and fortunate to have made at least one good choice in my career.