Business Applications: On the Tension between Efficient Testing and Compliance.
Klaus Haller · Softwaretechnik-Trends · 2015
Smooth business processes need a stable IT landscape. Thus, IT departments spend time and money on testing their business applications. But what could be a reason for a tension between efficient testing and compliance needs? Sensitive data are the reason! Testing business applications requires adequate data in the databases of test systems. Such data are often sensitive: client data in banks, patient records in clinics, patents to be filed, etc. If production data is copied to test systems, many testers and developers have access to sensitive data. Also, this can imply transferring sensitive data to other jurisdictions or to outsourcing partners. This is not only a risk. It might violate laws. This paper helps testers staying compliant with regulations without excessive costs. It is based on previous work on test data [1,2] and information security and data loss prevention [3,4,5]. 2. Test Data Management and Efficiency When testing a calculator, the correct result of a test case depends only on its input values. “3” “+” “4” and “=” is always “7.” In contrast, the outcome for many test cases for business applications also depends on database data. The account balance in the database decides whether a bank client can withdraw 50€ with his debit card. This test case, however, can only be executed if the core banking system can start up and reaches the starting point of the test case, so hundreds of database tables must be populated with data. Thus, a test case for business applications must state what to type in into the GUI (e.g., 50€) plus the database system state to get to the starting point of the test case and the database test objects (e.g. accounts) needed for a concrete test case (Figure 1). Test data management looks on processes, test center organization, and tools in two areas: providing test data (creating or identifying test data in databases based on clearly defined requirements) and managing test data types. The latter is crucial, but often overlooked. Test centers must manage test data types or they lose their investments into test cases. Test cases are only repeatable for years if the data requirement is clear. A test case must not state “test with adequate account.” Better, but only slightly, is “test with account 1234567.” Mostly, the life span of test cases is longer than the life span of data in the database. Accounts can be closed or modified. Then, test cases fail and are “lost.” Thus, test cases must state the type of data needed, e.g., “account with 370€” (see [1] for details). Test data management has to be reflected in the test center organization. If test data types are defined, test centers can centralize the test data provisioning, which can save costs or improve quality. In contrast, test data type management must be enforced centrally, but remains the work of all the test analysts writing test cases. 3. Towards “Clean” Test Environments 3.1 Reduced-Sensitivity Environments A cost-effective and easy way to get good test data is copying production data to test systems. This remains the standard for non-sensitive data. When it comes to copying sensitive data to test systems, more and more concerns are raised by risk or legal and compliance departments [5]. In the following, we present five options to address risk and compliance objections (Table 1). Basic database masking addresses the risk of losing bulk data. Sensitive attributes are masked during the copy from production to test: real names are replaced with random ones, letters and digits in free text fields are replaced with “X.” etc. When applied to all data copied to test systems, testers, for example, cannot extract and sell illegally lists with all clients, offers, patents, etc. A bank can focus on preventing that complete customer lists are stolen. Instead, and more strict, the bank could state to the IT department: Please ensure that testers cannot identify single clients by looking at test data. In the first case, basic data masking is sufficient, but not in the second case. Preventing bulk data loss is easier than making it impossible to reconstruct production data based on masked test data. In the latter case, more attributes are a risk. Often, for example, testers can identify a commercial client by knowing the ZIP code and that he is, for example, a butcher. This can be an issue for outsourcing or offshoring. Two countermeasures exist. During the copy process, the option castrate & inject removes all sensitive data plus all data useful for reconstructing sensitive data (e.g., industry sectors). Then, synthetic data are added so that data is available for most test cases. The option of pure synthetic data goes one step further. It does not copy any data from production to test systems. All test data is synthetic. Table 1: Overview Approaches for “Clean” Test Environments