Where would software testing be if bugs were no longer a viral presence in our applications? Advice on how to devise organized ways to uncover, repair and overcome software defects or "bugs" was a primary focus of many STAREast presentations.
Rob Sabourin of AmiBug.com's
Requires Free Membership to View
STAREast session, Chartering the Course: Guiding Exploratory Testing, began by describing the trials and tribulations of the first "real" exploratory testers -- Meriwether Lewis and William Clark (you know them as Lewis and Clark). These two pioneers are best known for their exploration of west of the Mississippi, an act which contributed to the Louisiana Purchase and legalized the Westward expansion of the United States. He used this example to illustrate a strong parallel in software development – where would North America be, had the urge for exploration and discovery not been satisfied? Similarly, where would software testing be if no one performed exploratory testing?
Exploration often leads to expansion, and in many cases, improvement. For our purposes, application exploratory testing can result in more solid applications, and those solid applications can often lead to the expansion of business. There is a myth that surrounds software professionals and their employers when exploratory testing is brought up. They regard it as nothing more than unorganized venturing into an application, a time and money consuming act that rarely yields the positive result one would expect from such a (presumably costly) endeavor.
But Sabourin spoke in favor of the "infamous act." Exploratory testing is valuable, but only when done correctly, meaning that the test procedure is constructed well, with strong mission statements and intelligible testing pathways. He coined the term "Charter Statements" and used it repeatedly in the session. He described exploratory testing as short statements, approximately the length of a Twitter Tweet, terse and to the point -- outlining a desired test path. After dispensing a spectrum of index cards to his attendees, he went on to explain how chartering statements should be written and what they should focus on.
Sabourin instructed us to "use these index cards for 'chartering the course', which is basically identifying areas of an application that have the tendency to be defect-rich and plan testing according to cater to those instincts. Test for discovery, capability, failure and quality factors." Each category of exploration was designated by a colored index card. The audience was shown another clip, this time a tutorial for how to use a Canadian-based online video rental system. We were asked to create possible exploratory tests under each category and write them down. The three best test ideas would be chosen from the submission pile and the winners would be the recipients of a new software testing book.
"When you write an exploratory test, or at least when I do, I like to give the test idea a persona. I like to think, how would Bart Simpson use this application? Would he find a way to break it? How would TAZ use it?" With this, Sabourin really had his audience thinking, most noticeably after mentioning Bart as a possible application user or abuser depending on who you asked. This provided a new perspective on how effective exploratory testing could be written, decided upon and implemented.
This was the bridge of interest between application test theory and imagined characters logging into software applications and wreaking havoc. "I've been under the hood of many, many applications, I've seen the business models good and failure prone, and I've broken the software. Using exploratory testing is a great way to gain insight into the health of your application; find problems and resolve them before it's too late," said Sabourin.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation