QUALITY ASSURANCE STANDARDS

INTRODUCTION

Testing is the last stage in the development cycle before the upgrade is sent out to the client. This stage is critical and is a means of identifying whether firstly the development matches the clients requirements and secondly if the upgrade functions according to the DBS.

This document is meant to act as a guide outlining the minimum testing requirement for the core processes within LIFEfit.

WORK ASSIGNMENT

TASKfit is the system used to log all errors and any new development highlighted by the client.  The project managers are responsible for creating a new Work Tracking Item (WTI) for every piece of work requested by the client, whether it is an error or a change.  Unless a work-tracking item (WTI) is assigned to a QA person no testing should be started.  (Please see process flows for more details.)

ESTIMATES AND DEADLINES

• Managers are responsible for adding estimates and setting a delivery deadline.  The estimates are broken down into: 

• Analysis
• Programming and unit testing
• Quality Assurance testing

• Check the estimates before the work is started. If the estimates seem unreasonable then highlight this to the project manager with valid reasons.  It is the responsibility of the project manager to then adjust the estimates and deadlines.
• If the estimates are reasonable then keep track of the time spent on the Work Tracking Item (WTI) and the delivery date.  If at any stage during the testing it is established that the estimate is not going to be met then again inform the project manager with valid reasons.  The project manager will then be able to speak to the client and agree adjustments to the estimate and to the deadline.
• It is the responsibility of individual QA (Quality Assurance) person to ensure that they report as early as possible to the project managers if they expect the project to be delayed. It is unacceptable to highlight this on or after the delivery date.

UPGRADES

• Never apply an upgrade to the QA (Quality Assurance) system if it has not been through a code review.
• Before applying the upgrade, print off the instructions.  Check that instructions explain the purpose of the upgrade and include any plan settings.
• The Upgrade should be applied to the QA (Quality Assurance) system and instructions followed to set-up any plan settings.  No assistance should be requested from the programmer.  QA (Quality Assurance) should be testing the instructions. If the instructions are not clear then fail the upgrade and the programmer should update the instructions. Include this as one of the tests on the test plan

PROCESS FLOW

• For every piece of development being tested ensure that the same process flow as the client is used.  This means the policy set-up is the same (e.g. import or new business) and the premium is collected in the same way (on-line or direct debit).  The policy is issued in the same way (on-line or batch).
• If the same process flow is not followed then the results gained from the testing at FIT could be different from the client.
• NEVER run batches from TCL during your testing.
• Always run the mandatory batch processes and any extracts generated by the client.
• If reports are being tested then ensure the same document server settings as the client are used.  Ensure the same print fonts are being used.

MANDATORY BATCH PROCESSES

There are certain processes in the batch that must be selected every time the batch is run.  These mandatory batch processes must be run in the order shown.

TESTING THE ACCOUNT POSTINGS

• Check the DBS for the account postings of the current piece of work being tested.  Use the Pseudo in the DBS to locate the account number on the system.
• Access the general ledger screen, which holds the monthly accounts for each general account.  Take a screen print of each account being tested before the batch is run.
• Run the Batch process.
• Look at the general ledger postings report.  For each account, add the amounts in the report to the amounts on the screen prints taken before the batch was run.  Match these figures against the figures on the general ledger screen.  The calculated figures must match the new figures on the screen.
• The figures should match exactly.  If there is a discrepancy (even a penny) then there is a problem.
• Check the Trial balance.  Everything should sum up to zero.  If the trial balance is not showing a summed total of zero, then the accounts do not balance.

TEST DATA

a. NEW BUSINESS

• There have been rounding problems on some systems.  To ensure that in the future any rounding problems are picked up in the testing, the data created at new business should assist in locating rounding problems.  It is recommended that .39 be added to the premium amounts entered at new business e.g. 4000 becomes 4000.39.

b. UNIT PRICES

• Use realistic unit prices unless unit price is critical to the test i.e. to give a certain value for .paid-up.
• Avoid using the same amounts for bid and offer price for a particular unit price date.
• Always ensure the prices are different for each day.
• Do not enter prices in over the weekend unless it is proven that the client does the same.
• Add prices on the relevant days dependant on the system-pricing basis e.g. if the fund is priced weekly then only enter the prices in on the dealing day.

c. REALISTIC DATA

• Always try to use realistic test data e.g. premiums on life cover are less likely to be whole numbers.
• If the testing can be done on the client’s real data then have that copied into the QA system.

TEST PLANS

OVERVIEW

The DBS should be used to assist in writing the testing plans.  The test plan should outline what type of policy is being used for the tests.  It represents a step-by-step guide of each process applied to the policy.  Anyone should be able to pick up a test plan, follow the instructions and duplicate the test results.

The plan should show the expected results and if an upgrade fails then the test plan should be passed to the developer who will find it easier to duplicate and fix the problem.

Try to test other areas of the system that could be affected by the upgrade being tested.  If there are other areas that need to be tested then add these to the test plan.

SCREEN CHANGES

For screen changes the following items should be considered when writing test plans:

• If applicable, check that F2 help works (F3 on Universe).
• Check the validation on the field e.g.. If numeric then an alphabetic character should not be accepted.
• If applicable, if data is being checked against another file e.g. if a scheme rate is being entered,  then it must exist on the SCHEME_RATES file.
• ALWAYS check F1 and F2 Help exists on the field.
• Check that the field has a meaningful name
• Check the validation of each field against the minimum and maximum values applicable for that field.

