Banking IT: Tips for test management

Since the publication of the circular "10/2012 (BA) - Minimum Requirements for Risk Management MaRisk" and the explanatory notes 12/2012 by the Federal Financial Supervisory Authority (BaFin), there have been a large number of measures to be implemented in the IT of banks, in particular to meet the requirements of AT 7.2 and AT 7.3. Announced special audits in accordance with Section 44 (1) of the German Banking Act (KWG) challenge business and IT managers alike.

Numerous formalities and administrative hurdles have to be overcome in addition to the heavy burden of day-to-day business. Of course, the regulatory requirements must be met, but it is not uncommon for measures to overshoot the mark. It is important to find an appropriate implementation path.

Connecting specialist areas, development and operations

Test management forms the central link between the specialist area, development and operations. Measures prescribed in the test lead to considerable side effects in the areas mentioned above.

The following section outlines pragmatic and tried-and-tested approaches along the software development process that can be used to fulfill the regulatory requirements from a test management perspective. A checklist (see next page) can be used to verify which components still need to be implemented.

New or modified software must be tested. The technical specification of the test cases immediately before the test phase by the specialist departments is often a tough process. It is much better to request a description of the test scenario for each formulated requirement during the conception phase.

Concept: Roles and authorizations

The topic of roles and authorizations is usually treated rather neglected. Here too, IT should insist on the correct and complete definition, the separation of functions and the formulation of corresponding test scenarios as early as the conception phase.

Development: SAP ChaRM

Up-to-date and lean development guidelines with naming conventions, guidelines for dealing with critical programming techniques and tips for optimized program code are now a must.

An integrated request and transport management system is also recommended. For SAP users, the SAP Change Request Management (ChaRM) component of the Solution Manager with dedicated approval procedures, strict role separation and audit-proof proof of the transport chain from development to test and acceptance systems through to production is ideal.

Not many development departments take the time for code reviews using the dual control principle. Here, too, there are now good tools on the market that check program code for security-relevant vulnerabilities and prevent it from being transported to quality assurance or production systems in the event of rule violations.

In the SAP environment, the Code Profiler from Virtual Forge and the SAP Code Vulnerability Scanner are regarded as leading tools. The prerequisites for the specialist test are documented module tests by the development department and the identification of test restrictions such as functions that have not yet been completed or known errors.

Supporting tools are also available here. The ChaRM component of the SAP Solution Manager, for example, enables the documentation and verification of module tests.

First and foremost, it is advisable to clearly define the test management processes and the roles in the test and acceptance processes and to provide templates for test concepts or test case descriptions, for example. Here, too, the principle applies: "Less is more."

Separation of roles

Long prose passages are not read. Checklists, tables and graphics are better. Incidentally, strict separation of roles between the specialist area, development and testing is important in order to meet regulatory requirements.

Excel-based test management procedures have become obsolete. Tests and deviations must be documented and stored in a traceable and audit-proof manner. The use of integrated test management tools such as the HP Application Lifecycle Management (HP ALM) Quality Center, IBM Rational Quality Manager or the SAP Solution Manager Test Workbench is mandatory.

For security reasons, no sensitive (especially personal) data may be used in test environments that are not centrally managed. For example, business partner data must be anonymized. A process must be defined for access to test data by testers (and possibly by developers for error analysis). The assignment of user IDs and authorizations must be logged.

Test management: Calculated risk

Risk management is becoming increasingly important. The bank must also demonstrate that test risks such as the late provision of the software to be tested or a lack of test infrastructure are recorded and evaluated and that appropriate migration measures are implemented and tracked.

The risk-based test approach has proven its worth. In this procedure, processes are evaluated according to criticality, such as call frequency or security requirements, as well as with regard to changes and adjustments in the ongoing test project.

The scope and priority of the test objects and test cases involved are derived from this. This shifts the focus to the really important tests in a risk-driven manner.

Test management is responsible for proving that mandatory result types such as a test concept or test planning have been created, that mandatory tests such as security or disaster recovery tests have been carried out (or reasons given for not carrying them out) or that the acceptance process has been properly completed. This is where a checklist-based internal control system (ICS) comes in handy.

Implementation and operation

Defined handover procedures with strict separation of roles between development and operations are important for implementation. For operations, an information security management system that is as tool-supported as possible should be established and operated. From a test management perspective, reference can then be made to regular standby procedures for disaster recovery, for example.

Conclusion

The measures listed above to meet the regulatory requirements must be implemented. A holistic approach and the implementation of pragmatic and tried-and-tested approaches are recommended.

The checklist can be used to verify which modules still need to be introduced. Furthermore, standards such as BSI standards 100-1 to 100-4, ISO 29119 (test) or ITIL should be used.

Checklist

These points provide an initial overview of whether and which components have been implemented (not/partially/completely fulfilled):

1. Is the definition of test scenarios for requirements mandatory?
2. Are changes to roles and authorizations described?
3. Are there development guidelines?
4. Has an integrated order and transport system been implemented?
5. Are the roles in the rollout of software strictly separated between development and operations?
6. Are code reviews carried out?
7. Are there supporting quality assurance tools in development?
8. Are module tests carried out and documented?
9. Are test processes and roles described in test management?
10. Is there a strict separation of roles in the test between the specialist area, development and testing?
11. Is an integrated test management tool available?
12. Is sensitive data protected/anonymized in test systems?
13. Is there a procedure for assigning users and authorizations for test systems?
14. Are the test risks documented, evaluated and tracked?
15. Is the execution of test cases prioritized?
16. Is the creation of mandatory result types and mandatory tests systematically monitored (ICS checklist)?
17. Is there a defined process for accessing sensitive test data?
18. Is the handover process to production defined?
19. Is an information security management system in place?
20. Are standards such as ITIL, BSI or DIN ISO standards used?