What Keeps Me in Software Testing
Last week I mentioned the name of someone I respected in testing. This person presented internationally in 2012 and served on nonprofit boards at about the same time but lately has been a little inactive publicly.
My friend replied, “Wow, that’s a blast from the past.”
The past? Really? Three years?
Then I realized where I was in 2004: desperately preparing for a presentation at my first international conference, STAREAST.
Eleven years is a long time, especially in this industry. Why do I stick around?
A Few Games in Testing
The first obvious game of testing is the bug hunt. Give me some software and let me find bugs. But there’s more to it than that; usually, a timebox. Now we have to ask what the right amount of time is to invest in mitigating risk and what the first test to run should be.
We also need to figure out what we know. Given an infinite number of test combinations and a tiny amount of coverage, what do we recommend?
One problem with the bug hunt is that you don’t know if the bugs matter to the customer. Getting to know the customer and to understand what matters, what the core business drivers are, and the risks associated with that to influence test strategy—that is a skill all its own.
Understanding what matters to the business is another. You’ve got to know the right thing and advocate for it, including what bugs should be fixed and what shouldn’t. For years many of the members of my community, Context-Driven Testing, have argued that testers don’t say what needs to be fixed; we provide information to decision makers. But it’s been my pleasure to get to know the product, customers, and decision makers so well that I can make the same decision they would if they had the time.
Finally, I take pride in helping get a better product in the first place. My first article for Better Software magazine, “An Ounce of Prevention,” was on ideas to improve the quality of the software before it got to final release testing.
To come full-circle, my talk at STAREAST this year is on getting rid of final release testing through—you guessed it—prevention.
Lessons Learned
The bug hunt, the timebox, deciding what bugs matter, getting to know the customer, finding the risks, learning how to communicate with colleagues, and prevention: Over the years I’ve experimented with these ideas as a programmer, project manager, test lead, contractor, consultant, and even part-time college instructor, but it has always been, as Cem Kaner put it so well, a dance around quality.
These aren’t the kind of things you “master”; I do not claim to have arrived. I do claim to have given a great deal of myself in pursuit of the goal and made some mistakes along the way.
I know a lot of people, when asked why they got into software, especially testing, say they sort of “fell into it,” and that’s fair. These are a few reasons why I stuck around.
