OrangeHRM

Test Plan

Created by:

Shivam Poojara (zest2019_trainee014)

Dhruv Haria (zest2019_trainee018)

 Test Plan OrangeHRM

Purpose:

This document provides strategy for testing and tells how testing will be done. It includes
scope, out of scope, entry criteria, exit criteria, testing plan and resource. This also describes
process for testing, bug tacking flow and deliverable. This article presents a high level details for
things which can be done and which can't be done, also it gives idea to stakeholders about
planning to achieve success in testing. As this is high level strategy, based on decision and change,
this article will be changed.

General Project Overview:

eFax Router is actually two applications – a Windows Service, and a Windows desktop
application to configure and manage the service. Individually, we call the Windows Service
eFax Router and the desktop application eFax Router Admin.

eFax Router:
eFax Router is a Windows Service application written in C#. It
continually
communicates with the eFax Enterprise API, polling for the customer’s faxes,
downloading them, and “routing” them to locations in the customer’s system –
a folder on a file system, a network printer, or a local application. eFax Router uses
JSON configuration files to direct how it operates. There are many configuration files
in an eFax Router installation: one main configuration file, one file for each user
(possibly hundreds), and one file for each fax handler (possibly dozens). While it is
possible for an administrator to manage these configurations manually, it is strongly
recommended that they use the eFax Router Admin application.

eFax Router Admin:

2
 Test Plan OrangeHRM
eFax Router is a Windows Service application written in C#. It
continually
communicates with the eFax Enterprise API, polling for the customer’s faxes,
downloading them, and “routing” them to locations in the customer’s system –
a folder on a file system, a network printer, or a local application. eFax Router uses
JSON configuration files to direct how it operates. There are many configuration files
in an eFax Router installation: one main configuration file, one file for each user
(possibly hundreds), and one file for each fax handler (possibly dozens). While it is
possible for an administrator to manage these configurations manually, it is strongly
recommended that they use the eFax Router Admin application.

eFax Router Admin is a Windows desktop application written in JavaScript

(Vue.js & Electron). Its main purpose is to provide an easy to use GUI for managing
the many configuration files required by eFax Router. It also has a secondary function
which is to provide an interface for starting, stopping, and restarting eFax Router.

3
 Test Plan OrangeHRM

There is actually a third application involved as well – the Installer application

itself. This installer (a Windows .msi file) installs both eFax Router and eFax Router
Admin. Naturally, it is the first thing to require testing.

Testing Approach:

In Scope

Sr. No. Particulars Details

1 Environment to be used for Testing -Production

-QA

2 Types of Testing to be done Sprint wise testing

-Smoke Testing
-End-To-End Functional Testing

-Regression Testing

-Retesting

Testing during free time of sprint

-Ad-Hoc Testing

-Exploratory Testing

Testing if requirement will come

-Load Testing

-windows 7,8,10(based on
3 OS on which the application is to
be tested availability)

4
 Test Plan OrangeHRM

Out of Scope
• OS: Windows xp or other older windows versions.
• Fax handler for print functionality will be excluded because any printer
will not be connected to the machine allocated to the QA.
• Security Testing, Acceptance Testing, Automation Testing

Main Functionality Under Test:

Testing eFax Router will happen in five phases:
• Installer: Ensure that the installer installs the applications correctly so
they can execute as expected.
• Windows Service: In isolation, ensure that the Windows Service can
start and stop successfully.

5
 Test Plan OrangeHRM

• Admin interface: This is where the bulk of the testing will occur. All the
tabs and functionality under those tab in Admin interface will be tested.
• processing of a fax: This will ensure that eFax Router can communicate
with the API, and that a fax can be properly processed.
• Uninstall process: This will ensure that eFax Router can perform a clean
uninstall.

Test environment

Sr. Hardware/ Software Specifications

No
Requirement

1 Windows 7,8 or 12 64 Windows Machine

Bits

2 Jira Bug Tracking Tool

3 Team Drive Document Management

Sprint wise testing strategy:

  User  Sprint
  Stories  Backlog

 Prioritize User Stories

6
 Test Plan OrangeHRM

Use Stories

Spr
int
Sprint 1

Backlog Test-case Sprint R

writing e
Test- Demo
g
case r
Executio e
n s
s
i
o
n
Spr
int
2

 Test-case Test-case Sprint Regressi Release1

Defects writing on
 Execution Demo


Test 
Planning Sprint n
 Sprint

 Backlog

Test-case Test-case Sprint Regressi

Defects writing Execution Demo on

7
 Test Plan OrangeHRM

Agile methodology will be followed for project development, and testing phase
will be planned accordingly.
Requirement Understanding:
o Requirement understanding will take place during sprint planning
meeting.
Estimation Phase:
o Story points/Estimation is given according piece of functionality taken in
testing at starting of sprint.

Test scenario/Test cases Creation:

o Test scenario/Test cases will be prepared on first and second sprint and
after that they will be updated or new scenarios will be added according
to functionality.
o Test scenario/cases will be managed in Excel tool and deployed in Team
drive of team canucks.
Test execution:
o Test execution will be taken in sprint after test-case/scenario creation
managed sprint wise.
o Smoke Testing, Functional Testing and Regression testing will be
performed most while sprint.
o Smoke testing will be take place at the starting of sprint. After that
Functional testing will take place.
o QA will execute all (Medium, Low) priority test cases during functional
testing cycle.
o After test-case execution sprint demo will be take place.
o Regression testing will be covered mostly in every sprint at the last stage
of execution.
o Sprint wise testing report will be sent to each stakeholder at end of the
test execution during testing phase of the sprint.
Defect Log:

