Xses Internet shop

TEST PLAN
https://sitefortest.ognivko.com/
Version 2.1.0.2
Revision History
Date Version Description Author Reviewed
20.01.19 1.0 Creating Liubov Oksana
Ohnivko Popovs'ka
04.02.19 2.0 Updating Liubov Oksana
Ohnivko Popovs'ka
01..03.19 3.0 Updating Liubov Oksana
Ohnivko Popovs'ka
 Xses Internet shop
TEST PLAN
Version 2.1.0.2
1 Project Identifier

Xses Internet shop, version 2.1.0.2, trial version.

Introduction
The Xses Test Plan is designed to prescribe the scope, approach, resources,
and schedule of all testing activities. It identifies the items to be tested, the
features to be tested, the types of testing to be performed, the personnel
responsible for testing, the resources and schedule required to complete
testing, and the risks associated with the plan.

1.Scope of Testing

1.1 Feature to be tested

The systems to be tested include the frontend customerfacing website
along with the backend ecommerce admin platform. Thus we consideer
the following features are needed to be tested .

USER:
•Registration -high priority
•Login — high priority
•Add To Cart — high priority
•Edit Cart — high priority

ADMIN:
•Create and Delete items from Category — high priority
•Create and Delete a Category — high priority
•Manage Orders — high priority
•Manage Members - high priority
1.2 Features not to be tested
Mobile purchasing through a mobile device will not be tested. Only
desktop web browser functionality will be tested.
These features are not to be tested because they will be done by separate
teams of testers :
• Software Interfaces
• Database logical
• Communication Interfaces
• installation
• Database
• Upgrade testing
• Security testing

2. Approach
The following types of testing ensure that the each feature and the
combination of the features are adequately tested.
2.1 Component testing
2.2 Integration testing
Both types of testing mentioned above won't be done by our team as they
are under develpers' responsibility.
2.3 System testing
Our team is included into the process of testing on the level of System
testing.
The following preconditions should be considered as Entry criteria for
the system testing stage:
• Application has passed the exit criterion for integration testing.
• Test Cases / Scripts, which needs to be executed in this stage, are
ready.
• tested content, features, and functionality of the product are verified
as feature-complete.
• The user interface and the feature set are frozen.
• The Technical Lead has submitted all files for integration
accompanied by Release Notes.
• The Integration engineer has tested for installability.
• All priority bugs have been fixed and closed.
 • Internal documentation has been updated to reflect the current state of
the product.
After completion of system testing all functional as well as non functional
requirements must be tested and important defects should not be in open
state. So following are considered as Exit criteria for the system testing
stage:
 All priority bugs are fixed and fix is verified.
 Test cases scheduled for system test phases have passed.
 Completion criterions have met for all types of testing related to
system testing stage
 The software runs on all the product’s supported hardware and
software configurations.

In the project Xses, the following types of system testing should be

conducted.

Sr. Type of Testing Testing Process

#
1. Functional • going through the entire website,
including content management system
or admin area, to make sure that each
function within the website is
performing as it should be.
2 Browser compatibility • Lack of support for early browsers
• Browser specific extensions
• Browser testing should cover the main
platforms (Linux, Windows, Mac etc.)

3 Usability • Non-intuitive design

• Poor site navigation
• Catalog navigation
• Lack of help-support

4 Availability • Availability 24/7

5 Internationalization • Language support

 • Date, time, location,currency
6. Performance Load handling
• Scalability analysis shows you when
your website is slowing down, which
pages are taking time to load and what
element of the page is causing the
problem.

2.4 Acceptance testing

The Entry Criteria
• Business Requirements must be available.
• Quality Assurance Plan approved
• Unit Testing, Integration Testing & System Testing should be completed
• All priority bugs have been fixed and closed.
• The software runs on all the product’s supported hardware and software
configurations.
• Application Code should be fully developed
• No High, Medium defects in System Integration Test Phase
• Only Cosmetic error is acceptable before UAT
• Regression Testing should be completed with no major defects
• All the reported defects should be fixed and tested before AT
• Traceability matrix for all testing should be completed
• AT Environment must be ready
• The Acceptance Tests must be completed, with a pass rate of not less than
100%
 Exit criteria for AT:
Before moving into production, following needs to be
considered:
No critical defects open
• Business process works satisfactorily
• AT Sign off meeting with all stakeholders
• All High Priority errors from System Test must be fixed and
tested
*No critical defects have been left out.
• Signing off acceptance testing
• Approval from management to stop AT.
Sanity testing
In this phase, we check the basic functionalities, like
1. login with valid credentials,
2. login with invalid credentials,
3. user's info are properly displayed after logging in,
4. making a purchase order with a certain user's id,
5. the "thank you" page is displayed after the purchase

Entry criteria
◦ No critical defects open
• Unit Testing, Integration Testing & System Testing should be
completed
• any minor bug is fixed or when there is a small change in the
functionality.
▪ after the changes or fixes are done in the code the
software build is available to the testers.
Exit criteria
• application works properly after minor changes
• new functionalities are working
• any dependent missing functionalities are defined
 Confirmation testing.
Entry criteria:
• there is a modification in the code based on the change in requirements.
• a new feature is added to the application.
• defects are fixed in the application.
• major performance issues are fixed in the application.
Exit criteria
• the failed test cases are re-executed.
• originally reported defects are corrected.
• the issue is fixed and working as expected.
• the quality of the application or product is improved

Regression Testing
Passing entry criteria for regression testing should indicate that code has
passed system testing and preparation for the regression testing (which
includes necessary test scripts and configurations of application) has
completed. So following are entry criteria for regression testing.
• Exit criteria for system testing have been met
• Regression Test Scripts are ready.
• Security Key / Configuration keys are finalized.
• Consistency Verification Test script is ready.
Exit Criteria
• All priority bugs are fixed and fix is verified.
• If any medium or low-priority errors are outstanding - the
implementation risk must be signed off as acceptable by Business
Analyst and / or Client.
• No open Issues / Queries exist.

