Click “Save” once all the fields are entered and the particular license will be listed as shown

in Figure 3.2

You may enter multiple entries of licenses.

To delete an entry, click on the check box next to particular entry. It is also possible to delete
multiple entries at the same time by clicking the check box entries you wish to delete and simply
clicking “Delete”.
●Attachments
Any supporting documents regarding your qualification that you think is needed by the management can be
attached here. Please note that each document cannot exceed 1 megabyte, but you can attach more than on
document. To add an attachment, click “Add” under attachment and the screen as shown in Figure 3.3 will
appear.

Click “Browse” and select the file from the relevant path and click “Upload” to upload it.

[Prepared By: Kamal Subramani] Page 50

Once you have uploaded the file, the file will be listed as shown in Figure 3.4

You may upload multiple attachments.

To delete an entry click on the check box next to the particular entry and click “Delete”.
Multiple selections can be deleted simultaneously.
3.1.11 Membership
If you are a members of any committee, institute etc. those details can be entered here. To enter
membership details, go to My Info>>Personal>>Membership and click “Add” and the screen as
shown in Figure 3.5 will appear.

[Prepared By: Kamal Subramani] Page 51

Click “Save” once all the fields are entered and the particular membership detail will be
listed as shown in Figure 3.6.

You may enter multiple entries of memberships.

To delete an entry, click on the check box next to particular entry. It is also possible to
delete multiple entries at the same time by clicking the check box entries you wish to
delete and simply clicking “Delete”.
You may also upload any attachment that would support the details you have entered on
the form by clicking “Add” under the “Attachment” and selecting a file from a relevant path
and upload the following file by clicking “Upload”.

4. Site Design
4.1 Aesthetic/HTML Requirements and Guidelines
OrageHRM must deliver a compelling visitor experience. However, it cannot sacrifice
usability and accessibility.
The web site ‘look’ must conform to the following requirements:
• The site should be HTML 4.0 compliant.
• All pages must download in less than 10 seconds over a 56k modem connection.-
Perfomrance req
• All pages must fit in a web browser displayed on a computer set to 640 x 480 pixels.
• All pages must use a web safe color palette.
• The site must be compatible with Internet Explorer 4, 5 and 5.5, and with Firefox
4-6, as well as Google Chrome 4.0 and later.
• The site must conform to the WAI Accessibility
Guidelines outlined at http://www.w3.org/TR/WAI-
WEBCONTENT/ , wherever possible.
• All site pages should be available for search engine robots.
• All pages that use static images should be displayed correctly.

5. Sign-Off Document
The following parties have read and agree with this Requirements Definition
document for the OrangeHRM application account module functionality.
After approval of this Requirements Definition phase, any significant changes in the scope
of this project will require validation of existing project costs and schedules.
_____________________________________ __________________________________________
Name Date
Business Lead
_____________________________________ __________________________________________

[Prepared By: Kamal Subramani] Page 52

 Name Date
Project Manager

TEST
PLAN

By

[Prepared By: Kamal Subramani] Page 53

 © www.Payilagam.com

Note: This is a sample test plan created on real time software testing live project – for training
conducted by www.Payilagam.com on following page:
Live Project Training - OrangeHRM
Test Plan (a Real Sample)

Version: 1.0
Created: 02/05/2014
Last Updated: 02/05/2014

Revision and Signoff Sheet

Status: DRAFT (The status would change to finalized post the BA, PM and dev team review and sign off)

Document History - To maintain a list of changes being made

Version Date Author Description of Change

1 02/14/2014 Kamal Subramani Draft

2 02/14/2014 Siva Subramani Draft - Reviewed

Approvers List - To track who has reviewed and signoff on the Test plan

Approver / Approval /
Name Role
Reviewer Review Date

[Prepared By: Kamal Subramani] Page 54

 Version Date Document Name
Reference Documents - Clearly mark the document used as an input to create the test plan

