Murali is from India and is an experienced Software Quality professional with over 18 yrs of testing experience. He’s a passionate, hands on tester himself and likes to contribute towards the larger testing community with thoughts on specific areas.
Apply Risk based testing for Software Functional Tests
Risk based testing has been talked about for some time now. This article attempts to detail simple ways to apply this methodology and looks at how testers can use this methodology for testing in appropriate situations. While Risk based testing is a vast subject that needs the use of Scientific methods and techniques for testing, this articles provides a sneak peek into the subject.
Questions that come up related to this:
- How is this different from the normal testing methodology and approach?
- Which projects and circumstances can this be applied ?
- What techniques can be used as a part for this methodology ?
- What are the benefits that will accrue from this methodology ?
- Can this be applied to all testing projects ?
- Do we need to look at only Product risks or at Project risks also ?
- How can we generalize risk areas across projects ?
- How can we ascertain the product risks even before getting to know the product features and technology?
When it can be applied- Use cases:
- The software has been tested earlier and the user is aware of the areas that are prone to defects, high risk area.
- The user has tested the software before and knows the areas that have gone untested, or the testing of a few features that has been accomplished using work arounds.
- Testing has been done but with workarounds and lack of test data
- Testing for certain areas was done partially due to the lack of integration with external systems
- Testing for a few features were not done due to lack of test environment
- Testing has been done but testing for a few features had been deferred
- Can be applied during regression tests
- There is a time constraint and shortened schedule/ period to test a software and hence some urgent critical area tests need to be achieved.
- The user is fully aware of the business domain and can use their knowledge to focus extensive tests for specific areas
- Mission critical apps have to be tested risk based in addition to the regular multiple rounds of testing
- User is aware of the product features and can foresee the risk areas within the product
- Observed that there are a lot of defects / bugs getting reopened during the retest and regression tests.
How it can be applied -Use cases:
Use case 1 – There are areas in the software that require complex calculations and hence this area is classified as high risk and tested extensively
Use case 2 – There are areas/ features in the software that had a lot of defects and hence regression and retest of these features are warranted
Use case 3 – There are features / areas in the software that has integration with external systems and hence are high risk areas need to be tested extensively.
Use case 4 – There are a lot of dependency between the features or functionality in the software and hence these areas need to be tested extensively
Use case 5 – There are tests that require specific data or long drawn conditioning of data to achieve the test, hence these areas are identified as risk areas
Use case 6 – There are time constrains to test and hence important customer facing features and main functionality needs to be tested extensively, while other low priority tests can be deferred for later.
Use case 7 – In mission critical applications all areas are high risk areas and need extensive testing
Use case 8 – Customer dissatisfaction will be triggered if certain features contain defects and hence these need to be extensively tested.
Use case 9 – Frequent changes occur to the Application Under Test and hence regression areas need to be identified and classified based on risk to plan the tests
Use case 10 – There are features in the application that have financial implications and can cause financial loss, and hence classified as High risk areas for extensive tests.
Use case 11 – There are data intensive tests that need to be classified as a higher risk for testing