Destructive Software Testing

Gunner or Bombardier?

Tester at work

What is destructive testing?

Definition: Destructive testing is the method of identifying the point of an applications failure.

(Sounds like regular functional testing, but it’s a bit more than this….)

What’s the difference between destructive testing and conventional testing?

Conventional testing: It is a process in which an application will show that it can perform its functions correctly.

This process often involves gathering/designing a set of test scripts, executing the test scripts, raising bugs, closing bugs and providing your stakeholders with Pass / fail metrics at the end of your iteration / sprint / test pass. This is a controlled process which we all know is relatively effective and provides us and our stakeholders with an degree of confidence that the end user will be able to perform their desired tasks correctly and to completion.

So now how do we know that this same fit for purpose application can handle incorrect use? We generally don’t! This is where destructive testing comes in. By practicing destructive testing you are already aware that sometimes the user will not use the application correctly.

Now by incorrect use I don’t mean ultimately logging a defect with a summary of “Application refuses to start after I threw my laptop out the window”. I mean by performing unpredictable behaviour within the application, it’s only then that we’ll know that the application can handle it gracefully.

Perhaps you want to buy a new phone and, since you’ve been known to be a bit clumsy, while in the phone shop you want to test the durability of the phone. How do you this? Well firstly, you don’t fling the phone off the wall. You feel around the phone and maybe even apply a little pressure to the phone to see if it, let’s say for example, BENDS. This would be a perfect example of destructive testing as you are trying to identify the point of failure for this phone and in a controlled fashion.

Now let’s look at a date field for example and type in “first of January two thousand and fifteen”. We don’t want to be presented with an error written in a language that only a software professional can understand. We want to be in a position where we can predict the outcome of unconventional use and in this case, be presented with a user friendly message such as “Date format must be in MM/DD/YYYY”.

It goes without saying that the realms of destructive testing will go beyond a date field. I personally have seen QA professionals input styled html mark up into text fields and watch an app crumble before my eyes. This is in essence the purpose of destructive testing. “Identifying the point of an applications failure”

So what do you do to adapt this mind set?

  • Disregard what the requirements say you can do. Do what you want with the application!
  • Ignore the process flow/happy path. Follow unpredictable GUI sequences.
  • Organise a black box session or even a bug bash. Give the app to someone who doesn’t know how to use it and watch them get to grips with it. This will especially help in developing your destructive techniques for the next time!
  • A white box approach can also be useful for developing a good destructive testing strategy so now do the opposite! Requirement says this is a number field; enter in alpha characters and vice versa!
  • Corrupt data is a tool, enter it in! Or even some code!

It sounds like simple stuff really but you’d be surprised how often something this trivial will go unnoticed and leave users perplexed with “fatal errors” and the likes. That is why I feel it’s important that a destructive testing strategy is included in conjunction with, and not independent of, conventional testing methods, since along with the application now being fit for purpose, it should behave predictably when presented with unpredictable behaviour.

About the author

Mohanid Ragel has been working in QA for 8 years across multiple sectors, most recently working on projects for medical software, financial and CRM institutions. He is currently working on an overseas collaborative Project for a U.S. Financial institution.

His main interests in QA are in process implementation, automation and Mohanid is currently undergoing the ethical hacking course (C|EH v8). Mohanid loves the technical aspect of QA and always looking for new ways to improve the QA function within an organisation.

You might be interested in... The Dojo

Dojo Adverts-05

Tags:

One Response to “Destructive Software Testing”

  1. John VorisMarch 16, 2015 at 6:59 pm #

    In this vein, one outrageous test of an input field on a webpage is not keyeing something in from a keyboard, but doing what a user might do – copying and pasting from a word document – with all those odd hidden paragraph marks embedded not entered in your input field. Or copying and pasting from a webpage.

    It is beyond the edge case of a date (like the 107 year old born in 1908 that you tested). It can be when you introduce things not found on the keyboard. This is not “incorrect use” – it is normal behavior by a user, and is a sometimes a technique encouraged by a trainer delivering your software.