ORANGEHRM VERSION 3.0 – MY INFO MODULE -

1.0 FSD

FUNCTIONAL TESTING SCOPE

Negative Test Expecting Additional Test
User Scenarios Sub Levels Complexity No. of Test cases Cases
Cases
Employee Login Page Login Medium 1 1
Employee My information Add info Complex 10 1 1
Delete info Complex 10 1
Verify the info display Medium 5
Employee Photograph Add photograph Complex 5 1 1
Replace Complex 5 1
Verify photograph Medium 3
Employee Aesthetics HTML requirements Medium 1
Performance Complex 3
Accessibility Complex 10
Image display Medium 10

[Prepared By: Kamal Subramani] Page 55

 DFRT EXECUTION CYCLE
Functional Start Date End Date Available time
Test Execution Monday, March 10, 2014 Tuesday, March 25, 2014

First navigation, Employee module(Cycle 1) Monday, March 10, 2014 Friday, March 14, 2014
Development team 1 Day Monday, March 17, 2014 Monday, March 17, 2014 (12 working days)
Retest Tuesday, March 18, 2014 Tuesday, March 18, 2014
First navigation, Employee (Cycle 2) Wednesday, March 19, 2014 Friday, March 21, 2014
Development team 1 Day Monday, March 24, 2014 Monday, March 24, 2014
Retest Tuesday, March 25, 2014 Tuesday, March 25, 2014

[Prepared By: Kamal Subramani] Page 56

1. INTRODUCTION
1.1. Purpose
This test plan describes the testing approach and overall framework that will drive the testing
of the
OrangeHRM Version 3.0 – My Info Module.com site. The document introduces:
• Test Strategy: rules the test will be based on, including the givens of the project (e.g.: start
/ end
dates, objectives, assumptions); description of the process to set up a valid test (e.g.: entry
/ exit criteria, creation of test cases, specific tasks to perform, scheduling, data strategy).
• Execution Strategy: describes how the test will be performed and process to identify and
report defects, and to fix and implement fixes.
• Test Management: process to handle the logistics of the test and all the events that come
up during
execution (e.g.: communications, escalation procedures, risk and mitigation, team roster)
1.2. Project Overview
My Info Module is a powerful tool providing employees of the company with the ability to view
relevant information such as personal information and updating personal information with an
internet enabled PC without having to involve the HR department.
The functionality of this module spans through the entire system, making information
available anywhere, anytime. All information is subject to company’s defined security policy,
where he/she can only view the information he/she is authorized to. An ESS-User can only edit
certain fields in the ESS Module, maintaining the security and confidentiality of employee
information
1.3. Audience
• Project team members perform tasks specified in this document, and provide input and
recommendations on this document.
• Project Manager Plans for the testing activities in the overall project schedule, reviews the
document, tracks the performance of the test according to the task herein specified,
approves the document and is accountable for the results.
• The stakeholders’ representatives and participants (individuals as identified by the PMO
Leads) may take part in the UAT test to ensure the business is aligned with the results of
the test.
• Technical Team ensures that the test plan and deliverables are in line with the design,
provides the environment for testing and follows the procedures related to the fixes of
defects.
• Business analysts will provide their inputs on functional changes.
2. TEST STRATEGY
2.1. Test Objectives
The objective of the test is to verify that the functionality of ORANGEHRM VERSION 3.0 – MY
INFO MODULE works according to the specifications.
The test will execute and verify the test scripts, identify, fix and retest all high and medium
severity defects per the entrance criteria, prioritize lower severity defects for future fixing via CR.
The final product of the test is twofold:
• A production-ready software;
• A set of stable test scripts that can be reused for Functional and UAT test execution.

[Prepared By: Kamal Subramani] Page 57

