Testing SAP Bank Analyzer 8.0

SAP TAO - Expert intelligent testing services: Testing SAP Bank Analyzer: Testing SAP Bank Analyzer – This article will explain best approach and test strategy to test SAP Bank Analyzer
 

With SAP Bank Analyzer, a Familiar statement is that SAP Bank Analyzer supports overall bank controlling by calculating, evaluating, and analyzing financial products and structure of Bank Analyzer is per IFRA and it provide facility to meet the current requirements ((IAS), Basel II, and Risk Adjusted Performance Measurement) for the value range of financial products. So let's evaluate the above statement first, In last couple of decades SAP offering Business Management Software Applications to meet industry problems, so in simple words SAP bank analyzer packaged applications that has been engineered for Banking Analytics (data management and arithmetic calculation) to streamline business process management / business requirement to meet Accounting for Financial Instruments, risk assessment, performance evaluating of the financial products in an Integrated Finance and Risk Architecture (IFRA) that is required not only for the bank's internal controlling over the Credit Portfolio Management but also reporting to external stakeholder from compliance perspective.

Above is a typical statement to define what is SAP Bank Analyzer, lets outline business and technical information of SAP Banal Analyzer and how does it work & where does it fit in a bank/ institution's  along side the testing and data strategy.

SAP Bank Analyzer is not single application to meet above stated business requirement but a product family that contains multiple components as:

• Data Load Layer (FS-BA-DL)  
• Source Data Layer (FS-BA-SD) - SDL
•  Processes and Methods (FS-BA-PM) - PML
•   Results Data Layer (FS-BA-RD) - RDL
•    Analytics (FS-BA-AN)
•   Infrastructure (FS-BA-IF)
•   Tools (FS-BA-TO)

 

Testing of Data Load Layer (FS-BA-DL) & Source Data Layer (FS-BA-SD)

One of the typical needs for risk assessment within Risk department is the need of data (either current real or a time series historical data) for risk modelling or reporting – First component of the SAP bank analyzer is the Data Load layer, information about the SAP Data Load Layer is available on the SAP Website " Documentation website" so here we will not repeat what is not relevant for our testing discussion.

Please note in any "Risk modelling solution" or a product implementation 50% time is being spent on sourcing data into tools therefore need of testing for DL/SDL layer is foremost important form system, business perspective.

Data Load Layer constitutes functions for importing source data and results data from SAP NetWeaver BI (tool BI) to the interfaces in the Source Data Layer (SDL) or some time Results Data Layer (RDL) in the SAP Bank Analyzer. This is fairly simple to test and can be proved using a general extraction, transformation and loading process test that can prove transfer of source system data to Bank Analyzer.