<top>

PREMIUM COLLECTION

When checking the premium payment the following should be considered when writing test plans.

a.  Policy Accounting

• Policy accounting transactions should be created for the correct amount.
• Any relevant fees should have been deducted and should be accounted for in the policy accounting screen.
• If the policy has riders and the premiums are collected separately then check that the premium on the rider is paid.
• Check the pseudos and accounts shown in the policy accounting screen are posted to the general ledger correctly.

b.  Future Records

• Check that the UPP future record has been created for unit allocation on the correct date.

c.  Paid To Date

• For regular premium policies check that the paid to date on the policy has moved on one modal frequency.

d.  Policy Accounting Screen

• Check the HOLD CASH matches the amount available for allocation using the formulae defined on the plan.

e.  Commission

• Check on the agent enquiry screen that the correct commission is calculated. 
• Check that the earned, unearned and paid commissions on the agent screen are correct.
• Check that the commission enquiry screen for individual commission transactions shows the correct commission to be paid to the agent.
• Check that the commission appears on the commission statement.

f.  Additional checks for Direct Debits

• Check the extract file generated for the bank matches the layout defined in the DBS.
• Check the next direct debit future record is generated correctly using the payment frequency defined on the policy.

g.  Batch

• Run the batch and make sure the policy accounting transactions are posted to the correct accounts and run the trial balance to ensure everything still balances.

<top>

UNIT ALLOCATION / DE-ALLOCATION

a.  Policy Value

• Always take a screen print of policy value before any allocation/de-allocation is done.
• Check the policy value after the allocation/de-allocation. Ensure the change in units on the policy match the unit moves transactions.

b.  Unit Accounting

• Check the plan settings to determine the allocation/de-allocation amount.
• Check the unit accounting to ensure the correct monetary amount is used to buy or sell the units. 
• If the bid / offer spread parameter is set, then check this is shown in the unit accounting.
• Check fluctuation accounting, if applicable.

c.  Unit Movements

• Check the unit moves to ensure the correct units appear have been created/deducted and that the total unit value of the transactions matches the unit accounting transactions.
• The unit movement is across the funds in accordance with fund split.
• Ensure the correct unit prices are used to buy or sell units. Take into account whether the system is forward, dealing day or daily pricing.
• Check the correct price is used (Bid or Offer).

d.  Batch

• Run the batch and make sure the unit accounting transactions are posted to the correct accounts and run the trial balance to ensure everything still balances.

<top>

POLICY ISSUES

a.  Policy Accounting

• Check the premium is paid on the policy.
• Check that policy accounting shows any fees defined on the plan.

b.  Policy Status

• Check the policy status is active.  The correct description is shown in policy enquiry.
• If the policy has a rider then check the status history (F6) option from policy enquiry screen and ensure that the rider is active too.

c.  Future records

• Check the plan settings and ensure all relevant future records are created.
• For each future record check the future date and make sure the future records are created on the correct date.  The plan settings for the product determine the future date.

d.  Commission

• Using the agent enquiry screen check the correct commission is calculated. 

• Check the earned, unearned and paid commissions on the agent screen are correct.
• Use commission enquiry option (F6) to check that the correct commission is shown for each selling agent.
• Check that the commission appears on the commission statement.

e.  Batch

• Run the batch and make sure the policy accounting transactions are posted to the correct accounts and run the trial balance to ensure everything still balances.

<top>

CANCELLATIONS/SURRENDERS

a.  Check section Unit allocation and deallocation

b.  Policy Accounting

• Check that the policy accounting will shows the amounts due to the client.
• Check that the amount on this screen matches the values of units shown on the units accounting screen.
• For claims ensure the amount being paid to the client matches the benefits defined on the plan e.g. greater of bid value of units or face amount.
• Check that any surrender/cancellation fees according to the plan parameters have been applied.
• Ensure the rider benefits have been included in the total payout to the client.

c.  Batch

• Run the batch and make sure the policy accounting transactions and the unit accounting transactions are posted to the correct accounts and run the trial balance to ensure everything still balances.

d.  Policy Status

• Check that the policy status is changed to reflect the cancellation/surrender etc of the policy.

• If the policy has any rider then check the status history (F6) option from policy enquiry screen and ensure that the rider has the same status.

e.  Payment Method 

• Ensure the payment is being made to the right person.
• Ensure if the payment is by e.g. direct credit then the future record is generated.
• Ensure if the payment is by cheque, then this payment appears on the cheques to be written report.

f.  Commission

• If there is commission claw back then ensure that the correct commission is reversed. 
• Check that the accounting for the commission reversal is correct
• Check that the commission reversal appears on the commission statement.

DEATH CLAIMS

a.  Death Notified

• Check status has changed to Death Notified.
• Check policy accounting transaction has been created with estimated death benefit postings.
• Check nothing else has changed i.e. units not cancelled, future records still present etc.

b.  Death Settlement

c.  Check section ‘allocation and de-allocation’

d.  Policy Accounting

• Check that the policy accounting will show the amounts due to the client.
• Ensure amount being paid to the client matches the benefits defined on the plan e.g. greater of bid value of units or face amount.
• Ensure the rider benefits have been included in the total payout to the client.
• Check the CTBW report to ensure the payment is to the correct beneficiary.
• Check status on the policy has been changed to death settlement.
• Check there are no units left on the policy.

APPENDIX:

X