Destructive Testing or Destructive Software Testing(DST)

May 08, 2019

---

Whenever, we hear or come across the term software testing, the picture that clicks into our mind is that testing a software product requires verification and validation of software functionalities and qualities w.r.t. specified requirements. But, ever wonder that some of the testing approaches involve breaking or destruction of software application or system in order to assess their quality, and destructive testing is one of them.

What is Destructive Testing / Destructive Software Testing (DST)?

Destructive software testing or DST is an alternative approach to conventional type software testing or CST. CST is a systematic and planned approach of carrying out the testing activities in a controlled manner to verify and validate the correct working of the software product with respect to its pre-defined requirements and specifications.

Contrary to CST, DST is oriented towards carrying out the task of testing in an uncontrolled manner with the intent to break or crash down the system so as to explore the points of failure in the software program.

It does not involve any kind of specification or business requirement. It is being performed without getting apprised of pre-decided requirements.

Why Destructive Testing or Destructive Software Testing is required?

It's a common fact that most of the customers are prone to mismanage the software application either by executing inappropriate operations or feeding invalid inputs, which may eventually lead to crash or failure of the software application. The task of DST is to detect these points of failures in the software program, which may occur due to improper handling of the software by the user.

Along with the detection of point of failures, it also ensures the robustness feature and lifespan of the software application.

Steps to perform Destructive Testing or on a software product:

• Walkthrough of the system as the task of failure point analysis to evaluate and assess each and every path and corner of the application, supported by the questionnaire rounds with business team w.r.t user's perspective, what may go wrong in the system, if any? What could be the reasons, etc. in order to detect weak spots, which may account for system's failure in future.



• Exploratory Testing of system as it does not needs any sort of requirement or specification and is being carried out with tester's gradual learning and thinking abilities.
• Pass on the product to your fellow tester, who is unaware and is not used to the software application. This may help in finding some weak or hidden spots of failure, which was invisible to you (tester).
• Feeding system with incorrect, invalid and inappropriate sets of input data and operations such as undesired sequence of GUI operations. This may also include corrupt data, also.

Types of Testing to execute in Destructive Software Testing(DST)

Given below are some of the testing strategies that may proves to be effective for executing DST.

• Top-Down Testing.
• Black-Box Testing.
• Acceptance Testing.
• Loop Testing.
• Boundary Value Testing.
• Stress Testing.
• Interface Testing.
• Beta Testing.
• Regression Testing.
• System Testing.

Key Points of Destructive Testing or Destructive Software Testing(DST):

• DST is an alternative approach to CST but not its replacement.
• Effective to carry out, in addition to the CST.
• It is carried under rigorous working conditions and environment until the software application breaks down.
• Although, DST does not require knowledge of any kind of requirements, but it is still advisable to have little knowledge of the requirements in order to build good and effective test strategy.
• Discovers points of failure in the event of inappropriate or misuse of the software application.
• Guarantees the uninterrupted working of software application, even on feeding invalid inputs.
• Ensures the robustness quality and lifespan of the software.
• Generally, it is performed by QA team.
• Verification and Validation types of testing are ineffective as they work on functional requirements whereas DST is nearly based on non-functional requirements.