The end users were the people with the most practical knowledge, but they had no IT or QA background. The testers lacked the proper financial background and the day-to-day experience. To solve this, the testers and end users were asked to sit together in small work groups (four to five people each) and come up with stories based on the most extreme examples that had happened, or that could happen in practice. Imagination was invited and exaggeration was welcome. To help the process, I asked the groups to imagine that they were writing soap operas.
Michael Bolton (from the video):
I am so excited by Hans’ presentation… He has touched on this fork, and the fork is, are we going to confirm repeatedly, relentlessly, the same stuff, that we have seen over and over and over again (which I worry sometimes the action word stuff drives us into) or are we going to do really exciting stuff that soap opera is good for. Which is to actually investigate what happens when things are non-routine and things are non-routine far more often than we believe. I love the soap opera concept, I absolutely love it.
Exploratory testing is all about curiosity. If you are not curious you do not find bugs…
Hans also mentions “exploratory test design” where you think about the business (not the User Interface UI).
This idea of planning exploratory testing is often overlooked. It is important to think about the critical business rules and how those ideas should be tested. Planning out areas and concepts that need to be covered during exploratory testing is important. Soap Opera Testing can help with this, as can Hexawise test plans which help you consider interaction effects.
Carrie Puterbaugh’s presentation at the Twin Cities Quality Assurance Association on using Hexawise to improve software testing at her organization (a large bank).
In one example she discusses in the video Carrie’s team used Hexawise to create an optimized test suite and provided that to the software vendor to have them run it prior to delivering the software to her bank. In this example historically they vendor was finding 67% of the defects and Carrie’s bank was finding 33%. Now that the vendor is using the Hexawise test suite the vendor is finding 98.5% of the defects and fixing them prior to delivering the software.
Based on these results her team was able to move staff off of testing this application and onto other testing needs of the organization. They are saving 90% of what they used to spend on QA on this project.
Another project she talked about was a high priority and high risk release that they used Hexawise on and achieved the highest quality software release they have ever had.
It was great…
We were able to go to management and say “we reduced the amount of test cases we ran and we got a better quality application.
Justin Hunter’s presentation at the 12th annual international software testing conference in Bangalore, India, December 2012.
The techniques discussed focus on how to reduce the amount of time spent selecting and documenting test scripts, reduce the amount of tests needed for execution by creating unusually powerful tests and thus increase the thoroughness of software test suites.
The talk explored the significant risks, for users, companies and employees of failing to catch software application failures before release (for example, looking at releasing Apple Maps with significant failures). And discussed how combinatorial (also orthogonal array or pairwise) software testing can be used to create test plans that test a large number of parameters/factors quickly.