As data is being core backbone for the basis for the evaluation in the next layer of the Bank Analyzer - Processes and Methods (FS-BA-PM) – testing operations system data with certain checkpoints within the SDL reduce any GAP of data or inconsistency in upstream layers, Parameterize data-driven Tests can also offer variance of tests so recommended to use a data scenarios spreadsheet or database to overcome any cumbersome changing requirements for example, when its is simple sandbox tests "LSMW" routine can be run with minimum data (e.g. master data (legal entity, account and transaction or data being verified between source application to Data load/SDL layer. 

Some time SDL component needs to be quickly supplied a large amount of input especially when functional test are stable and Tool BI or any ETL need for the purpose of system performance tests.  It is also recommended that Re-Usable data sets developed, reviewed and validated keeping High level business scenarios coverage in mind within tests of the SDL layers tests.

Data load layer testing (BI) is core to test to ensure the system selects the required data, and fills the extraction structure correctly. Only by doing these tests can you ensure that the BI data extraction works as expected using your settings, and that the system will later extract the data in the required form.

Further testing strategy depends upon the nature of the solution implementation e.g. a vanilla implementation, upgrade or prototype tests, if there are limitation of the source data or a prototype or data weaver in place to use /real time/ live data, this case, a data generator tool can help to develop required test data with all logical entities in place. You can create test data sets instead going to tedious work to develop data manually. As required for success of data-driven testing approach, all input data and expected results tests are kept in one place, reviewed with SME, updated when required.

Source system data, feeder system mapping, (ETL) and data set types and basic configuration can be agreed with data migration and functional team before or during the early phase of test cycle. It is also advisable that test coverage of the SDL layer testing should be moderate as downstream layers i.e. PML - Processes and Methods (FS-BA-PM),  RDL- Results Data Layer (FS-BA-RD), ,AN -Analytics (FS-BA-AN) and  tool and Infrastructure require more a Object based  tests, so may be we can looking to apply Object-Driven Tests
 

Data-driven testing test strategy is best approach to run together with related data migration sets/scenarios in a framework. An iterative and incremental approach is more useful during the SanBox – Config test runs, it must be applied using data scenario to check integrity of objects and processes. Other data drive test strategy depends upon the implementation consideration such as if requirement is for BASEL traceability of the in-house model input and output with time series of future validation based on model etc       

Best Testing practice -

• Data Load Layer does not contain data validation. The system data is being imported that has been transformed and mapped directly to the inbound interface of the SAP Bank Analyzer system (primary DSO). Relying on the data load loading results can not be prove enough system data quality checks therefore need for testing increases here, SDL need consistency checks of the data, integrity checks verification and in some case where stress test involves some data enrichment test as well  specifically in DLL using ABAP routine.
• Each load process supplies the last version of an object hence minimum tests should be run when processes are run. It is also not possible to process more than one version for each business day therefore keeping data set ready to utilize in short time span helps to ensure system quality. If an error occur during the data loading (Dala load). Remember to check business date or event date key when identifying new objects to be loaded. – This check must be pre-request of the identified tests.
• The SAP BA system does not load business partner data- master data. The only way that the system can load business partner data into the Bank Analyzer system is by using a BAPI. – Therefore need of tests increases when any BAPI is introduced to updated etc.

In short statement, the separation of the components ensures data is stored help in testing integrated and consistent way, Source systems / operational systems data is first mapped and migrated into the Source Data Layer (SDL). The FS Data Load Function is being used in the definition of a BI process chain (Check with BI -ETL team that it is in place so success of the tests is recorded) the process is scheduled and monitored within BI hence test representative should have appropriate access. Process control is part of the Data Load Layer that contains process chain also in event of change – CNS Change Notification Service (CNS) within the BI tested for any object change e.g. any primary object change – Change log for the primary objects change also provide assurance.

Any need for the BP (Business Partner) tests along with the operational system Data load or change within the SAP BA interface tests however this depends upon questions before finalizing test data strategy

Eg

·         Do we need Parallel runs and what is the data loading architecture?

·         What is the source data that they would require to be used in BA?

·          Would it be the financial instrument level of data or extension?
What data that lands in these BA or its tools require reconciliation to financial figures?

As we understand, each tool requires setup time. Will there be any blueprint on the implementation/mapping for SAP BA data for product and how the team structure is setup etc. Going forward, is there any requirement for building a in-house Data warehouse?

What and when the reports are coming out for the products – Daily, Monthly – IFRS, management or accounting statement reports etc?

Each of the data or each module required different data set and their timely testing

Following data attributes should be considered whilst developing test data strategy –

Master Data

• Reference Data items that are required to support the transactional data.

 Transactional Data

• Trading and non-trading financial data.

 Configuration Data

• This is data that is set up on SAP during the build and configuration process.  This type of data is not part of the migration process, as it will be transported to the production system through the SAP transport procedure

 Financial Instruments

- From defined business line

 Financial Transactions

• “Live” trades or an ongoing business transaction in scope.

  Counterparty data

• Counterparty data details - legal entity, region, and name etc.

  Valuation data 

• “Live” trades, yield curves, fair value, exchange rates etc.

  Business Transactions

• Current outstanding trades yet to settle or any other Business Transactions entries required to build up model

 From Performance testing perspective - Multiple Sources Data Synchronization, Volume of data and need for parallel runs and what is the data loading system architecture, hardware should be looked along side functional and integration tests?

Other Functions test consideration for the SDL, following functions for the primary objects to be tested -

● Validations -

● Authorizations

● Archiving

Removed as contents are client specific scenarios….

 

Fig – 1 Quick  dirty diagram to depicts ETL process to load Operation data into SAP BA – DL / SDL layer

Testing of the Processes and Methods (FS-BA-PM)

Before moving to Testing of the Processes and Methods, remember, SAP-AFI comprises a variety of processes that altogether form a complete subledger for Financial Products. The overall architectural idea of SAP-AFI is to have a thick subledger, i.e. one that contains all information required for financial reporting, and a thin general ledger, i.e. one that that holds just enough information to fulfill the daily reporting requirements with reasonable performance.

 

During defining testing of the PML, Keep in mind that the SAP BA infrastructure testing is incomplete for any business blueprint/ business processes until functional level summaries functions are not clearly listed and executed in the test strategy or detail plan –

Testing of the Processes and Methods (FS-BA-PM)

< >

Below list is the possible SAP BA E2E scenarios, each of the scenario will be decompose to describe Testing of the Processes and Methods (FS-BA-PM) in a typical FI implementation, Please join this blog and also send email if you are looking for complete End to end test scripts that has defined input and expected results, documentation of test results and resolution.

- Please note outlined SAP BA test strategy features have not been discussed for typical test management activities e.g. Resources, domain expertise, hands-on experience or accounting knowledge etc …

It is essential that consultant should understand basic of FI, Accounting (IAS - IFRS) & also technical structure of the SAP BA especially it a new implementation either be in FI or for credit risk implementation.

Moreover Financial Basis should be known to test resource to implement an effective testing strategy…

List tests are essentially function tests; there are two characteristics of the tests –

1)Component Integration test phase

2) E2E business processes tests.

In contrast to the other test scenarios, all the steps for AFI are collected in a typical sequence shown below.

Finance Accounts Testing scenario and their Results

Category 1 - business transactions

· Post external business transactions

· Update secondary business Transactions

Category 2 - date valuation

· Key date valuation for all financial positions

· Financial Positions for Period (PICC) event processing etc

· Update costing for period before GL and during transferring GL documents

· Calculation for all PICC

Category 3 – SAP GL Postings

· GL Connector and document generation – Journal and document review and finance reconciliation of the GL, Profit centre and any material code posting review

· Balance processing step 1 - (SV)

· Balance processing step 2 - (ATP)

Testing of the accounting for FI with Aggregation (AFI) for Accounts Results before RDL and GL

The Accounting Management comprises a number of accounting procedures that in turn cater for the correct derivation of postings for a certain business event.

Category 1 – position management

· Generate Finance Instruments position

· Aggregate Financial Transactions

· Prepare Business Transactions for Aggregation

· Process Reassignments for Business Transactions

· Aggregate Business Transactions

· Aggregate Current Accrual Results

· Process Reassignments for Accrual results

· Aggregate Retroactive

· Accrual Results

· Derive Application Events for source data aggregation

Imported Sub-Ledger Documents (ISD) for Results

ISD sub-ledger import

Other – FS-BA-PM – Tests