The earlier a bug is fixed the cheaper it is for your company to fix it, right?
One amongst many reasons, it helps to set a good reputation for your product, and that’s what all of us want. So we have trained testers to catch those bugs as earlier as possible.
But why, only after we make a release to Production, our customers start to find a high number of functional defects and usability and/or performance problems?
Why can’t we (trained testers) catch those annoying bugs found by our customers? This is all related to our way of looking at the problem.
Testing is all about having the correct mindset and context around a given application or feature.
We are, most of the times, focused and biased by our User Stories instructions and not defocusing enough to search for the surrounding problems in our products, so basically in our tests we try to prove that our product can perform the way that is asked to from the Product Owner.
The thing is, in Web Applications we don’t give an instructions manual to our customers and they don’t really care what was the Epic or User Story that implemented a given feature, and what were the Acceptance Criteria for that matter. They only want the product to work the best and the most intuitive way for them, not for our Product Owner.
For example, imagine the following scenario:
where the result is,
This is just a (stupid) example of things we tested as being OK, because we were too focused in our Acceptance Criteria and not defocusing enough switching our context to a more “customer perspective”.
We tend to keep our mindset in our Sprint as a whole, and sometimes is not easy to defocus from a User Story where we are already looking for the given Acceptance Criteria – to perform the way it’s asked to perform.
In the previous example, we knew that the Logo should be on top, and the log-in section on the right side, etc… but is this what the customer wants? Is this layout according to the industry standards, or easy enough to use or understand?
Now, imagine you are a customer and as a customer what do you want to know from the User Story? Maybe that there is a Landing Page is enough, so your User Story will look like this:
Not knowing where should be the Logo, the navigation and the login section, what would be your comments as a Tester (or a customer) after looking to the same result? Is this acceptable to you?
You’ll be really testing as your clients do when they use your products.
Your criticism regarding functionality, usability, performance, etc, is much higher when you don’t know what, where and how is expected to happen.
Having this is mind, the search for the point of failure or incoherences in your products will be much easier, and that’s what Destructive Software Testing is all about.
Destructive Software Testing
Destructive Software Testing tries to set the right context for the Tester (in my opinion), and erase all the biased information from the User Story.
It also helps to find an application breaking point, because we all know that our customers eventually will not use our products the way they are meant to work, and even our environment conditions (hardware/network) can be very different from the majority of our clients.
A few tips to set the correct context for DST:
- Learn all you can about your product. To think as a customer you have to know at least as much as a regular customer of your product.
- Discard the information from the User Story, at first. Put yourself in a “crazy” customer shoes that tries to break the application just for fun. Basically, explore the new functionality.
- Search for the Exception Paths.. not the Happy one. Remember that, by ignoring the Acceptance Criteria you’ll not know the expected Workflow.
- Don’t expect a correct response from your services/dependencies. What if something fails? Mock and corrupt everything you can.
- Remember that not all customers have last generation machines and network conditions. If possible, throttle your network conditions to a more realistic scenario.
Five simple points that can seem to you what conventional exploratory testing should be. But just the fact that you are ignoring the User Story information (a.k.a Acceptance Criteria) transforms your role temporarily from Tester into a Customer, and that’s why I believe a Tester can perform a pretty similar testing phase as Beta Testing.
Take in account that DST should be your first phase of testing. You’ll always have to confirm the Acceptance Criteria later in order to present the UserStories testing in the Sprint Demo or send them for UAT.
It’s not a perfect technique as there are no perfect software, but from my experience the number of high priority defects found and the number of raised questions from Exception Paths increased a lot.
When testing ask yourself:
Was the new feature easy to use without the Acceptance Criteria or instructions from any Dev or Product Owner?
Were the results of your use cases as expected from a user perspective? Did you understand the workflow and does it makes sense?
Does it bring value to your product as it is implemented?
Does it fail gracefully when an exception occurs?
Honestly, I cannot think of another way to test software.
