Let Observation Be Your Crystal Ball


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.

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.