So banks can test their software correctly – Computer Week

The test management of SAP applications as ‘SAP for Banking’ should not be underestimated by corporate users. Neglecting those responsible in the company, the topic, the related consequences can be quite severe. To meet the challenges, the methodology of risk-based testing provides a solution for banks.

The current challenges in Test Management

Among the current challenges in test management before especially the more stringent regulatory requirements. The Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) calls for regular assessment of the criticality of processes and compliance with the minimum requirements for risk management by MaRisk AT 7.2 (technical and organizational features). These include the occupation of test management by an independent body and the requirement that substantial changes are to be tested. These rules are not only on paper. BaFin also comes into the house and checked. Violations can lead to negative sanctions, up to the commitment to increase the capital.

In addition to the regulatory requirements, the test management needs due to changes in the market to react quickly to short development cycles. In parallel, the test and operational environment through portals, services, numerous interfaces and high safety requirements on the Internet more and more complex and the test window is smaller. In addition, release change from SAP applications (eg SEPA) often require regression testing of all processes.

consequences for the Test Management

The impact of these changing conditions are high testing costs, caused by complex test environments , the increased use of internal collaborations or by the substitution of internal testers by external resources. Ignoring the new requirements, companies have to take in consequence of a not or insufficiently tested software in purchasing. In the worst case, the lack of quality auszurollenden programs leads to negative external effects on the business processes of the bank.

Experience in practice show that often a lot, but not always the right thing is being tested. Two typical examples:

• As part of a new release regression tests the printing line is tested, although at the interface has not changed. Result: The provision of infrastructure has been delayed. The total decrease in the test is at risk

• Or. For the test, the rollover of mortgage loans, there are twelve variants, all ‘very high’ weighted by the priority. Shortly before end of the test shows that only two variants could be tested and the remaining time for the implementation of the remaining test cases is not enough.

And this is where the methodology Risk-based Testing on. The following are the experiences with the risk-based assay are described below.

The Methodology Risk-based Testing the example ‘Loan Management’

The basic procedure is always the same. First, the criticality of processes, as prescribed by the BaFin, regularly, eg annually, determined. In the example below, in the first step, the relevant evaluation criteria such as visibility to the customer, recorded and weighted impact on the process, call frequency and safety relevance. This is followed by per process evaluation. That is: How critical is the arrival of malfunctions for each criterion. In the example, an error in the ‘contract system’ a very high visibility to the customer and a very high impact on the execution of the process ‘contract system’. The call frequency must be assessed as ‘very high’ and the security relevance as ‘high’. As a result of the process ‘contract system’ a weighted criticality of ‘very high’

Risk-based Testing – simplified practical example of the, loan administration ‘
Photo: innobis AG

Regardless of the assessment of Criticality be assessed the changes to the software for the respective process in the second step for each project. Criteria for projects around SAP applications are for example:

• functional changes (adaptations or extensions),

• Changes in the data structures (eg, new or modified fields)

• Changes in Customizing

In the example, be determined for the process ‘contract system’ very high functional adaptations and medium-sized changes in the data structures and in Customizing. This results in a weighted evaluation of the changes brought about by the project of ‘high’.

In the final step, the priority or the scope of the test cases from the criticality of the process and the evaluation of the changes brought about by the project is determined. In the present case, for ‘Partner Management’ a priority ‘medium’. This value is to be regarded as a frame or guardrail for the prioritization and scope of the test cases, but not an absolute requirement. This review is carried out in a workshop with the project management as well as stakeholders from the various departments and the test management. Create departments following on the basis of the priority test cases.

Optionally, yet priorities for types of tests are defined. In the example requires the process ‘partner management’ no load and performance testing and regression testing applies because of software encapsulation a low priority.

Empirical

Risk-based testing in to establish the practice is not automatic, but rather a tough process. Resistors usually result in particular of lack of time or lack of knowledge of the methodology. The key to success is this: a lot of persuasion with the stakeholders and a well-prepared assessment workshop

The three-step approach outlined above is rarely pursued.. The main reason are not existing process models or rough processes. Also, the test management here is often not the driver of the process. More often starts with the assessment of the project and derived from the priority of test cases or test objects. Especially with new developments the reduction potential for the tests is rather low. But in any case, can be defined by the prioritization sequences for testing. If time is short, omitted the test cases with lower priority. Extremely rewarding the use of risk-based testing in the planning of regression tests, for example, the release change. There are not, as is often the case, all functions or infrastructure components blind tested, but the focus of the test is on the really important features or on the software changes.

As an introduction to the methodology is quite suitable also the start with Step 3. One successful approach is – on the basis of a test case matrix with primary test cases and variants (for example, product types) – to work with the departments to prioritize. Why should the variants C, D and E are still intensively tested, if A and B are working properly?

Conclusion

It is always worth it, regardless of the selected variant, in the topic Risk-based Testing enter. It is the beginning, however, to invest persuasion and methodical work in the implementation. But: Just the evaluation workshop with the project management, the departments and the Test Management brings a common view on the testing priorities. Ideally, can reduce the cost of test by the focus on the really important test and improve software quality. As a side effect, the approach satisfies the requirements of the BaFin regards regular evaluation of criticality of processes.

The Methodology Risk-based Testing the Test Management
Photo: innobis AG