RedSyn - Test Plan Document
RedSyn - Test Plan Document
RedSyn - Test Plan Document
This document serves as high level test planning document with details on the scope of the project,
test strategy, test schedule and resource requirements, test deliverables and schedule.
Scope
The scope of the project includes testing the following features of ‘https://xyz.in’ web application.
Inclusions
Customers
o Create Customer
o Account Summary details
New Orders
o Create/Edit Order
o Verify the details displayed in Account Summary page > Summary tab
o Verify the order details in Account Summary page > Orders tab
o Verify the order details in View Details page
Create and Run a Billing Cycle to generate invoice
o Create a Billing Cycle
o Start Manual Billing Run
o Verify the invoice details before payment
o Download and email the invoice
Make Payment
o Add a payment method
o Make payment as Client using
Credit Card
Check
Cash
o Make payment as Customer using
Credit Card
o Verify details in the invoice details, Account Summary Page > Summary and
Payments tabs
From our understanding, we believe above functional areas will cover our Functional Testing
Scenario.
Functional Testing Scenario will be run against the following test data,
Product: XYZ-SUBSCRIPTION
Charge:
Price Type:
Test Environments
Windows 10 + IE 11
Exclusions
All the features except that are mentioned under ‘Inclusions’
Test Strategy
Functional Testing
EnoFlux will create and execute the Test Cases for the above feature(s) mentioned in the ‘Inclusions’
for RedSyn’s ‘https://xyz.in’ Web Application.
Functional Testing – Testing each feature (within the scope of pilot) of RedSyn’s ‘https://xyz.in’ web
application to identify things the product can do as per expectations.
Flow & Scenario Testing – Apart from testing individual features, flows and scenarios will be created
to replicate end user actions with the application.
Usability Testing – Testing the ease with which the user and test whether the application built in
user-friendly or not.
Problem Tracking and Test Tracking Procedures
Defect Reporting Procedure:
Any deviation from expected behaviour by the application will be noted. If it can’t be
reported as a defect, it’d be reported as an observation/issue or posed as a question.
Any usability issues will also be reported.
After discovery of a defect, it will be retested to verify reproducibility of the defect.
Screenshots with steps to reproduce are documented.
Every day, at the end of the test execution, defects encountered will be sent along with the
observations.
Note: