Better Software - June 2008 - (Page 19)

Test Connection simultaneously. “What color is the car behind us? How many people were in that police car coming the other way? What’s the name of the street on the right? You have to process a lot of information as you’re driving.” These exercises helped me shift my focus rapidly between the big picture and fine details. I was put in situations where it was safe to make harmless mistakes, and then my mentors suggested alternative approaches and had me practice them. When I did something potentially dangerous, they did their best not to overreact. My own reaction to a scary situation was usually more than enough to make the learning stick. Freedom and responsibility are closely linked. After I got my license, my parents let me use the car on my own— short trips at first and then longer excursions. They gave me freedom but they also required responsibility. I had to be able to tell them where I was going, how I planned to get there, and when I expected to be back. If they saw anything risky in my plans, they would make suggestions like taking another route or avoiding rush hour. When I did get back, they asked me specific but reasonable questions about things that I had done and seen. My parents guided me but they didn’t try to control me. They realized skill doesn’t really develop when someone else takes control over your process. As I demonstrated responsibility, they granted me more freedom, but as long as I was using one of their cars, I had to remain accountable. Our task teaches us. One of the biggest sources of feedback about my driving was the car itself. It engaged my senses. The visual information from the speedometer and the tachometer reinforced the audible information that I got from the sound of the engine. If I pushed on the brakes too suddenly, the car would pitch forward. If I turned too hard, it would rock to one side. Very occasionally, a more serious mistake would trigger the sound of a horn or a dirty look from other drivers. When my Dad was driving one day and noticed that a wheel had gone out of balance, he pulled over to let me drive so I could feel the vibration of the steering wheel. He also reminded me to keep my eyes moving around the car, to listen for new sounds, and to be aware of new smells. His goal was to remind me that there were often clues available when there was a problem with my car or with my driving. Learning for drivers, just as for testers, is ongoing, and I still make mistakes every now and then. A few years ago in Santa Barbara, I tried to drive through a flooded underpass where the water was a good deal deeper than I had expected. Suffice it to say that I didn’t die, and I won’t make that mistake again. When we test, we need to know the written rules for our product—the documented requirements—but we also need to recognize, deal with, and report important things that the written stuff doesn’t cover. Books and classroom learning can prepare us, but the learning is richer, deeper, and more adaptable when it’s heuristically based and experiential. The software that we’re testing and the people around us often provide us with valuable feedback about what to test or what might be wrong with our testing process, and even experienced people make mistakes every once in a while. Coaching, mentoring, and, above all, practice are vital to developing expertise, and as we gain skill, we can take on and account for increasingly challenging work. There are still some bad drivers out there. Sometimes the problem is that they’re completely unsupervised; more often, they simply haven’t developed sufficient skill. Wouldn’t things be even worse if the unskilled people were driving under the control of someone else’s script? {end} How do you learn the complex cognitive skills of testing? Of other disciplines? Follow the link on the StickyMinds.com homepage to join the conversation. www.StickyMinds.com JUNE 2008 BETTER SOFTWARE 19 http://www.blackbaud.com/QAcareers http://www.StickyMinds.com http://www.blackbaud.com/QAcareers http://www.StickyMinds.com

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

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

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