Friday 9 August 2013

Domain Knowledge – The Performance Edge

Technical knowledge relates to application-technology
platforms whereas domain knowledge relates to the environment in which the application operates. It reflects the wherewithal to execute day to day  activities to achieve desired outcomes. Though its importance cuts across all industries, there are certain aspects that are unique to testing banking applications.

Challenges for testers:

Legacy Systems :

The changing environment and other due-to-market’ and regulatory constraints often lead to a complex system landscape. The documentation for the functioning of a legacy system is often usually located in different internal locations, if not outside the organization. It is probable that the requisite  documentation could be misplaced and hard to find. Often, data dependencies are implemented as batch or online interfaces. They also have issues concerning the manner in which data is defined and is perhaps not optimally designed. End-of-day uploading of market data to determine portfolio values and resulting ‘mark-to-market’ reports is a case in point. These are usually processed as a batch apart from exposing the in-house system to external applications like Bloomberg or Reuters. This is an extremely crucial area that impacts P&L reports apart from the settlement of trades among professional counter parties. It carries a large amount of reputational risk, which is a prized virtue in this era of Financial Crisis and Solvency Criteria assessment.
Testers are often hard pressed to produce realistic test data that would address the above constraints. They must know what results the input data would produce, where all it would reside and in the process, what files would be modified. In short they should carry with them a mental map of the information flow within the legacy system. Testers with holistic domain knowledge will contribute significantly to  obviating this challenge with a process that ensures the integrity of systems and test data.

Data confidentiality and test data management:


Domain experts will positively impact this aspect where it is required to generate elements of test data that do not violate confidentiality requirements. The ideal scenario would be to run the testing environment with data procured from production systems. Banking secrecy laws and internal data protection policies inhibit the process. Having internal or external testers work with production data significantly increases the risk of violating “need to know” internal laws apart from the possible impact of reputational damage and loss of clients to poaching. Testers with a grasp of the idiosyncrasies of a domain would know what experimental samples are to be drawn from archived data (if available) and what needs to be masked, instead of running the whole universe. 
Another aspect pertains to the access-control for test and development environments. A domain expert would be expected to generate and use realistic test data that is in line with the confidentiality requirements. It should be infeasible for anyone to even remotely infer the identity of a client from such dummy or masked test data! 

Changing market and regulatory requirements:


Intense competition amongst banking companies to acquire and retain clients raises new functionalities for existing IT systems in an ongoing manner. SBI offering “no breakage charge” for deposits placed for a minimum of 15 days is a recent case in point. Early closure of deposits earlier attracted a penalty. Apart from this, there are frequent changes in regulatory laws i.e. cash ratios and changes in the import and export permitted for categories of clients and or products. As a consequence frequent product releases or changes/upgrades to existing systems often requiring multiple testing regimes, each year, are required. This phenomenon affects both banks with their own in-house IT systems and those that use standard solutions offered by third parties.
Frequent testing of the system results in cost over-runs for the client. This is where a domain expert can add value by estimating “correlations” of changes to existing data systems and assessing the impact. Those changes that in the domain expert’s opinion warrant further testing need alone be executed! Those “assessed” as inconsequential to the system may be “parked” for a future date or clubbed with a larger system upgrade. The domain expert thus brings to the table a cost-effective testing environment over the application life-cycle. Thus, the banking environment provides unique challenges to testers. A multi-disciplinary approach, which encompasses an industry view of testing, would serve to overcome some of these challenges with significant benefits to test-management apart from preserving data integrity and reliability. In summary, domain knowledge significantly enhances productivity, addresses technical and industry specific jargon and enables one to distinguish between critical and trivial issues thus contributing to an overall improvement in user interface for the client.


No comments:

Post a Comment