Why Testers Need to Tune Out the Noise and Focus on Value
The testing field can be disorienting for both new and experienced testers. If a new tester asks five experienced testers for a simple definition of a term, the new tester is likely to get five different answers, including one answer that asks why the question exists in the first place.
There is little consensus on what books to read, what classes to take, or what—if any—methodologies or schools of testing are “best.” To boot, testers come from all over the place with their opinions and experiences in tow, emerging straight from college or from a certification organization, from a field outside IT, or from another department in the same organization. How do brand new testers make sense of their role in light of the myriad opinions about what testers are supposed to do?
One simple way is this: Tune out the noise. Beginning testers should use their minds to focus on how people might obtain value from the program they’re testing or why people are not receiving value in the first place. No matter what the textbooks or online forums say is the first step to becoming a good tester, value is always at the heart of testing activities.
Michael Bolton argues that testing is fundamentally “about gathering information and raising awareness that’s essential for identifying product risks and steering the project.” Information and awareness are value—first for the decision makers and ultimately for users.
Cem Kaner, James Bach, and Bret Pettichord argue in Lessons Learned in Software Testing that testers are the “headlights of the project,” illuminating the “road ahead so the programmers and managers, however they bicker over the map, can at least see where they are, what they’re about to run over, and how close they are to the cliff.”
In software development, everyone on the team has a specialized mission. Developers try to perfect code; product managers try to make customers happy; and testers try to provide information. If software development were like driving, other roles on the team would be myopically focused on one specific gauge on the dashboard, perhaps the speedometer or the temperature gauge.
So, who’s watching the RPMs and suggesting the driver shift up or slow down? Who’s thinking about where and when to fuel up? The tester is. Sure, the tester is concerned with functional correctness, pointing out that the specs say there should be a rear view mirror when it’s missing, but the tester is also looking at all the gauges, watching speed limit signs, and reporting that little shimmy in the engine every time the car hits 45 mph.
Testing can be complex and fancy, but beginning testers shouldn’t mistake the appearance of complexity as useful unless the test represents a sincere effort to discover a problem in a product. New and experienced testers alike should keep value close to their hearts and minds as they seek to make sense of their roles in testing.
