Better Software - December 2007 - (Page 24)

Here are some automation ideas to help complement manual testing: Create test fixtures to automate test setup using a GUI automation tool • Program navigation • Test data population • Workflow creation Automate the creation of test data and populate the application with it • I like using interfaces behind the GUI, such as Web services or database interfaces, as they tend to be less susceptible to change and often are much faster at processing Simulate: • Automate repetitive use of commonly used features or workflows • Create light user load for usability testing of client-server applications – This can be done on multiple machines using a GUI or on one machine using multiple threads and the protocol the application uses Automate build deployments, application installation, and file management Monitor: • Visually with diagnostic tools – e.g., the Unix “tail” command is useful to watch server logs in real-time • Create a log file or other activity watcher that alerts you if certain conditions occur when testing – Brian Marick’s Everyday Scripting with Ruby has an example “watch dog” script. See the StickyNotes for more information. The combination of a good automation test tool and the investigative mind of a tester was the recipe needed to find this bug. Furthermore, since I was using the same language and tools that the programmers were using, it was much easier for us to collaborate. Blurring Manual and Automated Testing Sometimes, test automation advocates scoff at manual testing, while manual testers don’t see how running unattended automated tests is an accurate reflection of the work they do. Often, this divide in thinking prevents utilizing the skills of both groups. However, automated testing and manual testing need not be contradictory concepts. Interactive automated testing bridges this gap and provides an opportunity to test applications in different ways. Different testing tools can help provoke different kinds of test ideas. Marshall McLuhan said: “We shape our tools and thereafter our tools shape us.” (see the StickyNotes for a reference). Before I used tools to enhance my manual testing, I didn’t adapt to changing conditions or observations as easily or as quickly. Sometimes I didn’t even see a change or an error condition that was being thrown on the backend because I was only testing through the GUI and wasn’t using a tool to monitor more closely. When I did see a problem that required a lot of setup and repetition to investigate, it required more time and thought to create and execute tests. Now, I tend to use tools to monitor servers, query data that is being used by the application, and help execute different kinds of tests. My testing has been likened to a cyborg—part human, part machine. Here is a recent example. A tester was running SQL scripts on the database backend of a Web application. She noticed that some of the data was duplicated—seemingly intermittently— and she asked for my help. This was a good step; she was using an automated tool for monitoring. She thought that the bug might occur when running similar types of tests. The only problem was the tests required an involved workflow with a lot of fields for an end-user to fill in on 24 BETTER SOFTWARE DECEMBER 2007 www.StickyMinds.com 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.