8
 Test Plan OrangeHRM
o All identified issues/bug/improvement will be logged in Jira.
o Retesting of bug will be take place if bugs of priority level are take
resolved during sprint.

After Test case execution, sprint Demo will take place within the team members.
QA will be the part of calls with team member to discuss functionality,
understand functionality and to discuss daily work and sprint status.
Traceability Matrix will be prepared to match for each user story with
test scenarios/cases.
Traceability Matrix will be updated during each sprint with new scenarios as
per scope of sprint.
Test plan will be updated as and when needed.

9
 Test Plan OrangeHRM

Scope of another type of testing (Ex. Load Testing…) will be explored and
planned in testing as per applicability.
Sprint status, Test execution report, QA process will be discussed in
Retrospective meetings. And if required then test plan and test process will be
updated.
QA sign off will be prepared and shared with all stakeholders.

Types of Testing:

Smoke Testing: Smoke testing will be covered at starting of sprint. If important

functionality or main flow of system will not work, then QA will not accept the
build for further testing. Smoke testing is also known as ‘build verification
testing’.

Functional Testing: End to end functional testing will take place after smoke
testing. In functional testing, Testing based on an analysis of the specification of
the functionality of a component or system Functions are tested by feeding them
input and examining the output. Functional Testing usually describes what the
system does.

Regression Testing: Regression testing will be take place after functional testing
at the end of execution. It is considering the t esting of a previously tested
program following modification to ensure that defects have not been introduced or
uncovered in unchanged areas of the software, because of the changes made.

Retesting: When a test fails because of the defect then that defect is reported,
and a new version of the software is expected that has had the defect fixed. In

1
0
 Test Plan OrangeHRM
this case we need to execute the test again to confirm that whether the defect
got fixed or not.

Exploratory Testing: Exploratory testing will be performed occasionally or during

the free time of sprint. It is defined as a type of testing where Test cases are not
created in advance but testers check system on the fly. This testing will be
performed to get enough idea of testing.

Load Testing: Load testing will be performed if the requirement will come in
future. It’s one kind of performance testing which determines a
system's performance under real-life load conditions.
Tool: Tool will be decided in future if requirement comes and according to
conveniences of tester and stockholders

1
1
 Test Plan OrangeHRM

Team and Role:

Team member Designation Roles & Responsibility

Name of the QA member Sr. QA Engineer - Test planning

- Test designing

- Test execution
- Status updates to
project team
- Client calls and status
update
- QA sign off

Entry Criteria and Exit Criteria:

Entry Criteria
a. Unit testing has been completed by developer and artefacts are provided
via email.
b. Controlled environment (Staging/ QA) for testing to be made available to
the testing team when the testing starts.
c. Test cases are available for the scope of the sprint.
d. Test data are available.
e. Test environment is upgraded with latest build, its accessible, up and
running.

Exit Criteria

1
2
 Test Plan OrangeHRM
a. All identified end-to-end functional test cases are executed with Pass/fail
result.
b. The status of all valid defects reported are “Closed” or “Deferred”.
c. All identified defects are retested, and associated test cases are re-
executed.
d. Required Regression is performed.

Test environment:
QA Environment - The base activity and responsibility of this infrastructure will
be driven by the development and QA team. The objective of this infrastructure will be
to provide an environment to the teams for testing the functionality prior to the
verification level. Here the bugs or threats encountered in the next levels need to be
reproduced so to pass processed information to the development centers.

1
3
 Test Plan OrangeHRM

Test Deliverables:
Listed below are the deliverables to be created and will be provided in form of
excel/word/PDF/email format.

Test Strategy/Test Plan- This document

Test Cases - Test cases will be created in Excel and deployed in Team drive.
Test Summary Report- Email will be sent to all stakeholders after completion
of execution.
QA Sign-off- Email will be sent at release time.
Defect Management - When defects will be identified, they will be logged and
tracked in JIRA Bug Tracking Tool. Appropriate Priority and Severity will be
assigned to each defects

Defect Management:

Refer standard defect/ bug tracking process diagram as given below.

1
4
Test Plan OrangeHRM

1
5
 Test Plan OrangeHRM

Note: Status and workflow can be changed which has been decided for JIRA as
mentioned below.

Status Description

To Do Work on the issue has not yet started, or issue has been
reopened

In Progress Work on the issue is ongoing

In Review Initial work is completed and waiting for peer review

In Testing Issue is ready for testing or being tested

Ready Work on the issue is completed and awaiting PO approval

Done Work on the issue is complete and has been accepted by the
PO

Reopened Issue was previously worked on but needs changes

Risk, Assumptions, Dependencies:

Test environment will be in total control of QA and will be available fulltime

during testing phase.
QA need to explore the system properly for effective testing.

1
6
 Test Plan OrangeHRM
QA will test only given build with given version, He will not accept another
build mean while testing.
No one should deploy anything in QA environment on un-awareness of QA.
May be backend API will not be working properly or not giving response
within time.
While sending the Faxes from external system may be system taking time
while processing faxes.

1
7