Release Test
Need to complete an information management release 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 all
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 release test?
The objective of a production support user acceptance test is to certify that an information management solution
meets production support user acceptance expectations and is considered
ready for production.
Test checklist
Scope
 Acceptance testing should focus on
testing a set of requirements (that is expected
to move to production as a Production Release) to ensure that it meets user expectations.
This should certify that
the
solution meets production support requirements.
Entrance Criteria
The following entrance criteria should be verified before acceptance testing commences:
Acceptance testing should
commence upon approval of the user Acceptance Test Lead, Quality
Assurance Test Lead and Data
Architect/Project Manager who shall ensure that 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 testing environment
baseline has been updated with the release baseline. (i.e. the
code and program versions in the acceptance 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 acceptance 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 acceptance 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.
Acceptance test cases and scripts have
been
completed and approved.
A unique acceptance test
environment has been
reserved and under Configuration Management control.
The 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 acceptance 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
Acceptance test scenarios are documented
in the release plan.
Test Execution
Acceptance testing should be performed in
the testing environment by team members assigned
from
production support.
Test Data
Test data should be based on a
sub-set of production data, produced by the production support team.
The test team should not augment
this data as it is should be assumed
that UAT testing has certified that the release meets business
requirements.
Defect Management
Acceptance 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
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.
|
