4/24/2018

SOFTWARE TEST STRATEGY DOCUMENT

WRITTEN BY : BURHAN RASOOL

ROLL NO: 38
SUBMITTED TO: DR. ZEESHAN
 Revision and Signoff Sheet

Version Date Author Description of Change

1 24/04/2018 Burhan Rasool First Draft

1. INTRODUCTION

1.1. Purpose
This test plan describes the testing approach and overall framework that will drive the testing of
Mobile Store System.

Test plan:

Features to be Tested:
 Login and authentication module
 Data storage Module
 Input and output process Module
 Design of the software
Features Not to Be Tested:
 We will not test network related issues

Approach:
 We will perform black box testing
 We will also perform white box testing
Item Pass/Fail Criteria:
 Item will be pass and fails if they don’t give required output.
 The storage failure will result in failure of function
Test Environment:
 We will use java test tool called j unit test on core i5 laptop.

Schedule:
 We will test software on Monday and Tuesday.

EXECUTION STRATEGY

Entry and Exit Criteria

 The entry criteria refer to the desirable conditions in order to start test execution; only the
migration of the code and fixes need to be assessed at the end of each cycle.

 The exit criteria are the desirable conditions that need to be met in order proceed with the
implementation.

 Entry and exit criteria are flexible benchmarks. If they are not met, the test team will assess
the risk, identify mitigation actions and provide a recommendation. All this is input to the
project manager for a final “go-no go” decision.

 Entry criteria to start the execution phase of the test: the activities listed in the Test
Planning section of the schedule are 100% completed.

 Entry criteria to start each cycle: the activities listed in the Test Execution section of the
schedule are 100% completed at each cycle.

Functional Test

PURPOSE: Functional testing will be performed to check the functions of application. The
functional testing is carried out by feeding the input and validates the output from the
application.

Scope: The below excel sheet details about the scope of Functional test. Note: The scope is
high level due to changes in the requirement.

To keep the document easily fragmented and categorized, the scope has been embedded as
separate document. If you prefer you can insert a table here itself. The scope is created based
on the Test scenarios that were identified in the previous article.

Functional Testing
Scope.xlsx

TESTERS: Testing Team.

METHOD: The test will be performed according to Functional scripts, which are stored in HP
ALM.

TIMING: after Exploratory test is completed.

TEST ACCEPTANCE CRITERIA
 Approved Functional Specification document, Use case documents must be available prior to
start of Test design phase.

 Test cases approved and signed-off prior to start of Test execution

 Development completed, unit tested with pass status and results shared to Testing team to avoid
duplicate defects

 Test environment with application installed, configured and ready to use state

Sign-off Readiness

•Approved Functional Specification Document •Development completed & unit tested

•Approved Use cases •Application deployed and system ready for
•Approved Test cases testing on Test environment
•Production like data is available to test all
functionalities.
•Defect fixes planned based on Defect
triage (Unit Testing) and evaluation criteria
User Acceptance Test (UAT)

PURPOSE: this test focuses on validating the business logic. It allows the end users to
complete one final review of the system prior to deployment.

TESTERS: the UAT is performed by the end users (L1, L2 and L3).

METHOD: Since the business users are the most indicated to provide input around
business needs and how the system adapts to them, it may happen that the users do
some validation not contained in the scripts. Test team write the UAT test cases based
on the inputs from End user (L1,L2 and L3 users) and Business Analyst’s.

TIMING: After all other levels of testing (Exploratory and Functional) are done. Only after
this test is completed the product can be released to production.

TEST DELIVERABLES

Test Effort Estimate

This document lists out all the activities that have to be performed by the QA team and
estimates how many man-hours each activity is going to take.
EXECUTION STRATEGY

4.1. Entry and Exit Criteria

 The entry criteria refer to the desirable conditions in order to start test execution; only
the migration of the code and fixes need to be assessed at the end of each cycle.

 The exit criteria are the desirable conditions that need to be met in order proceed with
the implementation.

 Entry and exit criteria are flexible benchmarks. If they are not met, the test team will
assess the risk, identify mitigation actions and provide a recommendation. All this is input
to the project manager for a final “go-no go” decision.

 Entry criteria to start the execution phase of the test: the activities listed in the Test
Planning section of the schedule are 100% completed.

 Entry criteria to start each cycle: the activities listed in the Test Execution section of the
schedule are 100% completed at each cycle.

Test Technical
Exit Criteria Notes
Team Team

100% Test Scripts executed

95% pass rate of Test Scripts

No open Critical and High severity defects

95% of Medium severity defects have been closed

All remaining defects are either cancelled or

documented as Change Requests for a future release
 Risk Prob. Impact Mitigation Plan

of the testing is delayed due to and the early communication

design tasks, the test cannot be with involved parties.

extended beyond the UAT  Some buffer has been added to

scheduled start date. the schedule for contingencies,
although not as much as best
practices advise.

RESOURCES Holidays and vacation have been

Not enough resources, resources on estimated and built into the
boarding too late (process takes Medium High schedule; deviations from the
around 15 days. estimation could derive in delays in
the testing.

DEFECTS Defect management plan is in place

Defects are found at a late stage of to ensure prompt communication
the cycle or at a late cycle; defects and fixing of issues.
discovered late are most likely be
Medium High
due to unclear specifications and
are time consuming to resolve.

SCOPE Scope is well defined but the

Scope completely defined changes are in the functionality are
Medium Medium
not yet finalized or keep on
changing.

Natural disasters Teams and responsibilities have

Test Metrics

Test metrics to measure the progress and level of success of the test will be developed and shared
with the project manager for approval. The below are some of the metrics

Report Description Frequency

Test To report on % complete, %WIP, % Pass, % Fail Weekly / Daily

preparation (optional)
Defects severity wise Status – Open, closed, any other
&
Status
Execution
Status

Daily To report on Pass, Fail, Total defects, highlight Daily

execution Showstopper/ Critical defects

status

Project Project driven reporting (As requested by PM) Weekly – If project

Weekly team needs weekly
Status update apart from
report daily and there is

template available