BAU SPRINT TEST PLAN
Services
BAU- Test Plan
– Nordstrom FSM Federation Bronze Layer
Caution: The online version of this document is the
master. To ensure that printed copies are current, compare the revision level
and date of the printed copy to the online master. Destroy all printed copies
immediately after use.
Copyright © 2021
Unisys Limited
All Rights Reserved
Unisys is a trademark of Unisys
Corporation
Revision and Signoff
Change
Record
|
Date |
Author |
Version |
Change Reference |
|
06 Oct
2021 |
Santhosh Jadala |
1.0 |
Initial
draft |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name |
Version Reviewed |
Position |
Date |
|
|
|
|
|
12 Tracking and Reporting
Status
13 Bug Reporting Tools and
Methods
13.1 Bug Reporting Tool
Strategy
13.2 Bug Classification
Strategy
1 Test Plan Summary
This document defines the overall
approach, strategy and the plan that will be taken to test scoped BAU requirements
of Nordstrom FSM Federation of Bronze layer. It identifies the scope of
testing, the goals, objectives and the various testing approaches to be
followed. Reading this artifact will provide a complete understanding of the
way this project will be tested.
2 Objectives
The objective of this document is to communicate:
·
Test Strategy
·
Test Approach and Techniques
·
Test Environment Specifications
·
Testing Processes
3
Scope
3.1 In Scope
|
Requirements - Azure DevOps |
|
User
Story 6462: FSM-Bronze Setup Nordstrom - Boards (azure.com) User
Story 6595: FSM-Federated accounts and Table sync process - Boards
(azure.com) ·
Verifying DSN login configured in
package used to sync data ·
Testing list of tables in ODS_NS_BZ
database matches with mapping table ·
Testing data loaded into tables of ODS_NS_BZ
database after data sync is having specific data of Nordstrom ·
Testing of views created for fetching
data from Global database (ODS_SN_FSM) are having Nordstrom filter |
3.2
Out of Scope
· Performance
testing of data load
· Functionalities
other than scoped items
4
Test Strategy
The test strategy for UCARE application is summarized in
below:
· Test Team will review the project artifacts
like Functional specifications, Design Documents and Mapping Documents. Analyze
various applicable test approaches and will come up with a test strategy/plan
document to detail out relevant testing aspects.
· Test team will prepare test cases based on the
functional specifications and design documents for each module, for all the
functional and non-functional requirements.
· The
approach behind testing is risk-based testing wherein all test cases are
prioritized and classified according to criticality in functionality. The test cases will be classified as P1, P2,
P3 and P4 (P1 being highest priority and P4 being lowest priority). This
classification is based on the criticality of the functionality that is being
tested.
·
A subset of P1 test cases will be identified as
BVT (Build Verification Test). The BVT test cases suite would be reviewed by
Development lead to ensure the functional coverage and effective build
acceptance criteria.
·
Test case priority, % of the total test cases and
definition is given below-
|
Test
Type |
% |
Definition |
|
BVT |
5-10 % |
Part of P1 test cases. All build certifying, smoke tests, high
level sanity test cases. |
|
P1 |
20-25% |
Test cases of Main or Important module & Frequently performed
business scenarios |
|
P2 |
30-35% |
Test cases of Non – Core & Frequently performed business
scenarios |
|
P3 |
30-35% |
Test cases of Non – Core & non-frequently performed business
scenarios |
|
P4 |
20-25% |
Test cases pertaining to nice to have, cosmetic genre, like
spellings & rare scenarios |
Note that actual P1, P2, P3 and
P4 test cases % could vary during the course of the test case planning.
· Requirement traceability matrix will be
generated, mapping each requirement to test case, demonstrating the coverage of
the test. The traceability details will help the team to assess regression
impact.
· On receiving build, test team will execute
applicable build verification tests. On Successful Build verification, execute
system tests on the interim build of the completed modules in the interim build
·
The identified BVT test cases will be considered
as automation candidates. A detailed feasibility analysis will be performed to
determine the automation scope and ROI.
5
Test Stages
Below table summarizes various test stages for UCARE
application along with associated ownership details:
|
Test Type |
Description |
Environment |
|
|
|
|
Unit Testing |
Documenting and executing unit test cases are the
responsibility of the developers. |
Development |
|
|
|
|
System Testing |
System Testing focuses on the functionality meeting
the design. |
Test |
|
|
|
|
User Acceptance Testing (UAT) |
User functionality of key real-world scenarios. |
UAT |
|
|
|
6
Risks and Assumption
6.1
Risks
·
Dedicated QA environment
is not in place and using the DEV/UAT environment based on availability for
testing
6.2
Assumptions
Following are the assumptions in this project:
·
Customer/Business
approval of functional specifications is considered final. If changes of functionality are discovered
during testing or UAT testing it could result in delay in schedule.
·
Requirements discussed
and documented in the User Stories would be developed as per plan.
·
Test environment
availability is important to meet testing requirements and will be available at
the start of the stabilization period along with access credentials.
7
Schedule
The high-level test activities and timing are depicted in the
table below.
|
Sprint |
Task |
Planned Start Date |
Planned Completion Date |
|
Sprint 63 |
Test Case Design |
07-Oct-21 |
08-Oct-21 |
|
Sprint 63 |
Test Case Review |
08-Oct-21 |
11-Oct-21 |
|
Sprint 63 |
Test Execution |
11-Oct-21 |
13-Oct-21 |
|
|
Test Sign Off |
14-Oct-21 |
14-Oct-21 |
Based on the subsequent sprints,
the start date and end date will be planned.
8
Test Team
|
Name |
Role |
|
Santhosh
Kumar Jadala |
Test
Lead |
|
Baven
Babu |
Tester |
9
Test Environment
For Nordstrom FSM Federation
Bronze layer testing, using UAT as test environment.
10
Testing Deliverables
The following test deliverables will be shared with team:
|
Project Phase |
Service Deliverable
Name |
Service Deliverable
Descriptions |
|
Plan |
Test Plan/Strategy |
Captures the test strategy and
execution plan needed to validate stability in the solution. |
|
Build |
System Test Cases |
Entire set of Test cases will be
delivered. |
|
Stabilize |
System Test Report |
Report listing all details of System
Test execution along with Go/No-Go recommendation by the test team will be
shared. |
11
Quality Criteria
11.1
Entry and Exit criteria
To achieve compliance to planned testing activities it is
imperative that entry and exit criteria are defined and signed off from
respective delivery owners. The Exit criteria for a phase is same as Entry
criteria for next phase and hence is not mentioned explicitly.
Following are the Entry Criteria identified for testing
phases.
QA Testing Entry Criteria
Following criteria should be
met for entry into testing phase
|
Phase |
Team |
Entry
Criteria |
|
Plan |
QA |
Requirement document describing complete details |
|
Design/ Development |
Dev |
Development of all planned features for the package is completed. Code review is complete. Unit testing is complete |
|
QA |
Creating Azure DevOps Test Plan with Suites Prepare test cases with linking to user story so that test
traceability is complete Test Plan is signed off by the team |
|
|
Testing |
QA |
Test Environment is ready and test data
is available. |
QA Testing Exit Criteria
Following criteria should be
met to exit QA & enter to UAT
·
100% system test execution by Test team for all the
delivered features.
· List
of Known issues is made available to team.
· UAT environment ready.
· Zero S1/S2 defects.
11.2
User
Acceptance criteria
The
following are the high-level acceptance criteria identified:
·
The
system will have met all the major business functionality and all of the high
priority requirements are covered.
·
The
system will have 0 S1/S2* defects.
*(S1 defect: Showstopper or Critical defect for the End user or the
Business. The solution is unusable to conduct business for the end users.
Development, testing, or production launch cannot proceed until the defect is
corrected. S2 defect: 1. Major defect
for the End user or the Business. The solution is usable.)
12
Tracking and Reporting
Status
Test team will send a test status
report daily during testing of the application.
13 Bug Reporting Tools and Methods
Azure DevOps has been chosen as
the defect/bug reporting tool.
Bug Life Cycle :
13.1 Bug Reporting Tool Strategy
·
All defects are verified
and then closed by Testers.
·
All bugs must include:
o
Clear repro steps
o
The results of the repro
steps
o
The expected results of the
steps
o
A detailed summary of the
issue
o
Severity
o Priority
o
When updating a bug always
provides extra detail (pretend that someone completely new to the system is
reading your bug and can’t ask you questions about it).
13.2
Bug Classification
Strategy
Bug Severity:
|
DevOps Severity |
Description of Severity |
|
S1 |
1. Showstopper or
Critical defect for the End user or the Business. The solution is unusable to
conduct business for the end users. 2. Development, testing,
or production launch cannot proceed until the defect is corrected. 3. Critical business
functionality or feature of the system is affected. 4. There is no work
around or the existing workaround is cumbersome. 5. More than 75% of User
acceptance tests or System tests are blocked |
|
S2 |
1. Major defect for the
End user or the Business. The solution is usable. 2. Major Business
functionality or feature of the system is affected. 3. There is work around. 4. 30% - 75 % of User
acceptance tests or System tests are blocked. |
|
S3 |
1. Minor defect for the
End user or the Business. 2. Minor Business
functionality or feature of the system is affected. 3. There is work around. |
|
S4 |
1. Work around is not
needed or the end user can live with the defect. 2. Less than 5% of User
acceptance tests or System tests are blocked. |
Bug Priority:
|
Priority |
Description of Priority |
|
P1 |
Showstopper
defect. Content migration approach must be altered to rectify issue. Must
fix as soon as possible. Defect is blocking further progress in establishing
content migration approach. Production-focused
content migration activities cannot begin until issue is resolved and
retested to conclusion. |
|
P2 |
Defect
must be fixed prior to moving to production-focused content migration
approach. Does
not affect Proof of Concept test plan execution for this Quick Start
engagement. |
|
P3 |
It
is important to correct the issue; however, it is possible to move forward
with this content migration strategy using a workaround for this particular
issue. Does
not impact content migration strategy (i.e., message change in user
experience program). |
|
P4 |
Design
change from original concepts. |
13.3
Bug
Triage Strategy
Bug
triage meetings within Team will be scheduled on need basis during test
execution to discuss the bugs with all the stakeholders for better
communication and faster resolution. Discussions should center on deciding
relevance, priority, and severity of bugs.
·
System
Testing
·
UAT
Testing
13.4
Bug Closure Criteria
· Bug is verified by test team and is working as
expected
· Bug is no longer an issue.
· Bug is resolved as by design.
· Bug will not be fixed.
· Bug is not reproducible.
· Bug is deferred for next release.
· Bug is duplicate.
Comments
Post a Comment