Are you a tester who is particularly good at finding "the weakest link" in code? Are you a developer who has been impressed with a tester's uncanny ability to hone in on weak code? This skill is probably more a matter of organizational understanding and observation than intuition. In this column, Bret Pettichord explains how to use communication factors to predict problem areas in code (and how to avoid letting those same observations draw you into unwanted territory).
Many successful testers use their psychological and sociological perceptions to guide their testing. Developers are often amazed by these people's ability to hone in on weak code and quickly uncover clusters of bugs. How do they do this? In awe of this ability, they attribute it to "intuition"—as if the master testers have bug radar or something. But they don't. They just look at things from a different perspective.
Understanding How People Work
Software is created by humans, usually by groups of humans. And the strengths and weaknesses of these humans often show up in the code they produce. Most developers understand code by reading it. But this can be a daunting task, and many are not able to understand more than a part of the code for their project. They know what they've written and parts of what they have to work with. And the rest is a mystery.
Testers must understand something about how large software systems will work—or fail. Understanding the organization that built and assembled the software is often key. A lot can be learned by talking to the developers and observing how they communicate.
Are there some developers who don't really understand how the code they are developing will be used? Are some developers habitually behind in their schedules? Is code that needs to work closely together being developed by two different organizations? Is development dispersed across multiple physical locations? Are the design documents for some modules confusing or missing? Are different teams in dispute regarding technology or methodology choices?
These questions lead you to identify where buggy code may lie. It can simply boil down to a matter of communication. Developers who talk to each other daily are more likely to understand each other's code (and the big picture) better than those who only see each other at weekly meetings.
I have a colleague who suggests that you simply need to measure the physical distance between the developers whose code must interact. The greater the distance, the greater the likelihood of interaction bugs. (I'd love to see a researcher actually test this hypothesis.)
Remember the Mars Orbiter that crashed because of a mix-up over measurement? One team in Colorado calculated thrust data in pounds, but a team in California interpreted it as being in Newtons (the metric unit of thrust). I really don't know how that snafu came about, but I'd be very surprised to learn that the two teams had good or frequent communication.
Knowing Your Limits
Once you've gotten into the habit of noticing organizational problems and predicting their effects on the software, it's natural to want to get to the root of many potential defects by fixing the organizational problems.
If certain people aren't talking, schedule them to attend reviews of each other's code. If design documents are lacking, require them to be updated. If separate teams need to write code that works together, make them sit together and report to the same manager.
These are all good ideas, but the trap lies in thinking that it's your place, as a tester, to tackle these issues. There are two problems with this.
- Testing well requires that you have access to design documents, development meetings, and interviews with developers. It can be hard to win the trust necessary for this access. Pointing fingers will lead you to losing this access. This is why it is so important to write defect reports in a neutral, nonblaming tone.
The developers may be amazed at your intuition, but the managers probably already know about the problems. Personnel and communication problems are not always easy to fix. Indeed, pointing them out for public attention often makes them harder to fix. This is the trap: The response you get from some might be to conclude that you are the problem.
If you are truly savvy at noticing the correlations between people, the organization, and the resulting software, and you really want to try to fix these problems up front, then you need to get into management. I've known plenty of software testers who were able to build careers as project or development managers from their start in testing. If that's not for you, then stick to finding and reporting the bugs, and use your organizational observations to help you do the job. Your crystal ball can be a big help—if you use it wisely.
