test strategy template
Post on 23-Nov-2014
467 Views
Preview:
TRANSCRIPT
Test Strategy
<<Work request #>>
Author: Authorized By: Status: Owner: Version: Last Updated:
<<Work Request>>Test Strategy
1. Amendment History
Version Date Created
Created/Amended By
Approved/ Reviewed By
Change Detail
2. Distribution
Recipient Role/Team
3. Supporting Documentation & Reference
Reference Name Author Date Version
4. Test Strategy Document Sign-Off
<<work request>> Test Strategy – not ready for release Page 2 of 21
<<Work Request>>Test Strategy
Name Role Date Signature
3. Table of Contents
Release Notices.................................................................................................................................1
1. Amendment History................................................................................................................22. Distribution..............................................................................................................................23. Supporting Documentation & Reference..............................................................................24. Test Strategy Document Sign-Off.........................................................................................33. Table of Contents................................................................................................................... 3
<<work request>> Test Strategy – not ready for release Page 3 of 21
<<Work Request>>Test Strategy
5. Glossary of Terms..................................................................................................................56. Introduction.............................................................................................................................57. Test Approach.........................................................................................................................58. Test Techniques...................................................................................................................119. Test Objective and Coverage...............................................................................................1310. High Level Project Timeline.................................................................................................1511. Resources.............................................................................................................................1712. Test Environment................................................................................................................. 1913. Configuration Management.................................................................................................2014. Incident Management...........................................................................................................2015. Test Status Reporting...........................................................................................................2316. Issues & Risks...................................................................................................................... 2317. Communications...................................................................................................................2318. Roles and Responsibilities..................................................................................................2419. Appendix.................................................................................................................................26
<<work request>> Test Strategy – not ready for release Page 4 of 21
<<Work Request>>Test Strategy
5. Glossary of Terms
Acronym/Abbreviation
Description/Definition
6. Introduction
7. Test Approach
TEST FRAMWORKTesting 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.
<<work request>> Test Strategy – not ready for release Page 5 of 21
<<Work Request>>Test Strategy
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’sAccountable - Development ManagerResponsible – DevelopersDeliverables – Execution
Code Integration Testing Code Integration testing is a test where individual software modules are combined and tested as a group. The overall idea is a "building block" approach, in which verified assemblages are added to a verified base which is then used to support the integration testing of further assemblages.Approach – Code Integration testing will be completed after development of each requirement. When the requirements have been developed and tested they will be released to the test team to commence functional testing. It is a possibility parallel development and functional testing may be needed. This will be identified upon completion of the work break down structure Accountable - Development ManagerResponsible – DevelopersDeliverables – Test Plan, Test Criteria, Test Status reporting, Sign off and Execution Note: Sign off will be provided by Development Manager with the CIT exit criteria to be met.
Smoke Testing
<<work request>> Test Strategy – not ready for release Page 6 of 21
<<Work Request>>Test Strategy
A smoke test is a validation test performed by the business analyst and test analyst after code integration testing but before functional system testing and then again after functional system testing but before business acceptance testing. This test provides the business analyst and test analysts with the ability to review the developed solution before the next phase of comprehensive testing commences. Approach – This testing is executed after all development has been completed, the smoke testing will be executed after code integration testing but before functional testing. The smoke testing will need to be executed on each requirement when made available for functional testing. This test is to be completed prior to functional testing of the requirements commence.Accountable – Test LeadResponsible – Test Analyst and Business AnalystDeliverables – Test Criteria, Sign off and ExecutionNote: Sign off will be provided by the Test Lead.
Functional System Testing including E2E Functional system testing will be conducted by a Test Analyst. Functional system testing will be based on the signed off version of the Functional Specification Document. This phase of testing is to ensure the functions of the developed <<work request>> solution are as per the FSD.A key focus of this phase is the end-to-end (E2E) and regression testing which provides a full examination of the system under test. This is generally undertaken prior to the BAT phase to ensure the majority of key defects have been adequately resolved and the system stabilised. Accountable – Test LeadResponsible – Test Analyst Deliverables – Test Plan, Test Matrix, Test Scripts, Test Status reporting, Sign off and Execution Note: Sign off will be provided by the Test Lead.
Non Functional System Testing Performance testing is the process of determining the speed or effectiveness of the ING DIRECT applications (eg. web and middleware) and is executed by a developer. This test involves measuring the response time even the number of instructions per second at which the application functions. Load/Stress testing is the process of subjecting ING DIRECT applications to their breaking point, testing beyond the normal operational capacity and is executed by a developer.Security Testing will verify the security of the application, looking at the external interfaces as well as the internal interfaces. The ability to disrupt services, perform fraudulent transactions or
<<work request>> Test Strategy – not ready for release Page 7 of 21
<<Work Request>>Test Strategy
intercept private information will be tested. This testing is executed by the security team and/or an external ethical hack vendor.Accountable – Test LeadResponsible – DeveloperDeliverables – Test Plan, Test Criteria, Test Status reporting, Sign off and Execution Note: Sign off will be provided by the Test Lead and the Development Manager.
Business Acceptance Testing BAT is executed formally by business users and/or Business Analyst acting as a proxy of the business user performing business operational testing to enable them to determine whether to accept a system based on the Business Requirements document.Accountable – Test LeadResponsible – Business users and/or business analyst (still to be decided)Deliverables – Test Plan, Test Criteria, Test Status reporting, Sign off and Execution Note: Sign off will be provided by the Test Lead and the Business.
Entry and Exit Criteria
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.
Upon entry into a phase of testing a testing certificate will be released to all business and IT stakeholders advising that testing has formally commenced. This certificate will be sent by email and will contain the entry information that has been satisfied.
<<work request>> Test Strategy – not ready for release Page 8 of 21
<<Work Request>>Test Strategy
8. Test Objective and Coverage
The objective of testing the <<work request>> solution is to ensure each element of the application integrates and meets the functional, design and business requirements:
Note: testing will cover positive, negative and regression
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
Business Requirements <<work request>>
No. Name
<<work request>> Test Strategy – not ready for release Page 9 of 21
<<Work Request>>Test Strategy
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>>.
9. High Level Project Timeline
The project time line for project <<work request>> can be found in the project folder:
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 StrategyEffort required in
days To be commenced To be completed
Test Strategy
Non Functional System TestingEffort required in
days To be commenced To be completed
Non Functional System Test Plan<<work request>> Test Strategy – not ready for release
Page 10 of 21
<<Work Request>>Test Strategy
Test Criteria Document
Non Functional Test execution
Smoke TestingEffort required in
days To be commenced To be completed
Smoke Test Criteria to move to Functional Testing
Smoke Test Execution to move to Functional Testing
Smoke Test Criteria to move to BAT
Smoke Test Execution to move to Functional BAT
Functional System TestingEffort required in
days To be commenced To be completed
Functional System Test Plan
Test Scenario Matrix
Test Scripts
Functional Test Execution
Business Acceptance TestingEffort required in
days To be commenced To be completed
<<work request>> Test Strategy – not ready for release Page 11 of 21
<<Work Request>>Test Strategy
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
Test Execution
Resource skill for Execution No. Required Date Required StatusTest LeadCode Integration Testing
<<work request>> Test Strategy – not ready for release Page 12 of 21
Resource skill for Preparation No. Required Required StatusTest LeadCode Integration TestingDevelopers Test Analyst Smoke TestingBusiness AnalystTest AnalystDevelopersFunctional TestingTest AnalystsBusiness AnalystsNon Functional TestingDeveloperTest AnalystBusiness Acceptance TestingBusiness AnalystUsers
<<Work Request>>Test Strategy
Developers Test Analyst Smoke TestingBusiness AnalystTest AnalystDevelopersFunctional TestingTest AnalystsBusiness AnalystsDevelopersNon Functional TestingDeveloperBusiness AnalystTest AnalystBusiness Acceptance TestingBusiness AnalystTest AnalystDeveloperUsers
Hardware Required
Software Required
Browsers
Vist
a
Win
dow
s O
ffice
Mac
into
sh
LAN
Co
nnec
tion
ADSL
Co
nnec
tion
Dia
lup
Conn
ecti
on56
.6K
Scre
en
Reso
luti
on
1024
x 7
68
<<work request>> Test Strategy – not ready for release Page 13 of 21
<<Work Request>>Test Strategy
11. Test Environment
The following table outlines the regions that will be utilised throughout testing of <<work request>>
Test Phase<<work request>>
Unit Test ExecutionCode Integration Test ExecutionFunctional (E2E) System Test Execution inc. regressionNon Functional System Testing ExecutionBusiness Acceptance Testing Execution
12.Configuration Management
13. Incident Management
<<work request>> Test Strategy – not ready for release Page 14 of 21
<<Work Request>>Test Strategy
This section identifies how the incidents will be documented and managed. It is the responsibility of each phase of testing to assign their defects a severity.
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 DefinitionThe following table provides a guideline for classification of incidents found during the course of testing.
SEVERITY 1
Syst
em fa
ilure
The application or an essential part of it is totally unavailable (major system failure) and is causing testing to stop pending problem resolution. No feasible workaround is available for the problem.Response should be given within 2 hours including an estimate of time for fixing the problem. It is expected that the problem will be rectified within 24 hours.
SEVERITY 2
Func
tion
failu
re
The application or an essential part of it is not working or is working with reduced or incorrect functionality; however it is not seriously impacting testing because there is a feasible workaround.Response should be given within 4 hours including an estimate of time for fixing the problem. It is expected that the problem will be rectified within 2 days.
SEVERITY 3
Req
uire
men
t fa
ilure
A non - essential function is not working or is working with reduced or incorrect functionality. The business impact is small.Response should be given within 12 hours including an estimate of time for fixing the problem. It is expected that the problem will be rectified within 5 days.
<<work request>> Test Strategy – not ready for release Page 15 of 21
<<Work Request>>Test Strategy
SEVERITY 4M
inor
di
scre
panc
y
A minor problem exists in the application, no effect on the business.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
<<work request>> Test Strategy – not ready for release Page 16 of 21
14.Test Status Reporting
What status reports will be generated
15. Issues & Risks
Any issues and risks identified during test planning and execution will be reported to the IT project manager
Dependencies
Assumptions
16.Communications
Meeting Name IT <<work request>> Test Team meetingsMeeting Objective
Attendees
FrequencyDurationAgenda
Meeting Name Cross Project DependenciesMeeting Objective
An opportunity for all test leads to get together to communicate AttendeesFrequencyDuration
<<Work Request>>Test Strategy
Agenda
17.Roles and Responsibilities
Role ResponsibilityTest Manager Escalation point for Test Lead
Provide Sign off of test strategy and planTest 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.
<<work request>> Test Strategy – not ready for release Page 18 of 21
<<Work Request>>Test Strategy
Contribute to the test status report Log and retest defects. Communicate issues and risks to the Test Lead. Support BAT environment and lab during BAT phase.
T Project Manager
Log any testing issues into the Project Issues/Risks register log. 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 Manager
Ensure Unit Testing is undertaken and the results formally 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.
<<work request>> Test Strategy – not ready for release Page 19 of 21
<<Work Request>>Test Strategy
18.Appendix
<<work request>> Test Strategy – not ready for release Page 20 of 21
top related