Destructive Testing (DT)


Destructive Testing is defined as a software testing type to find points of failure in a software program. It is a testing method where an application is intentionally made to fail to check the robustness of the application and identify the point of failure.

Unlike other testing method which checks the function of an application, this technique will check the unpredictable user behavior within the application. For Destructive Testing, it is not necessary to have the knowledge of the original requirements of a software product. However, some knowledge could help in developing a good testing strategy.

Why to do Destructive Testing?

  • It helps to understand predictable software behavior when the software is put under improper usage.
  • It helps to check the robustness of a software product.

What you check in Destructive Testing?

In Destructive Testing, you will check for following things
  • Proper software behavior
  • Improper software behavior
  • Improper usage
  • Improper input data
  • Proper output data



Destructive Testing Methods

  • Tensile Test (high temp. & room temp
  • UTM – 100 Tons
  • Torsion
  • Creep
  • Bend Test
  • Impact Test
  • Flattening Test
  • Hardness test on various measuring scales
  • Wet analysis
  • Positive metal Identification (PMI)

How to do Destructive Testing?


Destructive Testing involves many activities like designing a set of test scripts, executing test scripts, raising bugs, closing bugs, and providing the pass or fail metrics to stakeholders at the end of the iteration. For Destructive Testing, there are numerous ways it can be tested. Some are:

  • Failure point analysis method: It is a walkthrough of the system conducting an assessment of what could go wrong at various points. For this strategy, help from BA (Business Analyst) may be taken.
  • Tester peer review: Get your test cases analyzed or reviewed by a fellow tester, who is less familiar with the system / function
  • Business review of test cases: The end users or experts may think of many valid scenarios which sometimes testers may not have considered or missed as their entire focus will be on testing the requirements
  • Conduct exploratory testing, using run sheets: Exploratory testing using run sheets, will help to determine what was tested, repeat the tests and allows you to control your test coverage.
  • Use other source: You can ask someone to break the software product and analyze for various scenarios.


Phone:

+91-9871418181, 9910933633, 8317054803

Address:

Plot no.13, Badoli Village, Sector - 75
Faridabad - 121002, Haryana, India

Email ID:

acrolnr@gmail.com