This will be achieved through daily meetings whose function will be to
- Agree status of each raised Error
- Prioritisation of valid Error's
- Ensure that enough documentation is available with Error's.
- Agree content and timescale for software releases into System test.
- Ensure one agreed source of Error reporting information.
- Identify any issues which may affect the performance of system testing.
Classify and prioritise each Error.
- Review Error's raised for Duplicates etc.
- Agree priority of each Error
- Determine adequacy of documentation associated with raised Error's.
- Examples of showstoppers
- If, because of a consistent crash during processing of a particular type
of application, a user could not complete that type of
application.
- Incorrect data is passed to legacy system resulting in corruption or
system crashes
- Example of severally affected functionality
- Calculation of repayment term/amount are incorrect
- Incorrect credit agreements produced
2. Bugs would be classified as "B" where :
- a less important element of functionality
is affected
- Example : a value is not defaulting correctly and it is necessary to
input the correct value
- data is affected which does not have a major
impact
- Example : where, for instance, some element of client capture was not
propagated to the database
- there is an alternative method of completing
a particular process
- Example : a problem might occur reading all the details of a credit -
this change can be manually input.
3. "C" type bugs are mainly cosmetic bugs i.e. :
- incorrect / no helptext on screens
- drop down lists repeat an option
| 1. | The Test Controller will refer any major error/anomaly
to either Devopment Team Leader or designated representative on the development
team before raising a formal error record. This has several advantages
:-
- it prevents the testers trying to proceed beyond 'showstoppers' - it puts the developer on immediate notice of the problem - it allows the developer to put on any traces that might be necessary to track down the error. |
| 2. | All bugs raised will be on the correct Error form, and contain all relevant data. |
| 3. | These errors will be logged on the day they occur with a status of 'RAISED' |
| 4. | There will be a daily 'System Test Support Group' meeting
to discuss, prioritise and agree all logged errors.
During this meeting some errors may be dropped, identified as duplicates, passed to programmer, etc. |
| 5. | The Error Log will be updated with the status of all errors after this meeting. e.g. with pgmr, dropped, duplicate. |
| 6. | Once errors have been fixed and 'rebundelled' for a release the paper forms must be passed to the Test Controller and he will change their status to 'Fixed to be retested' |
| 7. | Once the error has been retested and proven to be corrected the status will be changed to 'Closed' |
| 8. | Regular status reports will be produced from the Error system, for use in the Error Review Team meetings. |
| Test Requirement | Check Items | Level of Testing |
| Accounting | ||
| When spooling complete the Summary report should be checked
against :
1. Similar Legacy Transactions 2. Test Input forms |
1. Legacy Txs on Report
V Office Transactions on Report 2. Summary report
|
1. Checking at
field level 2. Checking at
|
| Accounting : after open/amend the amendment report
should be checked:
1. For rejected open/amend instructions 2. Detail should correspond to input Applic Forms |
1. Amendment report
2. Amendment report
|
1. Satisfy as to
reasons for rejection 2. Checking at
|
| Print off Account and Customer records and check field detail against applic input forms/branch summary report | Bookkeeping - Input tx's
V Test Input forms/Amend rpt |
Checking at
field level |
- No. of Error's Raised by Category (A/B/C)
- No. of Error's Raised by Reason Code
- No. of Error's Raised by High Level Business Function