11.
APPENDICES
11. APPENDICES
11.1. Purpose of Error Review
Team.
Ensure maximum efficiency of the development and system testing
teams for the release of the new office software through close co-operation of
all involved parties.
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.
11.2. Error Review Team Meeting
Agenda.
- Review any actions from last meeting.
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.
- Agree release content and timescale.
- Review of assigned actions from meeting.
11.3. Classification of
Bugs
1. An "A" bug is a either a showstopper or of such
importance as to radically affect the functionality of the system i.e. :
- 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
11.4. Procedure for maintenance of Error
Management system.
| 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. |
11.5. Overnight Processing - Checking
Accounting & Audit & CIS
| 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
V
Applic input forms |
1. Checking at
field level
2. Checking at
field level |
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
V
Test input forms |
1. Satisfy as to
reasons for
rejection
2. Checking at
field level |
| 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 |
11.7. SOFTWARE QUALITY ASSURANCE
MEASURES
(i) DATES.
- Start date of SQA
involvement.
(ii) EFFORT.
- No. of SQA Man
Days Test Planning
- No. of SQA Man Days Reviewing Test Plans
- No. of
SQA Man Days Executing Tests
(iii) VOLUME.
- No. of Tests
Identified
(iv) QUALITY.
- No. of Tests
Passed First Time
- Percentage of Tests Passed First Time
- No. of
Error's Raised During Regression Testing
- No. of Error's Generated as a
Result of Incorrect Fixes
- 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
(v) TURNAROUND.
- Average
Error Turnaround Time