2.2. Test Assumptions
Key Assumptions
• Production like data required and be available in the system prior to start of Functional
Testing
• In each testing phase, Cycle 3 will be initiated if the defect rate is high in Cycle 2.
General
• Exploratory Testing would be carried out once the build is ready for testing
• Performance testing is not considered for this estimation.
• All the defects would come along with a snapshot JPEG format
• The Test Team will be provided with access to Test environment via VPN connectivity
• The Test Team assumes all necessary inputs required during Test design and execution will be
supported by Development/BUSINESS ANALYSTs appropriately.
• Test case design activities will be performed by QA Group
• Test environment and preparation activities will be owned by Dev Team
• Dev team will provide Defect fix plans based on the Defect meetings during each cycle to plan.
The same will be informed to Test team prior to start of Defect fix cycles
• BUSINESS ANALYST will review and sign-off all Test cases prepared by Test Team prior to
start of Test execution
• The defects will be tracked through HP ALM only. Any defect fixes planned will be shared with
Test Team prior to applying the fixes on the Test environment
• Project Manager/BUSINESS ANALYST will review and sign-off all test deliverables
• The project will provide test planning, test design and test execution support
• Test team will manage the testing effort with close coordination with Project PM/BUSINESS
ANALYST
• Project team has the knowledge and experience necessary, or has received adequate training
in the system, the project and the testing processes.
• There is no environment downtime during test due to outages or defect fixes.
• The system will be treated as a black box; if the information shows correctly online and in the
reports, it will be assumed that the database is working properly.
• Cycle 3 will be initiated if there are more defects in Cycle 2.
Functional Testing
• During Functional testing, testing team will use preloaded data which is available on the
system at the time of execution
• The Test Team will be perform Functional testing only on ORANGEHRM VERSION 3.0 – MY
INFO MODULE
UAT
• UAT test execution will be performed by end users (L1, L2 and L3) and QA Group will provide
their support on creating UAT script.
2.3. Test Principles
• Testing will be focused on meeting the business objectives, cost efficiency, and quality.
• There will be common, consistent procedures for all teams supporting testing activities.
• Testing processes will be well defined, yet flexible, with the ability to change as needed.
• Testing activities will build upon previous stages to avoid redundancy or duplication of effort.
• Testing environment and data will emulate a production environment as much as possible.
• Testing will be a repeatable, quantifiable, and measurable activity.
• Testing will be divided into distinct phases, each with clearly defined objectives and goals.
• There will be entrance and exit criteria.
2.4. Data Approach
• In functional testing, ORANGEHRM VERSION 3.0 – MY INFO MODULE will contain pre-loaded test
data and which is used for testing activities.

[Prepared By: Kamal Subramani] Page 58

2.5. Scope and Levels of Testing
2.5.1. Exploratory
PURPOSE: the purpose of this test is to make sure critical defects are removed before the
next levels of testing can start.
SCOPE: First level navigation, dealer and admin modules
TESTERS: Testing team.
METHOD: this exploratory testing is carried out in the application without any test scripts
and documentation
TIMING: at the beginning of each cycle.
2.5.2. 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
1. Approved Functional Specification document, Use case documents must be available
prior to start of Test design phase.
2. Test cases approved and signed-off prior to start of Test execution
3. Development completed, unit tested with pass status and results shared to Testing
team to avoid duplicate defects
4. Test environment with application installed, configured and ready to use state

Sign-off Readiness

•Approved Functional Specification •Development completed & unit tested

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

[Prepared By: Kamal Subramani] Page 59

 TEST DELIVERABLES
S.No. Deliverable Name Author Reviewer
1. Test Plan Test Lead Project Manager/ Business
Analyst’s
2. Functional Test Cases Test Team Business Analyst’s Sign off
3. Logging Defects in HP ALM Test Team Test Lead/ Programming
Lead(Vijay)
Test Team/ Test
(4. Daily/weekly status report Lead Test Lead/ Project Manager
5. Test Closure report Test Lead Project Manager

MILESTONE LIST
The milestone list is tentative and may change due to below reasons
a) Any issues in the System environment readiness
b) Any change in scope/addition in scope
c) Any other dependency that impacts efforts and timelines
Testing generally is not carried out in one cycle. Based on the testing scope, we can
estimate how much time it takes and establish the time lines as you can see in the below embedded excel sheet.

