The client, an international financial service organization, wanted to upgrade its existing mortgage application with new features, including the integration of a third party insurance system. This would ensure that the mortgages would be intrinsically linked to relevant insurance products, allowing the client to offer its customers a onestop-shop. There was a real competitive advantage for the client to do this; hence it became a strategic initiative with senior business sponsorship.

The project itself was made of three distinct components; integration of a new 3rd party insurance application, implementation of a maintenance release and a complete Siebel upgrade. Each of these would provide a challenge individually, and it soon became clear that the integrated technical solution was not robust. AppLabs was engaged to help the client understand what was causing the issues and how the client should approach mitigating the business risk that was being exposed.

Initially, AppLabs completed a smoke test against the integrated applications. This highlighted that an upgrade to the latest Siebel version of the application was failing to work with the current configuration of LDAP. To overcome the repercussion, AppLabs recommended the client to implement a Risk Based Testing approach. This will mitigate the risk of not being able to test all planned items in scope. AppLabs has a comprehensive and defined method of implementing Risk Based Testing, so changing policy to meet the business challenge was relatively seamless.

By the time the test environment was configured and ready for test execution (without the Siebel upgrade), all the preparatory work for implementing the Risk Based Testing had been completed. The profiling of tests was carried out in such a way that the planned 1000 test cases, was reduced by 20% to 800 test cases–all of which were executed within the timeframe to meet the original implementation date.

The improvement in the testing processes and move to Risk Based Testing resulted in true efficiencies. The approach resulted in a reduction of 360 man-days to the project–equating to a saving of £144,000–representing 11% of the project’s testing budget, and above all hitting the deadline date.

Static Testing is a well-known and beneficial concept within the testing space, but tightened budgets and looming deadlines can hinder the benefits. Here are few suggestions on how taking a risk-based approach to static testing can help realize the benefits.

Implementing Static Testing
For implementing static testing, it is advisable to create a small dedicated implementation team with specific roles. It should include the Process Champions who would be backing the process, the Trainers, and most importantly the Implementers, who will need to develop and document the process; examples of the process materials and collateral required are, Static Testing Policy, Strategy; Review Process, Review Techniques and Guidelines; Templates – Review Logs, Review Metrics, Document Review Matrix; Training courses. The other factors to consider for the implementation are, verifying the internal materials by using the process and templates and involving people from different projects/teams in the development of the materials.

When actually implementing Static Reviews, experience has shown that a phased approach is often best, both in terms of minimizing the impact and also being able to demonstrate early benefits as a result. For this reason AppLabs recommends an approach making use of a pilot and then a full implementation:

The strategy behind the pilot approach is to provide a least risk environment which will allow early demonstration of some or all of the benefits of Static Testing. Having experienced at first hand how this approach can provide a successful basis for further implementation(s), AppLabs has recognized some essential factors that will contribute to success.

• Target small area/project that is ideally in (or not much later than) start-up phase;
• Establish implementation plan;
• Train nominated project staff;
• Execute Review techniques on selected documents;
• Evaluate success of process, training and process materials, and identify areas for improvement;
• Rework process and training materials as appropriate and create baseline set for publication.

The full implementation of Static Testing should build upon the success of the pilot and it is particularly important to document and publicize the benefits demonstrated by the pilot.

Risk-Based Static Testing
While conducting a risk based approach to static testing, identify the product. Compile a list of all the deliverables that are going to be created or changed by the work that you do. For each of the identified products consider the associated level of risk, assign a rating to each product accordingly. Establish a product review matrix, and then plan a review technique- formal and informal. Include Inspections, Structural Reviews and Walkthroughs while conducting the formal review. And for the informal review employ “Buddy Checks”, a simple peer review of the artifact and Desk Checks. A pre-requisite to any review should be that the artifact in question has been quality checked by the author. Most importantly, identify the right people to involve in reviews – rotate responsibility to encourage cross-skilling, and to keep the process ‘fresh’.

The major purpose in Risk Based Static Testing is early mitigation of risks with the most appropriate use of time and resources. Industry statistics have demonstrated that identifying and correcting defects at the source document stage is several orders of magnitude less costly than correcting them in the development or dynamic testing stages. The British Computer Society estimates that for a 3% investment of the overall project budget in Static Testing, 70% of defects can be found by eradicating assumptions and ambiguity from documents before a line of code is written or a system is configured.