Better Software - March 2008 - (Page 19)

Test Connection we made our client sufficiently aware of the risks associated with information that we might discover with further testing? Mission Accomplished!: We might determine that we’ve learned the answer to some specific question that we asked as we set out, and we don’t expect to learn anything more than what we’ve already discovered. We suspect that we’re done when we have a plausible story for why we think we’re done, and we run this story by the client. Might there be more to the answer than we’ve already found? Might new, important questions occur to us if we continue to explore? I Feel Stuck!: We might choose to stop, at least temporarily, when we feel stuck, severely confused, underequipped, or blocked by some bug. We might feel the need for tools, equipment, or bug fixes to proceed. Are we really stuck, or could we use other information to proceed? Could we report that we’re stuck and why, and then proceed along some parallel or alternative path? Flatline: During a stress test, we may see the program become unresponsive by some measure. No matter how much data we force-feed the program, it displays the same response. We might hypothesize that the program has crashed, is throwing data away, or otherwise is failing to handle the load. In any event, the program is flatlining, and it’s time to pull the plug on this test. Might the program be handling the stress and recovering? Cost vs. Value: All of the above heuristics are really variations on the idea that we stop when the incremental value that we are obtaining, or that we anticipate, is too low compared to the cost of continuing to test. Every activity takes time. Our current activity might have some value, but is it the most valuable thing that we could be doing right now? Could we lower the cost of our current activity through automating some aspect of it? Could we increase the value of the activity by using human capabilities of observation, cognition, and inference? Testing isn’t a race; we’re not in defined lanes, and there’s no clear finish line. Scripted approaches might tell us to stop too soon or suggest insufficient, unimportant, or distracting observations. Part of the power of exploratory testing comes from its open-ended nature; we’re free to keep testing if we think there’s value to be found—a bug, a new test idea, or a new aspect of the product to discover. Still, we might be wrong. If we think we’re done, a problem might manifest itself moments after we’ve stopped testing and watching; if we’re inclined to go on, we might not add sufficient value. More exploration will almost always yield more information; with increasing experience and skill, we learn to infer heuristically whether that extra information will matter. {end} Are you in control of your own testing process? How do you decide whether to stop or to keep going? Follow the link on the StickyMinds.com homepage to join the conversation. www.StickyMinds.com MARCH 2008 BETTER SOFTWARE 19 http://StickyMinds.com http://www.rallydev.com/bsm http://www.rallydev.com/bsm http://www.StickyMinds.com

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

Better Software - March 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: Breaking Ground On SOA Software Development Worst Practices Mind the Gap Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

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