Better Software - December 2008 - (Page 16)

Test Connection A Map by Any Other Name by Michael Bolton Through most of the ’90s, I worked for Quarterdeck, a company that made memory management software for PCs. Memory management tools were important in those days because programs had been developed for the MS-DOS operating system, which was in turn developed for a processor that provided only one megabyte of address space. When more powerful processors appeared on the scene, they provided access to vastly more memory, but DOS programs couldn’t get at extra memory without some fairly sophisticated trickery. One of the approaches was based on mapping—making physical memory from far outside DOS’s address space appear in a window that was inside DOS’s address space. For a long time, I found the concept difficult to understand. I knew something about mapping in cartography, and I knew that a mathematical function is sometimes referred to as a mapping, but I’d never heard the word used to describe making something appear somewhere else. Things got easier to understand when I considered mapping more generally and realized that maps are links to an idea and a representation— literally, a “re-presentation” of the idea. So a mapping, in a general sense, can take the form of charts, graphs, drawings, or diagrams but might also appear as tables or lists. When we talk about test coverage, we might be talking about covering a map that represents the product or some aspect of it—a functional diagram or a process workflow. But we might also decide to cover a map—or more accurately a mapping—that presents testing ideas in a non-graphical form. Here are a few examples: Use a requirements document as your map. Many test groups translate requirements documents from one form (“The input field shall accept up to twenty characters”) into another (“Verify that the input field accepts up to twenty 16 BETTER SOFTWARE DECEMBER 2008 characters”). This is not only a waste of time but also, potentially, a directive toward weak testing. Instead of rewriting the document, try testing directly from it. Identify and prioritize statements in the document, using them to trigger test ideas. Checkmark and annotate requirements statements as they’re tested, or describe tests in some kind of summary form, pointing to data tables or output files rather than reproducing them. Use the annotated document to guide reviews of testing sessions between a tester and a test manager or project lead. Combine the discussion and the annotated requirements document to check whether test coverage is satisfactory. Requirements documents and requirements tools are intended to capture and specify someone’s intentions for some aspect of the product. These specifications often focus on functional attributes and sometimes pay less attention to the parafunctional (some say non-functional) aspects. While it’s likely that much has been learned or changed since the requirements were first identified, in my experience it’s somewhat less likely that the document or tool has been updated to reflect the new information. Requirements-based test planning may guide the tester toward a heavily www.StickyMinds.com confirmatory approach, rather than a more investigative one. So don’t let your test coverage stop here; diversify and use other approaches, too. Create a map directly from the user interface. While interacting with the product, develop a mind map or a list in hierarchical outline form of the menu and submenu options, dialogs, wizards, buttons, context menus, and other interface options that the product appears to provide. Annotate or detail your map with descriptions of how you tested each item. This approach details coverage for the options that are apparently available to the end-user, but it may be weak in terms of low-level functionality, data integrity, long-term reliability, and so on. It also fails to account for functions that may be available or necessary but not immediately visible. Diversifying your coverage ideas will mitigate the risk of missing something important in the UI. When I miss something using this approach, I ask myself whether I need to explore more methodically or whether features are buried where end-users might not find them, either. Map the risks. Use review and brainstorming to identify important plausible risks in the product and optionally list specific test ideas. Then perform tests ISTOCKPHOTO http://www.StickyMinds.com

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

Better Software - December 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles What's a Manager to Do? Six Thinking Hats for Testers The Key to Good Interviewing 2008 Salary Survey Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - December 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.