Better Software - November 2007 - (Page 32)

also can vary—from keyboard to mouse to voice recognition, etc. Other applications or sub-systems may interact through different interfaces with correct, incorrect, or missing information. The Exploratory Testing Challenge I hope I have whetted your appetite for FfET. I would like to invite you to try some testing using the framework. I have identified a suitable application, a small flash application called “Barcode Yourself” that runs in a browser. An Internet search for “Scott Blake barcode yourself” will find it on the Web site with a description of the application and what it does. I give you the charter to investigate the various flows (although you can ignore printing) and try to determine the quality of the application. If you want to participate in the study, you can email your test notes to me at et_challenge@gmx.net, subject “ETC.” Normal privacy practices will be followed with the email addresses, which will not be sold or reused. See the StickyNotes for submission details and some clues. Good luck! {end} Erik Petersen is a consultant and trainer involved in custom software development—mostly with a testing focus. He won the award for best presentation at STARWEST 2002 and won the best paper award at STARWEST 2006. Erik also inadvertently named the Master Test Report in the new IEEE 829 testing standard (2007). He thanks Rob Sabourin and Jon Bach for some initial ideas and Jonathon Kohl, Cem Kaner, and Brian Marick for some serious discussions that fleshed out the explanations of the FfET. Visit Erik at www.testingspot.net. by James Whittaker and his students produced a series of seventeen focused attacks that can be used to find software defects. Knowing these attacks, which experienced testers may have learned subconsciously, may help fast-track lessexperienced testers to find defects more effectively. Is there much difference between observing (WLL) and experimenting (WHW)? Some skilled testers use WLL to let their subconscious guide their actions. Others consciously think about each step with WHW. So the difference is in the way we think about or note the activity, rather than the activity itself. How does “Wise Choice” work? There is no way we can test everything, so we need to make wise choices to focus our activities. There are two aspects to this focus. The first is choosing what to test: the best action to take; the best preconditions, environment configuration, and settings; the best data to use as input; the best data to look for as output; or the best actions and information to increase coverage (testing samples of the different actions or information). “Best” is subjective; as we learn more, our idea of what is best could change. The second aspect is when to change focus: when is it best to stop what we are doing and vary it (i.e., change one or more of the “whats”) or finish testing? There is also the issue of priority. We want to cover everything important, 32 starting with testing the most important things first. This information can come from our discoveries, research, or discussions with users. So choices that drive our focus are key. We can note on our session to-do lists other choices to revisit once we have finished with our first choices. What sorts of wise choices are there? There are many levels of choice— from a function to a screen or report to a particular field or value. There can be workflows where the lifecycle of an application entity can be followed (CRUD—create, read, update, delete) or scenarios where a user interaction can be followed (use cases). At a higher application level, it is common to document the variations of functionality to test in charters that can be ranked by importance or risk based on our discovery activities. Other choices cover different environments, different or missing preconditions, different settings or configurations, different interferences, etc. There are different ways to interact with an application—positive testing to check that things work, negative testing to check that user errors are properly handled, or even tests simulating confused users or hackers. If we find a defect, we can say this type of person would do this and have this problem. There are different security levels or authorizations that are possible. There is familiarity with an application, and speed of interaction. Interaction styles www.StickyMinds.com Sticky Notes For more on the following topics go to www.StickyMinds.com/bettersoftware. I I I Bubble pop link The Exploratory Testing Challenge Step-by-step demonstration of bubble pop test sessions BETTER SOFTWARE NOVEMBER 2007 http://www.testingspot.net http://www.StickyMinds.com/bettersoftware http://www.StickyMinds.com

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

Better Software - November 2007 Contents MarkYour Calendar Technically Speaking What’s Happening @StickyMinds.com Code Craft Test Connection Management Chronicles The Measure of a Management System Behind the Scenes A Story About User Stories and Test-Driven Development Product Announcements The Last Word Ad Index

Better Software - November 2007

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.