DFRT Execution
Cycle.xlsx
2.5.3. 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
S.No. Deliverable Name Author Reviewer
1. UAT Test Cases Test Team Business Analyst’s
Sign off

2.6. 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.

New_Detailed DRFT

3. Test estimate v1.xlsx

Note: this estimate is for the TCOE team only Testing Schedule
4. 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.

[Prepared By: Kamal Subramani] Page 60

 • 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.
Technic
Test al
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
All expected and actual results are captured and
documented with the test script
All test metrics collected based on reports from HP
ALM
All defects logged in HP ALM

Test Closure Memo completed and signed off

Test environment cleanup completed and a new
back up of the environment

4.2. Test Cycles

 There will be two cycles for functional testing. Each cycle will execute all the scripts .
 The objective of the first cycle is to identify any blocking, critical defects, and most of
the high defects. It is expected to use some work-around in order to get to all the
scripts.
 The objective of the second cycle is to identify remaining high and medium defects,
remove the work-around from the first cycle, correct gaps in the scripts and obtain
performance results.
• UAT test will consist of one cycle.
4.3. Validation and Defect Management
• It is expected that the testers execute all the scripts in each of the cycles described above. However it
is recognized that the testers could also do additional testing if they identify a possible gap in the
scripts. This is especially relevant in the second cycle, when the Business analyst’s join the TCOE in

[Prepared By: Kamal Subramani] Page 61

 the execution of the test, since the BUSINESS ANALYSTs have a deeper knowledge of the business
processes. If a gap is identified, the scripts and traceability matrix will be updated and then a defect
logged against the scripts.
• The defects will be tracked through HP ALM only. The technical team will gather information on a
daily basis from HP ALM, and request additional details from the Defect Coordinator. The technical
team will work on fixes.
• It is the responsibility of the tester to open the defects, link them to the corresponding script, assign
an initial severity and status, retest and close the defect; it is the responsibility of the Defect Manager
to review the severity of the defects and facilitate with the technical team the fix and its
implementation, communicate with testers when the test can continue or should be halt, request the
tester to retest, and modify status as the defect progresses through the cycle; it is the responsibility of
the technical team to review HP ALM on a daily basis, ask for details if necessary, fix the defect,
communicate to the Defect Manager the fix is done, implement the solution per the Defect Manager
request.
Defects found during the Testing will be categorized according to the bug-reporting tool “Mercury HP
ALM” and the categories are:
Severity Impact
1 (Critical)  This bug is critical enough to crash the system, cause file corruption, or
cause potential data loss
 It causes an abnormal return to the operating system (crash or a
system failure message appears).
 It causes the application to hang and requires re-booting the system.
2 (High)  It causes a lack of vital program functionality with workaround.
3 (Medium)  This Bug will degrade the quality of the System. However there is an
intelligent workaround for achieving the desired functionality - for
example through another screen.
 This bug prevents other areas of the product from being tested.
However other areas can be independently tested.
4 (Low)  There is an insufficient or unclear error message, which has minimum
impact on product use.
5(Cosmetic)  There is an insufficient or unclear error message that has no impact on
product use.
4.4. 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

[Prepared By: Kamal Subramani] Page 62

 Report Description Frequency

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

preparatio
n (optional)
& Defects severity wise Status – Open, closed, any other
Execution Status
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
with project team to
use.

4.5. Defect tracking & Reporting

Following flowchart depicts Defect Tracking Process:

[Prepared By: Kamal Subramani] Page 63

