Better Software - March 2009 - (Page 21) Test Connection but all of these combinations seemed to be disabled. I was losing enthusiasm for my systematic tour, until I got to Windows-L, for Login or Lock—and there, to my astonishment, was the Login screen. At least it was passworded. I considered trying to guess the password— maybe it was some combination of “Admin” and the hotel name, maybe combined with a 1 or a 0. Going through all of the possibilities felt like too much work, and lunchtime was approaching— and besides, there was that button in the lower right corner of the screen that said “Turn off computer.” I considered the potential consequences for a moment, then I clicked the button. The machine rebooted. As it was starting up, I pressed the F8 key and got access to the command prompt. I now owned the machine. Time to stop. I rebooted and left the system alone. To my relief, the Windows logo appeared, Internet Explorer came up, and the kiosk software started inside the browser. Once it did, we noted the support number for the company that created and maintained the kiosk. We had to believe that the service provider’s programmers and technicians didn’t know about this vulnerability or had forgotten to change the key combination to something more obscure. James called the company to alert it to the vulnerability. The first-level support technician didn’t understand the implications of what James was reporting, but her supervisor did and took the report seriously. This is an example of what we can find with freestyle exploration. We had been working implicitly under a very open-ended mission: Learn something about this system starting from scratch. We designed and executed tests in parallel with interpretation of test results and with learning. We created questions and answered them on the fly. Sometimes—as in the case of discovering that the two systems were on different machines—we obtained the answer before we had framed the corresponding question. Not knowing from the outset where we were headed, we used an approach that we’ve found effective for all forms of test design: Start anywhere you like. Every journey begins with a single step. For the very first step of a freestyle exploratory session, we can choose something that might be interesting, fun, familiar, or useful; something that we might want to learn about; or something that we could infer might be important to some client. Start with a question, a conjecture, a specifically defined task, or a completely unmotivated activity and see where it takes us. Did we learn anything? Did we observe something surprising? Did we have a new idea? Did we suddenly recognize a new risk? Is there something here that’s worth recording for future reference or that might be a point of departure for a more specifically chartered session later on? What previous knowledge did we bring to the table? What do we know now that we didn’t know before? What skills might we want to practice? When we report our findings, how does our client react? If we wanted to do something like this next time, what would we do differently? Whatever we discover, we may choose to focus on it, explore it, and learn something about it, or we may choose to refocus, step off in a different direction, and investigate something new. Note that we can follow this process with anything that we might wish to test or review—a document, a prototype, a flowchart, a whiteboard diagram, a new feature, a unit, a complete program, or a test idea itself. Would we test an entire product using only freestyle exploration? Of course not. A good test strategy is driven primarily by risk. Many problems in software products are familiar, and we can be enormously productive by anticipating those problems and seeking them out, www.StickyMinds.com aided by risk lists, coverage outlines, and other forms of checklists. Yet we must also foster the discovery of new risks, problems that we haven’t anticipated. We can’t ever be sure of what we’re going to find, and sometimes we can’t recognize what we’re looking for until we see it. There are at least two ways of addressing that problem. One is to remain alert, alternating between focusing and defocusing, switching between random and systematic actions as we follow our planned routes through the program. Another is to wander every now and then—quite deliberately—away from the plans that we’ve set for ourselves and see what we find hiding in the bushes when we’re off the trails. {end} Whether testing a product for business or for pleasure, what problems did you find incidentally—or accidentally? Follow the link on the StickyMinds.com homepage to join the conversation. MARCH 2009 BETTER SOFTWARE 21 http://www.stickyminds.com/testconnection11-2 http://www.railsware.com/be-agile http://www.railsware.com/be-agile http://www.StickyMinds.com
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.