Академический Документы
Профессиональный Документы
Культура Документы
Author:
Authorized By:
Status:
Owner:
Version:
Last Updated:
<<Work Request>>
Test Strategy
1. Amendment History
2. Distribution
Recipient Role/Team
3. Table of Contents
1. Amendment History......................................................................................................................2
2. Distribution....................................................................................................................................2
3. Supporting Documentation & Reference....................................................................................2
4. Test Strategy Document Sign-Off................................................................................................2
3. Table of Contents....................................................................................................................3
5. Glossary of Terms.........................................................................................................................5
6. Introduction....................................................................................................................................5
5. Glossary of Terms
Acronym/Abbrevia Description/Definition
tion
6. Introduction
7. Test Approach
TEST FRAMWORK
Testing of project <<work request>> will following the <<company name>> testing framework
outlined below. The detailed test approach for this project will be identified and documented in the
Details test plan.
TEST MODELS
Test Types
Below are the types of testing cycles required to verify the performance of the product
Unit Testing
Unit testing is a test that validates that individual units of code are working as planned. The goal
of unit testing is to isolate each part of the program and show that the individual parts are
correct. This test will be conducted by the developer on their individual machines and will test
individual components of given IT deliverables. Upon completion of the unit test the
Development manager will provide the IT test team with the unit test results.
Approach – This testing will be completed during development on development PC’s
Accountable - Development Manager
Responsible – Developers
Deliverables – Execution
• Smoke Testing
The entrance and exit criteria specified by the Test Lead should be fulfilled prior to commencing the
particular testing phase. In the event, that any criterion has not been achieved, the testing may
commence if the steering committee and test lead are in full agreement that the risk is manageable.
In the event that the testing is suspended, a resumption criterion will be specified and testing will not
re-commence until the software reaches this criteria.
The exit, entry and resumption criteria for each phase of testing will be outlined in the detailed test
plans.
• To identify defects and issues in the functionality and impacted systems that will adversely
affect the <<work request>> project
• To assist in the repair and mitigation of issues and defects by reporting them in a timely and
accurate and retesting when fixed
• To verify and validate that deliverables behave according to stated objectives
• To verify the quality of the release against the functional and business requirements
• Ensure impacted system components and business processes are regressed and work end-to-
end
• Report to Management and Stakeholders the status of testing during the execution phase
• Guide and assist stakeholders in performing the Business Acceptance Testing so they are able to
accept the release with an appropriate degree of confidence
• Ensure a managed and coordinated testing effort across the <<work request>>
• Verify the changes are accurately reported on
This table provides a visual of the applications, systems and services that will be used to test and will
be tested by the <<work request>>.
The following tables outline the high level effort estimates from IT and business that will be required for
each test deliverable including the execution of these phases. The estimates given are in days and will
be spread across working days Monday to Friday.
The main purpose for the business effort during test planning and preparation is to review and feed into
the test documentation deliverables. During execution they will be required to prepare and perform
Business Acceptance Testing.
Please note that the following estimates are high level and are based on the Business Requirements
Document. Upon completion of the FSD the testing effort will be re-estimated and distributed.
Note:
Test Strategy
Effort required in
To be commenced To be completed
days
Test Strategy
<<work request>> Test Strategy – not ready for release
Page 10 of 21
<<Work Request>>
Test Strategy
Smoke Testing
Effort required in
To be commenced To be completed
days
Smoke Test Criteria to move to Functional Testing
Test Scripts
10. Resources
Human
The following table outlines the Human resources that will be required for test preparation and
execution of the <<work request>> solution. The resources identified in this test strategy are at a high
level but will provide and initial view of what will be required.
Note: The date required is estimated and will most likely change, these date will be confirmed with in
the detailed test plan.
Test Preparation
Hardware Required
Software Required
ConnectionADSL
Connection
Resolution 1024
LAN Connection
Windows Office
Dialup
Macintosh
Screen
x 768
Vista
Browsers
56.6K
The following table outlines the regions that will be utilised throughout testing of <<work request>>
Test Phase
<<work request>>
Unit Test Execution
Code Integration Test Execution
Functional (E2E) System Test Execution inc. regression
Non Functional System Testing Execution
Business Acceptance Testing Execution
Incidents will be classified according to a severity of 1-4 where 1 will be given the highest priority to
resolve and 4 will be given the lowest priority. Each phase of testing will be assigned an acceptable
number of incidents classified by Severity as Entry and Exit Criteria.
Generally an incident will be assigned a Severity according to guidelines set out in this document;
however, the working group will review the incidents on a regular basis to determine if a change in the
severity is needed.
All defects will be channeled through the Test Analyst and/or Test Lead as defect coordinator for
Functional, Non Functional and Business Acceptance Testing phases
Severity Definition
The following table provides a guideline for classification of incidents found during the course of testing.
SEVERITY 3 fixing the problem. It is expected that the problem will be rectified within 5
days.
discrepancy
A minor problem exists in the application, no effect on the business.
Minor
SEVERITY 4 Response should be given within 24 hours including an estimate of time for
fixing the problem.
Defect Triage
A brief paragraph around how you intend to manage the flow of defects
Any issues and risks identified during test planning and execution will be reported to the IT project
manager
Dependencies
Assumptions
•
16. Communications
Role Responsibility
Test Manager • Escalation point for Test Lead
• Provide Sign off of test strategy and plan
Test Lead • Accountable for follow-up on testing progress and status as well as
reporting on exit and entry criteria for Non Functional, Functional
and Business Acceptance testing
• Provide formal sign-off of Non Functional, Functional and Business
Acceptance Testing
• Creation of Test Plan for Non Functional, Functional and Business
Acceptance Testing
• Provide project with appropriate test resources
• Support responsible Business Analyst during BAT
• Raise testing issues which may affect delivery dates, quality, and
functionality deviations to ITPM and Test Manager.
• Report test execution progress during execution of Non functional,
Functional and Business Acceptance testing
• Escalation point for Test Analyst.
• Oversee the test planning and execution and ensure test procedures
are followed
• Assist with resolution of issues and risks during the testing lifecycle
• Test Lead is testing stakeholder and working group member
Test Analyst • Creation of Test Scenario Matrix and Scripts for Functional System
Testing
• Organise and complete a review of test scenarios and priorities with
business and project team
• Perform functional test execution
• Produce test data to be used for Functional System Testing
• Produce test results/evidence as specified in test scripts.
• Store test results/evidence for audit purposes.
• Contribute to the test status report
• Log and retest defects.
<<work request>> Test Strategy – not ready for release
Page 18 of 21
<<Work Request>>
Test Strategy
• Communicate issues and risks to the Test Lead.
• Support BAT environment and lab during BAT phase.
T Project • Log any testing issues into the Project Issues/Risks register log.
Manager • Review Test Deliverables.
• Provide regular status reports on progress of testing to key IT and
business stakeholders.
• Sign Off all IT Deliverables.
• Sign off Production Readiness of all IT Deliverables.
• Sign off Production Implementation for all IT deliverables.
Developer • Ensure Unit Testing is undertaken and the results formally
Manager documented.
• Ensure Code Integration Testing is undertaken and the results
formally documented.
• Raise development issues which may affect delivery dates, quality,
and functionality deviations to the IT Project Manager.
• Ensure issues arising out of Non Functional, Functional System
Testing and BAT are corrected.
• Work with the Test Lead to have all defects resolved throughout all
phases of testing.
Business Analyst • Document all change requests raised by the Business.
• Review Test Deliverables.
• Prepare for and coordinate BAT (including the preparation of the BAT
test criteria).
• Validate incidents raised against the BRD and or FSD.
• Clarify issues with the business.
• Coordinate business users during BAT (If business users are
available).
• Assist Business Users with the creation of the test criteria document
• Plan, prepare and coordinate production verification
Developers • Plan and perform Unit, Code Integration and Non Functional Testing.
• Fix incidents and update Incident Management tool with resolution
details.
• Support the test lead and test analyst on a day to day basis during
the different phases of testing.
18. Appendix