5. TEST MANAGEMENT PROCESS
5.1. Test Management Tool
HP Application Lifecycle Management is the tool used for Test Management. All testing artifacts
such as Test cases, test results are updated in the HP Application Lifecycle Management (ALM)
tool.
• Project specific folder structure will be created in HP ALM to manage the status of this
DFRT project.
• Each resource in the Testing team will be provided with Read/Write access to
add/modify Test cases in HP ALM.
• During the Test Design phase, all test cases are written directly into HP ALM. Any change
to the test case will be directly updated in the HP ALM.
• Each Tester will directly access their respective assigned test cases and update the status of
each executed step in HP ALM directly.
• Any defect encountered will be raised in HP ALM linking to the particular Test case/test step.
• During Defect fix testing, defects are re-assigned back to the tester to verify the defect fix.
The tester verifies the defect fix and updates the status directly in HP ALM.
• Various reports can be generated from HP ALM to provide status of Test execution. For
example, Status report of Test cases executed, Passed, Failed, No. of open defects, Severity
wise defects etc.

[Prepared By: Kamal Subramani] Page 64

5.2. Test Design Proces

Establishing Incorporating
SME /Peer
Understanding Traceability Preparation of Review
Review of Test
Requirements Matrix in HP Test cases comments in
cases
ALM test cases

• The tester will understand each requirement and prepare corresponding test case to
ensure all requirements are covered.
• Each Test case will be mapped to Use cases to Requirements as part of Traceability
matrix.
• Each of the Test cases will undergo review by the BUSINESS ANALYST and the review
defects are captured and shared to the Test team. The testers will rework on the review
defects and finally obtain approval and sign-off.
• During the preparation phase, tester will use the prototype, use case and
functional specification to write step by step test cases.
• Testers will maintain a clarification Tracker sheet and same will be shared periodically
with the Requirements team and accordingly the test case will be updated. The
clarifications may sometimes lead to Change Requests or not in scope or detailing
implicit requirements.
• Sign-off for the test cases would be communicates through mail by Business Analyst’s.
• Any subsequent changes to the test case if any will be directly updated in HP ALM.
5.3. Test Execution Process
Participate in

each of Mark Status as Raise defects for Send the daily Complete the
Defect Triage
the test step in Pass/Fail in HP the failed test status report to test execution of
cycle and explain
test case ALM cases in HP ALM Test Lead all the test cases
the defects

• Once all Test cases are approved and the test environment is ready for testing, tester will
start a exploratory test of the application to ensure the application is stable for testing.
• Each Tester is assigned Test cases directly in HP ALM.
• Testers to ensure necessary access to the testing environment, HP ALM for updating
test status and raise defects. If any issues, will be escalated to the Test Lead and in
turn to the Project Manager as escalation.
• If any showstopper during exploratory testing will be escalated to the
respective development SPOCs for fixes.

[Prepared By: Kamal Subramani] Page 65

 • Each tester performs step by step execution and updates the executions status. The
tester enters Pass or Fail Status for each of the step directly in HP ALM.
• Tester will prepare a Run chart with day-wise execution details
• If any failures, defect will be raised as per severity guidelines in HP ALM tool detailing
steps to simulate along with screenshots if appropriate.
• Daily Test execution status as well as Defect status will be reported to all stakeholders.
• Testing team will participate in defect triage meetings in order to ensure all test
cases are executed with either pass/fail category.
• If there are any defects that are not part of steps but could be outside the test steps,
such defects need to be captured in HP ALM and map it against the test case level or
at the specific step that issue was encountered after confirming with Test Lead.
• This process is repeated until all test cases are executed fully with Pass/Fail status.
• During the subsequent cycle, any defects fixed applied will be tested and results
will be updated in HP ALM during the cycle.
As per Process, final sign-off or project completion process will be followed
5.4. Test Risks and Mitigation Factors

Risk Prob. Impact Mitigation Plan

SCHEDULE • The testing team can control the

