logo for information-management-architect.com
leftimage for information-management-architect.com

User Acceptance Test

Need to complete an information management change management user acceptance test and want practical suggestions to ensure rapid project delivery?

What is quality assurance testing?

The objectives of the quality assurance testing phase is to ensure that allUser Acceptance Test software components meet requirements and are ready to transition to production.

What is a test plan?

A plan is a communications tool, which clearly sets testing expectations for all team members. The plan should identify:
  • Test strategy;
  • Test plan;
  • Test data strategy;
  • Test deliverables;
  • Resource plan;
  • Training considerations; and
  • Test schedule.

What is a change management user acceptance test?


The objective of release testing is to certify that a release meets production support user acceptance expectations and is considered ready for production.

Release user acceptance test test checklist

Scope

Release testing should focus on testing a set of requirements (that is expected to move to production as a Production Release) to ensure that the release meets user expectations.
Release testing should certify that the solution meets production support  retirements.


Entrance Criteria

The following entrance criteria should be verified before release testing commences:

Release testing testing should commence upon approval of the user Acceptance Test Lead, Quality Assurance Test Lead and Data Architect/Project Manager who shall ensure that release test entrance criteria have been met. 
A configuration management process has been established and documented to handle requested changes to project documentation
The code migration process has been documented and arrangements made to accommodate testing.
A turnover package has been prepared and all code changes are identified in and made available to the Requirements Manager and test team. This includes database changes, changes to install scripts and instructions, structure changes, etc.
Code to be tested is locked-down and ready to be moved into the test area.
A release testing environment baseline has been updated with the release baseline. (i.e. the code and program versions in the release test test environment "mirror" the production environment).
Release team members have been involved in project meetings since the quality assurance and UAT testing phases.
At least one release test team member is on all applicable project communications lists.
The requirements specification has been base lined, is under configuration control, and has been made available to the release team for review.
All design documentation has been base lined, is under configuration control, and has been made available to the release team for review.
Development resources  have been identified and assigned to support the testing effort and are  listed in the Test Plan.
Independent code reviews & review/checkpoints have been completed and documented.
Unit testing results have been documented and reviewed by the testing team.
Unit test defects have been fixed, validated or otherwise properly finalized, and documented.
Integration testing results have been documented and reviewed by QA Test Team.
Integration test defects have been fixed, validated or otherwise properly finalized, and documented.
Quality assurance testing results have been documented and reviewed by the UAT Test Team.
Quality assurance test defects have been fixed, validated or otherwise properly finalized, and documented.
A development team representative from each subject area has been identified and assigned to support the release testing effort (and is listed in the Test Plan).
All required support files (such as account lists, flat file inputs, ini files, etc.) have been documented in the Release Object Migration Plan.
The release test defect management process has been documented and implemented.
The release team has been trained in and have appropriate access to the defect management tracking tool.
A Defect Manager has been identified, allocated, and trained.
Test Plan(s) have been completed and approved.
release test cases and scripts have been completed and approved.
A unique release  test environment has been reserved and under Configuration Management control.
The release test environment has been verified as accessible and functioning including connectivity to all applicable systems.
All applicable test tools have been installed, verified as functional, and user guide/documentation up-to-date.
Proper user ids and permissions required for testing have been obtained and verified.
Test data has been received and pre-tested for validity.
Deployment and installation instructions have been successfully executed and validated.
Contacts have been assigned for their various component responsibilities and are listed in the Test Plan.
All applicable service level agreements are in place and updated if needed, including clear ownership of Incident Resolution.
Any training required by the Release Test Team has been completed.
Any waivers or exceptions to the above have been documented and approved.
A release schedule has been established and documented. This schedule must include periodic planned builds for defect fixes while in test.

Test Cases

Release test scenarios are documented in the release plan.


Test Execution

Release testing should be performed in the release testing environment by release  team members assigned from production support.

Test Data

Release test data should be based on a sub-set of production data, produced by the production support team.
The release testers should not augment this data as it is should be assumed that UAT testing has certified that the release meets business requirements.

Defect Management

Release  testing  “defects” shall be identified, and recorded in the defect management tracking tool, e.g ClearQuest, by the Release manager.
Defects should be identified as:
  • Procedural, i.e. the documented procedures in the release plan do not produce the desired results or cannot be followed by the release team or
  • Technical Defects i.e. the object migration plan is incomplete or there are technical issues with migration code/scripts.
Defects should be assigned to the release manager who should:
  • Determine impact on project deliverables;
  • Approve/reject change; and
  • Create and manage Change Requests as appropriate to ensure that requirements are changed, reviewed, and approved before commencing technical analysis design, build, test and deploy.
Defects shall follow project methodology  e.g. analysis, design, build, review/checkpoint process before defects are certified ready for re-testing in the release test environment.
Defect resolution should be monitored by the Release Manager.

User acceptance test exit criteria

Release testing user acceptance test shall be considered complete upon sign-off and approval of the Production Support/Release Manager, Project Manager, UAT Test Lead and business owner who shall ensure that release test exit criteria have been met.
Any updates to test documentation have been completed and are under Configuration Management  control.
All defects have received a final disposition (i.e. open, closed, postponed, invalid, duplicate).
All closed defects have an assigned defect root cause. 
Sign-off has been obtained from designated stakeholders indicating test completion.
Other test completion and validation conditions, as specified in the Test Plan, have been met.

Summary...

The objective of user acceptance test release testing is to certify that a release meets production support user acceptance expectations and is considered ready for production.

The release plan should identify user acceptance test roles and responsibilities, tasks, deliverables and entrance/exit criteria.



footer for Information management page