Types of Software Testing – R

Ramp Testing:

Continuously raising an input until the system breaks down. This is a type of testing is conducted to check the response of the software with constant increase in workload on the software. Ramp testing enables testing the ability of the software to sustain gradual increase in work load.

Recovery Testing:

Testing that confirms the program recovers to its contextual base-state from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

Red-Box Testing:

Acceptance Testing is otherwise called as Red-Box Testing that is conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.

Regression Testing:

Re-testing a previously tested program following modification (bug fix or enhancement or new feature introduction) to ensure that faults have not been introduced or uncovered as a result of the changes made.

Whenever a change in a software application is made it is quite possible that other areas within the application have been affected by this change. To verify that a fixed bug hasn’t resulted in another functionality or business rule violation is Regression testing. The intent of Regression testing is to ensure that a change, such as a bug fix did not result in another fault being uncovered in the application.

Regression testing is so important because of the following reasons:

  • Minimize the gaps in testing when an application with changes made has to be tested.
  • Testing the new changes to verify that the change made did not affect any other area of the application.
  • Mitigates Risks when regression testing is performed on the application.
  • Test coverage is increased without compromising timelines.
  • Increase speed to market the product.

Regression Testing types are functional regression tests by testers and Unit regression tests by developers.

Reliability Testing:

This deals with testing software’s ability to function under given environmental conditions for a particular amount of time. Software reliability is the probability that software will work properly in a specified environment and for a given time, where

Probability = Number of failing cases / Total number of cases under consideration

To achieve the satisfactory results from reliability testing one must take care of some reliability characteristics.

For example, Mean Time Between Failures (MTBF) = Mean Time To Failure (MTTF) + Mean Time To Repair (MTTR).

MTTF is the difference of time between two consecutive failures. It is measured in terms of three factors – operating time, number of on off cycles and Calendar time.

MTTR is the time required to fix the failure.

Types of Reliability Tests are Feature Testing, Load Testing, Stress Testing and Regression Testing.

Retesting:

This is a type of testing that is carried out as a part of defect fix verification. For e.g. a tester is verifying a defect fix and let us say that there are 3 test cases failed due to this defect. Once tester verifies defect fix as resolved, tester will retest or test the same functionality again by executing the test cases that were failed earlier.

Resilience testing:

This is a type of testing carried by performance engineering team to assess how stable the software is when it is subject to incorrect data, large workloads and more volume of data to be processes.

Recovery Testing:

This is a type of testing performed by software testers. Recovery testing aims at checking how soon and how efficiently software can recover from software crashes, Operating system crashers, and hardware failures. Recovery testing is not the same as fail rover testing or reliability testing.

Risk based Testing:

This is a type of software testing and an different approach towards testing a software. In Risk based testing, requirements and functionality of software to be tested are prioritized as Critical, High, Medium and low. In this approach, all critical and High priority tests are tested and them followed by Medium. Low priority or low risk functionality are tested at the end or may not based on the time available for testing.

Create a free website or blog at WordPress.com.

Up ↑