Testing schedule is tight. If the start preparation tasks (in advance)
of the testing is delayed due to and the early communication
design tasks, the test cannot be with involved parties.
High High
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 Low Medium Teams and responsibilities have

[Prepared By: Kamal Subramani] Page 66

 Risk Prob. Impact Mitigation Plan

been spread to two different

geographic areas. In a catastrophic
event in one of the areas, there will
resources in the other areas needed
to continue (although at a slower
pace) the testing activities.
Non-availability of Independent
Test Due to non availability of the
environment and accessibility environment, the schedule gets
Medium High
impacted and will lead to delayed
start of Test execution.
Delayed Testing Due To new Issues During testing, there is a good
chance that some “new” defects
may be identified and may become
an issue that will take time to
resolve.
There are defects that can be raised
during testing because of unclear
document specification. These
defects can yield to an issue that
will
Medium High
need time to be resolved.
If these issues become
showstoppers, it will greatly impact
on the overall project schedule.
If new defects are discovered, the
defect management and issue
management procedures are in
place to immediately provide a
resolution.

5.1. Communications Plan and Team Roster

5.2. Role Expectations
The following list defines in general terms the expectations related to the roles directly involved in
the management, planning or execution of the test for the project.
Roles Name Contact Info

1. Project Manager

2. Test Lead

3. Business Analyst
4. Development Lead

[Prepared By: Kamal Subramani] Page 67

 Roles Name Contact Info

5. Testing Team

6. Development Team
7. Technical Lead

5.2.1. Project Management

• Project Manager: reviews the content of the Test Plan, Test Strategy and Test Estimates signs off
on it.
5.2.2. Test Planning (Test Lead)
• Ensure entrance criteria are used as input before start the execution.
• Develop test plan and the guidelines to create test conditions, test cases, expected results and
execution scripts.
• Provide guidelines on how to manage defects.
• Attend status meetings in person or via the conference call line.
• Communicate to the test team any changes that need to be made to the test deliverables or
application and when they will be completed.
• Provide on premise or telecommute support.
• Provide functional (Business Analysts) and technical team to test team personnel (if needed).
5.2.3. Test Team
• Develop test conditions, test cases, expected results, and execution scripts.
• Perform execution and validation.
• Identify, document and prioritize defects according to the guidance provided by the Test lead.
• Re-test after software modifications have been made according to the schedule.
• Prepare testing metrics and provide regular status.
5.2.4. Test Lead
• Acknowledge the completion of a section within a cycle.
• Give the OK to start next level of testing.
• Facilitate defect communications between testing team and technical / development team.
5.2.5. Development Team
• Review testing deliverables (test plan, cases, scripts, expected results, etc.) and provide timely
feedback.
• Assist in the validation of results (if requested).
• Support the development and testing processes being used to support the project.
• Certify correct components have been delivered to the test environment at the points
specified in the testing schedule.
• Keep project team and leadership informed of potential software delivery date slips
based on the current schedule.
• Define processes/tools to facilitate the initial and ongoing migration of components.
• Conduct first line investigation into execution discrepancies and assist test executors in
creation of accurate defects.
• Implement fixes to defects according to schedule.

[Prepared By: Kamal Subramani] Page 68

6. TEST ENVIRONMENT
ORANGEHRM VERSION 3.0 – MY INFO MODULE’s servers will be hosted at X company’s site. RANGEHRM
VERSION 3.0 – MY INFO MODULE will be hosted on two servers: One to host the actual website and (language)
code, and the other to host the (database name) database.
A windows environment with Internet Explorer 8, 9 and 10, and with Firefox 27.0, as well as Google Chrome
32.0 and later should be available to each tester.

7. APPROVALS
The Names and Titles of all persons who must approve this plan.

Signature:

Name:
Role:
Date:

Signature:

Name:
Role:
Date:

[Prepared By: Kamal Subramani] Page 69

 TEST
SCENARIO

By

Kamal Subramani

[Prepared By: Kamal Subramani] Page 70