Better Software - November 2008 - (Page 18)

Test Connection Cover or Discover? by Michael Bolton Most of the time, excellent testing and our evaluation of the quantity and quality of our test coverage start with asking who our client is and what he wants to know about the system. Yet, if our client isn’t knowledgeable about testing, development, or some other aspect of the context in which the product must work, it’s possible that neither we nor the client knows what he wants to know. So where could we start? We might want to start by looking at a map of the system and asking questions about it. Suppose that I showed you a map of a subway system and asked you to cover the map. How would you do it? You might start by choosing a station at the end of one of the lines on the system and then riding the train to the other end of the same line. Then you might do this for each of the other lines in turn. When you had covered all of the lines, would you have achieved complete coverage of the map? Maybe not. Most subway lines consist of two or more tracks in each direction. To cover the system, you’d have to take each line in both directions. So you do that. Would you be done then? Maybe not. There are also sidings off the main lines, so that trains can turn around or pass one another. After you have visited all the sidings, would you have achieved complete coverage? Subway lines don’t exist on their own; there are transition points between the lines. To cover the map, you’d likely want to cover the interchanges between the lines in every direction. And is it sufficient merely to travel the lines, or would we need to stop at each station and have a look around? So far we’ve been thinking about covering the map in an abstract, structural way, but we haven’t been thinking very much about what actually happens on or with the system. We haven’t talked much about the rolling stock—the trains themselves or other vehicles like maintenance wagons. We have yet to discuss the infrastructure—track, signaling systems, elec18 BETTER SOFTWARE NOVEMBER 2008 trical supply—that is needed to support the operations of the system. We could look at the interconnections with other systems—sidewalks, buses, streetcars, and commuter train services. We might talk about the different types of people who use the system—commuters, students, and people with strollers or in wheelchairs. We might consider why they are using the system—to get to work or school during peak hours, to get to cinemas and art galleries on the weekends, or to get home after the bars close. We could discuss aspects of the system that might seem peripheral or incidental to its primary purposes— signage, collection booths, janitorial services, newsstands, and advertising. We should consider the relationship between the system and time—scheduling, actual time between trains, boarding time. We haven’t considered how our observations might be affected by the times at which we make them—at rush hour, in the middle of the day, in the middle of the night when the system is closed. And then, we could think about combinations of circumstances and how they might result in behavior that is non-linear—at rush hour, trains are more crowded, so they take longer to board, so the trains can’t leave the stations as quickly as at other times, so the system backs up, so the trains become more crowded. Maybe we haven’t talked about these things because we—or our clients— haven’t completely realized the motivation for why we’re testing. Yet maps rapidly inspire thinking about what we might think or do to cover them and raise possibilities about what we might see. Some representations of a system actually look like maps—flowcharts, diagrams, UML models, and the like. Usually we design tests by asking queswww.StickyMinds.com tions about specific things that are labeled on the map such as the steps in some task that the map models. But if we’re stuck for ideas on what might be most important to cover, we could start with some map and ask questions that apply generally to maps or apply some general guideword heuristics—simplest, popular, critical, complex, pathological, challenging, error handling, periodic. “What’s the easiest way to get from here to there? What’s the standard way? What routes are essential? What parts of the route are potentially confusing or error prone? What could interfere with this task? What would happen if this route were missing or compromised? Does the map suggest what workarounds might be available? How much traffic goes along this path? How fast does it go? Are there possibilities for collisions?” But another class of questions might arise, too, based on the idea that we might add details to an existing map. An older version of the Toronto subway map that I have indicates the lines and their connections, the stations, and interconnections with suburban rail. A newer version adds extra labels—the street addresses of the subway stations and the locations of parking lots, public restrooms, elevators for people in wheelchairs or with strollers, and surface route transfer points—but drops the labels for the suburban rail transfer points. This reminds us that any map includes some kinds of information that might be useful ISTOCKPHOTO http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2008

Better Software - November 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Getting Agile with User-Centered Design Google Web Toolkit Simple Summaries of Complex Projects Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.