Disruptive testing is a type of testing which is carried out to make a software application crash or fail in order to determine the behavior of the application when different amounts of load are applied to it. It is the best suitable for the products which are produced in large quantities since the loss for destroying a small number of quantities would be less than the cost of destroying the larger one. For example, mobile testing. When a new version of a mobile software is developed, it will be used in a large number of handsets and the risk of not performing load or stress test can affect the business extensively.
Disruptive testing is comparatively easier to perform, yields more information than other types of non-functional testing. It determines the robustness of the software. Let’s understand this type of testing in detail starting with the types of disruptive testing.
Types of Disruptive Testing:
Disruptive testing is of the following types:
Destructive testing:
It is the traditional way to test the robustness of the software application. As discussed before, this test is conducted to determine the behavior of the application when different quantities of load are applied to it. Destructive testing is also used to verify that the software functions properly even when it accepts invalid or unexpected inputs, which helps to establish the robustness of input validation and error-management routines
Exception handling testing:
Exception handling is a part of destructive testing when the system fails there should be a certain process in place in order to respond to the occurrence, during computation of exceptions, irregular or exceptional conditions that require special processing than the normal program execution flow. Such exceptional handling is provided by the programming language constructs or computer hardware mechanisms.
Recovery testing:
Recovery testing is the type of testing to test the behavior of the software application to recover from hardware or software crashes or failure. Recovery testing is facilitated through the forced failure of the software in numerous ways to verify that the recovery is properly performed or not. It is different from the reliability testing, where we are just focused on testing the failure point.Recovery testing is a basic test done to check how quick a software application can recover against various kinds of a crash, hardware failure, or other catastrophic problems, etc.
Advantages of performing disruptive testing:
It helps to determine the software application behavior when the software is subjected to the improper usage.
It helps to check the software product robustness.
Disadvantages of performing disruptive testing:
An additional cost to the organization.
Destructive Testing Strategy:
As any traditional testing, the Destructive Testing has test cases designing, test scripts development, test scripts execution, bugs raising, bugs closure, and providing the testing report to the stakeholders after the completion of the testing. The following are some of the ways to conduct the destructive testing.
Methods to analyze the Failure point: In this strategy, the Business Analyst could play a key role in the system walkthrough to conduct an assessment of what could go wrong at various points.
Peer review: Test cases should be reviewed by a fellow tester or peer who is not very familiar with the system operations.
Test cases review: It is commanded to be done by the end users or experts who know various application scenarios very well. Such scenarios could have missed by tester while designing the test cases but experts may help to include those missing test scenarios.
Conduct exploratory testing: Exploratory testing, as usual, can help to determine the quick application robustness by hitting tests directly on the application weak areas.
Monkey testing: It aims at breaking the application at any cost. The expert can directly catch the jugular vein of software and hit there to break the application.
How to perform disruptive testing?
In destructive testing, we verify the following things:
Proper software application behavior: It is the check of the software behavior during the various request volumes that comprises from low request volume to the peak request volume. The aim is to crash the application and study the behavior of the application under test.
Improper software application behavior: The reliability testing is done to mark the point where the application can deliver the proper behavior before it can break down. But at the same time, it is essential to know about the improper application behavior when we conduct destructive testing beyond the breakpoint. These specifications could be useful to the application support team for the smooth operation of the application in the production mode.
Improper usage: There could be scenarios of improper use of software application such as frequent peak volume or unexpected volume. Under such scenarios, the exact behavior of the software application should be known beforehand which can only be possible through destructive testing.
Improper input data: It is not always the case that the valid input data is fed to the application. There could be scenarios where invalid data will be fed to the application which may result in the application crash. Again, such behavior and the robustness of the application could be tested through the destructive testing.
Proper output data: All computer applications follow the default rule of GIGO i.e. Garbage in and Garbage Out. Destructive testing can be used to study the application behavior against garbage input against garbage output which explains the level of validations placed within the application to overcome the situation of software crashes or failure.
Conclusion:
In the destructive testing technique, a software application is purposefully made to crash or fail the program in order to check its robustness. Also, to conduct the destructive testing it is not crucial to have the application knowledge of the original requirements.