3. Pass/Fail Criteria
All core functionality of the systems should function as expected and
outlined in the individual test cases. There must be no critical defects
found and an end user must be able to complete a purchase cycle
successfully and initiate a refund without any errors. 95% of all test cases
should pass and no failed cases should be crucial to the end user’s ability
to use the website
Tests executed against the system use the functional requirements, non-
functional requirements, and use cases as the oracle to determine pass or
fail.
Product
passed if:
• No critical defects open
• Business process works satisfactorily
• AT Sign off meeting with all stakeholders
• All High Priority errors from System Test must be fixed and tested
*No critical defects have been left out.
• Signing off acceptance testing
• Approval from management to stop AT.
Failed if :
AT exhibits a product failure to meet the objectives of any of the
functional requirements, non-functional requirements, or the use cases.

Testcases
passed— steps fullfilled
its actual result matches its expected result.

Failed - steps fullfilled

its actual result does not match its expected result.

Blocked - A test case that cannot run because the preconditions for its
execution are not fulfilled.

4. Suspension criteria and resumption requirements

4.1 Suspension criteria
If the system contains one or more critical defects like the defects in the
GUI editor which provides the editing features for one line diagrams and
database locking, unlocking and sharing features which provides the
environment for multiple users to work in parallel, the entire system
should be suspended.
• The testing may also be suspended if the hardware and software
components required are not available on time.

• The failed test cases should be recorded along with the description
for failure.
• The build contains many serious defects which seriously or
limit testing progress.
• Significant change in requirements suggested by client
• Assigned resources are not available when needed by test team.
• When a defect is introduced that cannot allow any further
testing.
• Critical path deadline is missed so that the client will not accept
delivery even if all testing is completed.
• A specific holiday shuts down both development and testing.

4.2 Resumption requirements

When a new version of the system is transmitted to the test group after a
suspension of testing has occurred, all previous tests will be rerun to
ensure program changes have not inadvertently affected other portions of
the program. Resumption will only occur when the problem(s) that
caused the suspension have been resolved.
• When the external dependent systems become available again.
• When a fix is successfully implemented and the Testing Team is
notified to continue testing.
• The contract is renegotiated with the client to extend delivery.
• The holiday period ends
5. TEST DELIVERABLES
 Test deliverables for the project are provided as below:

- Before testing phase

Test plans document.
Test cases documents
Test Design specifications.
During the testing
Test Tool
Simulators.
Test Data
Test Traceability Matrix
Error logs and execution logs.
After the testing cycles is over
Test log
Test Results/reports
Defect Report
Release notes
Update test cases

6. TEST TASKS and SCHEDULE

No. Task Due date Who will do Approved by

1. Test plan 21.01.19 tester PM
2. Test design 21.01.19 Tester PM
3. Test Execution 24.01.19 Tester PM
4. Test Report 24.01.19 Tester PM
5. Test Delivery 24.01.19 Tester PM

7. ENVIRONMENTAL NEEDS
The following tools will be employed for this project:
Tool
Test Management
Test rail
Defect Tracking Jira
 Test Coverage
Test rail
Monitor or Profiler
Project
Jira
Management

For the test environment, a key area to set up includes :

• System and applications
• Test data
• Client operating system
• Browser
• Hardware includes Server Operating system
• These systems should be tested in EDGE, FireFox, Safari, Chrome
and Internet Explorer.
• The systems should be tested on Windows, Linux and Mac
machines.
Documentation required like reference documents/configuration
guides/ user manuals

8. Responsibilities

No. Member Tasks

1. Project Manages the whole project ;
Manager Defines project directions ;
Acquire appropriate resources .
2. Tester Identifies and describes appropriate
techniques/tools/automation architecture ;
Verifies and assesses the Test Approach ;
Executes the tests, logs results, reports the defects.

9. Staffing And Training Needs

Testing should be done by all the members of the testing team. The testers
assigned should have basic knowledge in the domain of the ecommerce
platform.

10. Risk and Contingencies

Risk name Description Level Mitigation
Team member High Plan training
lack the required course to skill up
skills for website your members
testing.
SCHEDULE High Set Test Priority for
The project Testing schedule is each of the test
schedule is too tight. If the start
of the testing is
activity.
tight;it's hard to delayed due to
complete this design tasks, the test
project on time cannot be
extended beyond the
UAT
scheduled start date.

Test Manager has Plan leadership

poor training for
management skill manager
A lack of Middle Encourage each
cooperation team member in his
negatively affects task, and inspire
the employees' them to greater
productivity efforts.
Wrong budget High Establish the scope
estimate and cost before beginning
overruns work, pay a lot of
attention to project
planning and
constantly track and
measure the
progress

DEFECTS defects High Defect

Defects are discovered late are management plan
found at a late most like is in place
stage of ly be to ensure prompt
the cycle or at a due to unclear communication
late cycle; specifications and and fixing of
are time consuming to issues.
resolve.

Scope Creep – as testers become more High Each iteration,

familiar with the tool, functionality will be
they will want more closely monitored.
functionality Priorities will be set
and discussed by
stakeholders. Since
the driver is
functionality and
not time, it may be
necessary to push
the date out.
Loss of all test Changes to the High Export data prior to
cases functionality may any upgrade,
negate the tests already massage as
written and we may necessary and re-
loose test cases already import after
written upgrade.

11. Approvals
The test manager and product manager both must agree on completion of
the testing project and determine when it’s ready to proceed to the next
step.