What is destructive testing?

Destructive testing is a testing technique in which the application is made to fail in an uncontrolled manner to test the robustness of the application and also to find the point of failure.

Destructive testing is performed under the most severe operating conditions and it is continued until the application breaks. The main purpose of destructive testing is not only to determine the design weaknesses if any which may not show up under normal working conditions but also to determine the service life of the product.

Destructive testing is a software assessment method used to find points of failure in a program. Essentially, the method involves interacting with the software incorrectly, for example entering data that is corrupt or in the wrong format, to determine whether the application would fail were an end user to make that error.


Why we have to perform destructive testing?

As every user to the system is not same, some user may handle the system in incorrect way. So by performing this testing we are able to sure that what happen when some error will occur due to improper use of it.

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.

What do you keep in mind to perform destructive testing?

  • 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.
  • Organize 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!

Techniques to perform destructive testing

  • Failure point analysis: This is a walk-through of the system, performing an assessment of what could go wrong at various points. This is a really useful exercise but involves some help from a BA (Business Analyst) and/or an Architect. The aim of this is to go into a lower level of detail and discuss some ‘what if’ scenarios. For example, ‘what if the system goes down before it has received the response to a request?’
  • A fresh pair of eyes / tester peer review: Get your test cases reviewed and analyzed for gaps by a fellow tester who is not as familiar with the system / function as you are. This can sometimes help because when you work on something for a long period, you get used to the product and make assumptions without realising it, forcing you to miss the obvious.
  • Conduct a business review of test cases: This is a task which I would encourage with any project. The Business / end users will normally think of many valid scenarios which you, as a tester, may not have considered. This is generally because the test team will focus testing on requirements, rather than the full end to end business process (although some tests can be written to cover business processes). The point is, testers are not normally SME’s in the end system or the business processes, so an expert will be able to pick up new test scenarios which will stretch the software a little further.
  • Perform exploratory testing, using run sheets: If you have the time and the resources to do this, exploratory testing should always be a consideration. Using run sheets can be useful in helping to define what was tested, repeat the tests and enables you to control your test coverage. Exploratory testing can be utilized using business resources as well as test team resources.
  • Ask someone to break it: This is a fairly straight forward idea but again it can yield some interesting results and defects. This approach is a little unstructured for my liking but as long as you perform actions which are not ‘happy path’ or duplicates of previously executed tests, then there should be some value in it.

Advantage of destructive testing

  • By performing this testing we can find point at which system is venerable.
  • It provide the error occurs when user enters wrong input. For example in the field of phone number user entered alphabet value which leads into an error.


The goal of destructive testing is to ensure a software product exhibits proper behaviour when subject to improper usage or improper input. Ongoing work includes the development of requirements specification that mandate destructive testing of a case study software product.

Destructive testing is a reflection of the fact that user will sometimes use a software product in an improper manner. Destructive testing does not replace conventional testing. But it performed in addition to conventional testing.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>