How can we reduce the risk by using a test plan?

A test plan apart from just serving the purpose of a guide for the software testing life cycle also plays a great role in the assessment of the risks associated with the development of that particular software system or application and also provides the alternatives or builds for overcoming those factors which are the root cause of the risk.

The preparation of the test plan must be based on all the risks identified during the process of risk assessment. This article is focussed up on the relation that exists between the risk and the test plan and how a risk based test plan can help reducing the overall risk.

How a risk based test plan reduce the overall risk?

- Such a test plan is effective only when a test oriented risk analysis is carried out during the software system or application development life cycle.

- With the advancing and sophisticated technology the complexity of the software systems and applications is also increasing and so does it lengthens the testing process which is quite exhaustive.

- The software testing methodologies therefore should be quite selective and should also be chosen keeping in mid the time limit and the budget of the project.

- It is often stressed by many testers that the testing should be based on the risk which is not possible until and unless the testers are well equipped with the knowledge of the risk.

- It is a wise decision of concentrating the testing more on the area which is at higher risk compared to other parts of the software system or application.

- Many researchers have made a rigorous research on the subject of risk based testing and have stated that a software system or application requires apart from the understanding of software testing, the knowledge of risk and its analysis also.

Types of Risks
There are two types of risks namely:

1. Forward Risks
These are the risks associated with the operation of the system and one of the major cause of the software failure.

2. Backward Risks
These are the risks associated with the development issues like those mentioned below:
(a) Inappropriate design
(b) Casual programming
(c) Incorrect specifications
(d) Inadequate management

Risk is thought of as a function of two components as described below:

1. The probability of occurrence of an undesirable event that is defined and
2. The degree of the severity of the consequences if the event of the system failure does occur.

In most of the cases, the consequences following the failure of the software system are related to the purpose of the software and therefore reducing the risk is not always an option.

Thus, this leads us to the conclusion that the risk must be reduced by reducing the probability of the failure of the software system which in turn can be achieved only with an efficient test plan.

Now you must be wondering can this actually happen? Yes of course.

- The software testing reduces the risks by digging out many of the bugs.

- But, the actual risk reduction is based up on the implementation of the corrected code and functions.

- The failure of software system is not systematic and hence cannot be predicted by just checking out the history.

- So for the cases like these, only the estimation of the potential consequences of the failure works via the risk based testing that acts as a single factor analysis in
such cases.

- For some it may seem like a trivial process but, it is not so and calls for a thorough examination of the system failure.

- The single factor analysis though does not produce a very correct estimate; it does help the testers in focussing their testing on the code that is buggier than the other units.

How to assess alternative architectural designs?

There are many architectural alternatives that need to be assessed. There are different ways to assess the design:

Trade off Analysis Method
It establishes an iterative evaluation process for software architectures. It involves six steps:
- All the scenarios are collected.
- Requirements, constraints and environment description are elicited.
- Architectural styles or patterns chosen to address scenarios and requirements are described.
- Quality attributes are evaluated.
- The sensitivity of quality attributes to architectural attributes are identified.
- Critique candidate architectures using sensitivity analysis.

Architectural Complexity
In architectural complexity, the dependencies between the components are assessed within the architecture. Dependencies can be divided into:
- Sharing dependencies represent dependence relationship among consumers or producers.
- Flow dependencies represent dependence relationships between producers and consumers of resources.
- Constrained dependencies represent constraints on the flow of control among set of activities.

Architectural Description Languages
Architectural description language provides a semantic and syntax for describing a software architecture. It is a set of tools and notation that allows the design to be represented in an unambiguous and understandable fashion.

Understanding Rapid Testing and Rapid Testing Practice

Rapid testing is the testing software faster than usual without compromising on the standards of quality. It is the technique to test as thorough as reasonable within the constraints. This technique looks at testing as a process of heuristic inquiry and logically speaking it should be based on exploratory testing techniques.

Although most projects undergo continuous testing, it does not usually produce the information required to deal with the situations where it is necessary to make an instantaneous assessment of the product's quality at a particular moment. In most cases the testing is scheduled for just prior to launch and conventional testing techniques often cannot be applied to software that is incomplete or subject to constant change.

It can be said that rapid testing has a structure that is built on a foundation of four components namely:
- People
- Integrated test process.
- Static Testing
- Dynamic testing
There is need for people who can handle the pressure of tight schedules. They need to be productive contributors even though the early phases of the development life cycle. It should also be noted that dynamic testing lies at the heart of the software testing process, and the planning, design, development, and execution of dynamic tests should be performed well for any testing process to be efficient.

Rapid Testing Practice
It would help us if we scrutinize each phase of a development process to see how the efficiency, speed, quality of testing can be improved keeping in mind:
- Actions that the test team can take to prevent defects from escaping.
- Actions that the test team can take to manage risk to the development schedule.
- The information that can be obtained from each phase so that the test team can speed up activities.
If a test process is designed around the answers to these factors, both the speed
of testing and quality of the final product should be enhanced.

Some of the aspects that can be used while rapid testing are:
- Test for link integrity.
- Test for disabled accessibility.
- Test for default settings.
- Check the navigation.
- Check for input constraints by injecting special characters at the sources of data.
- Run multiple instances.
- Check for interdependencies and stress them.
- Test for consistency of design.
- Test for compatibility.
- Test for usability.
- Check for the possible variability's and attack them.
- Go for possible stress and load tests.