Better Software - December 2007 - (Page 22)

Similarly, when testing, I look for tools to assist me on the task I need to accomplish. If I want to thoroughly investigate the software I’m testing, I do more manual testing and analysis. If I need to complete tasks quickly or repeat tasks that require little thought, I use some form of automation. I call this hybrid of manual and automated testing “interactive automated testing.” Instead than did our combination of manual and automated testing. The combination of manual and automated testing involves trade-offs. Unattended automated test suites can be run frequently, quickly, and when there are no human testers around. Unfortunately, machines aren’t intelligent, so they can’t observe and investigate suspicious behavior, vary their testing focus on a particular area of the screen more easily or watch for patterns that I miss when I’m busy typing or clicking. The ability to pull myself out of an immersive testing environment and view my testing from a different perspective is a powerful thinking tool. Watching an automated test run is one way of pulling yourself out of your manual-testing environment. I’ve often seen previously of viewing test automation as an effort to replace all manual tests, this style of automation focuses on extending the abilities of the tester with an automation tool. It can also provide a different perspective on the software I am testing. Using Automation with Exploratory Testing When I started out as a test-automation specialist, my goal was to automate as many testing tasks as possible. My team thought that running tests unattended was ideal, so we wrote scripts to automate complex, manual test suites. However, some tasks were difficult to automate reliably and were more trouble than they were worth. Many times our unattended scripts would miss bugs we hadn’t thought to program for or would fail at tasks that are simple and routine for humans but difficult for a computer. Our test automation ended up with some degree of human intervention, at least some of the time. While this felt like a setback, our automated test harness was running quite reliably, and when we did need to step in and help out manually, we tended to discover important information about the software we were testing. We noticed that our unattended automated tests discovered far fewer bugs 22 activities, or report results the way a human can. Sometimes when performing exploratory testing, I want to focus on an area deep within an application. If setting up the exploratory test requires a significant number of steps, I will use a tool to automate navigation through the graphical user interface (GUI). Since I am creating an automated test setup that I can use for different tests, I might call this tool a “text fixture” for my exploratory testing. Once I have the navigation automated, I run my completed test fixture, watch it play back on my monitor, and then take over manually when I get to the section where I want to focus my testing. Automating exploratory test fixtures or the setup required to run a test can be an effective tool to enhance manual testing. You get the speed, precision, and repeatability of an automated test, coupled with the power of a curious human tester observing and investigating the application. Not only does this help testing become more efficient, but being able to watch the application work without any distractions from your program interaction also can provide a different perspective. When I’m not physically operating the application by typing or using a mouse, I see things differently. I can www.StickyMinds.com unnoticed behavior in an application when running a test fixture, stopped it, taken over manually, and found an important bug. I find this perspective to be a good source of testing ideas. Observation, Investigation, and Automation Automated test fixtures were a great kick-start for my exploratory-testing sessions, but I soon learned to incorporate other forms of automation in conjunction with manual testing. In one case, a high-profile, intermittent bug was passed on to the test team. We were under time pressure to track it down and help the programmers fix it. I used an automated test fixture to navigate for me, and I performed several manual tests in the area of concern. Realizing it would take a significant amount of time to explore my current test ideas, I modified my test fixtures to create my test data and to repeat a test in a loop. I suspected that the bug appeared to be intermittent because two users were simultaneously performing actions in one area of the application. To simulate this, I ran one automated script to create test data, another to repeat steps in a loop, and then I manually tested on another machine. I managed to re-create the bug because it required two BETTER SOFTWARE DECEMBER 2007 http://www.StickyMinds.com

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

Better Software - December 2007 Contents Mark Your Calendar What's Happening @ StickyMinds.com Technically Speaking Code Craft Test Connection Management Chronicles Man and Machine Let Your Values be Your Guide A Story About User Stories and Test-driven Development Product Announcements The Last Word Ad Index

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