Up One Level


User Acceptance Testing - UAT

 

The test procedures that lead to formal 'acceptance' of new or changed systems. User Acceptance Testing is a critical phase of any 'systems' project and requires significant participation by the 'End Users'. To be of real use, an Acceptance Test Plan should be developed in order to plan precisely, and in detail, the means by which 'Acceptance' will be achieved. The final part of the UAT can also include a parallel run to prove the system against the current system.

The User Acceptance Test Plan will vary from system to system but, in general, the testing should be planned in order to provide a realistic and adequate exposure of the system to all reasonably expected events. The testing can be based upon the User Requirements Specification to which the system should conform.

As in any system though, problems will arise and it is important to have determined what will be the expected and required responses from the various parties concerned; including Users; Project Team; Vendors and possibly Consultants / Contractors.

In order to agree what such responses should be, the End Users and the Project Team need to develop and agree a range of 'Severity Levels'. These levels will range from (say) 1 to 6 and will represent the relative severity, in terms of business / commercial impact, of a problem with the system, found during testing. Here is an example which has been used successfully; '1' is the most severe; and '6' has the least impact :-

  1. 'Show Stopper' i.e. it is impossible to continue with the testing because of the severity of this error / bug
  2. Critical Problem; testing can continue but we cannot go into production (live) with this problem
  3. Major Problem; testing can continue but live this feature will cause severe disruption to business processes in live operation
  4. Medium Problem; testing can continue and the system is likely to go live with only minimal departure from agreed business processes
  5. Minor Problem ; both testing and live operations may progress. This problem should be corrected, but little or no changes to business processes are envisaged
  6. 'Cosmetic' Problem e.g. colours; fonts; pitch size However, if such features are key to the business requirements they will warrant a higher severity level.

The users of the system, in consultation with the executive sponsor of the project, must then agree upon the responsibilities and required actions for each category of problem. For example, you may demand that any problems in severity level 1, receive priority response and that all testing will cease until such level 1 problems are resolved.

Caution. Even where the severity levels and the responses to each have been agreed by all parties; the allocation of a problem into its appropriate severity level can be subjective and open to question. To avoid the risk of lengthy and protracted exchanges over the categorisation of problems; we strongly advised that a range of examples are agreed in advance to ensure that there are no fundamental areas of disagreement; or, or if there are, these will be known in advance and your organisation is forewarned.

Finally, it is crucial to agree the Criteria for Acceptance. Because no system is entirely fault free, it must be agreed between End User and vendor, the maximum number of acceptable 'outstandings' in any particular category. Again, prior consideration of this is advisable.

N.B. In some cases, users may agree to accept ('sign off') the system subject to a range of conditions. These conditions need to be analysed as they may, perhaps unintentionally, seek additional functionality which could be classified as scope creep. In any event, any and all fixes from the software developers, must be subjected to rigorous System Testing and, where appropriate Regression Testing.


*** The Information Security Glossary ***
Previous PageTop of this pageNext Page



Buy Now:

 

This Glossary forms part of the RUsecure Security Policy Suite... visit RUsecure Security Policy World
Use of the guidance contained within RUsecure™ is subject to the End User Licence Agreement
This site created with EasyHTMLHelp(tm) for MS Word
 Risk Associates: Resources for Security Risk Analysis, ISO 17799 / BS7799, Security Policies and Security Audit