1. Create a test plan document for any application (e.g. Hotel Management System).

REQUIREMENTS:

SOFTWARE: MS-Word
HARDWARE: Windows XP/7

THEORY: Hotel management has been considered many times by students/developers for
bringing out a typical application. One such application is utilised for the needed purpose here.

Test documentation:
Test documentation is documentation of artifacts created before or during the testing of software.
It helps the testing team to estimate testing effort needed, test coverage, resource tracking,
execution progress, etc. It is a complete suite of documents that allows you to describe and
document test planning, test design, test execution, test results that are drawn from the testing
activity.

Advantages for Text documentation:

 The main reason behind creating test documentation is to either reduce or remove any
uncertainties about the testing activities. Helps you to remove ambiguity which often
arises when it comes to the allocation of tasks
 Documentation not only offers a systematic approach to software testing, but it also acts
as training material to fresher in the software testing process
 It is also a good marketing & sales strategy to showcase Test Documentation to exhibit a
mature testing process
 Test documentation helps you to offer a quality product to the client within specific time
limits
 In Software Engineering, Test Documentation also helps to configure or set-up the
program through the configuration document and operator manuals
 Test documentation helps you to improve transparency with the client

DESIGN: The test plan for the above said application is provided below. Designing and
developing a test plan is important for any testing team – all the tests are dependent on the plan.
Such a plan has been designed and is being presented below.

HOTEL MANAGEMENT SYSTEM

 Version 1.0

19/12/2019
VERSION HISTORY

ID Prepared Revision Approv Approval Reason

&Vers By Date ed Date
ion By
#
1.0 Ch.Sharmila 19/12/2019 JNTUK 27/12/2019 draft
Sri
 TABLE OF CONTENTS
1 INTRODUCTION.....................................................................................................................4
1.1 Purpose of The Test Plan Document..........................................................................4
2 TEST ITEM.................................................................................................................................
2.1 Project description......................................................................................................4
2.3 Items to be excluded...................................................................................................5
2.4 Test Approach(s)........................................................................................................5
2.5 Test Pass / Fail Criteria..............................................................................................5
2.6 Test Entry / Exit Criteria............................................................................................7
2.7 Test Deliverables........................................................................................................9
2.8 Test Suspension / Resumption Criteria......................................................................9
2.9 Staffing / Training Needs...........................................................................................9
3 RISK AND MITIGATION........................................................................................................
3.1 Test Risks / Issues....................................................................................................10
4 TEST ENVIRONMENT AND INFRASTRUCTURE........................................................10
4.1 Required Infrastructure............................................................................................10
4.2 Availability Plan.......................................................................................................10
5 ROLES AND RESPONSIBILITIES.....................................................................................10
5.1 Roles and assigned responsibilities..........................................................................10
6 TEST SCHEDULE.................................................................................................................10
6.1 Milestones and schedule..........................................................................................11
TEST PLAN APPROVAL..............................................................................................................
APPENDIX A: REFERENCES..................................................................................................12
APPENDIX B: KEY TERMS.....................................................................................................12
 1. INTRODUCTION:
1.1 PURPOSE OF THE DOCUMENT
HMS 1.0–Hotel Management System (version 1.0)is software used to manage the catalog of
a hotel. This helps to keep the records of whole transactions. Ample trails provide hotel
management system which is very easy to use and fulfills all the requirements of a hotel
manager.
This test plan is a basic guideline for future testing in the HMS. It mainly focuses on two
problems what we will test.

2.TEST ITEM:

2.1 PROJECT DESCRIPTION

HMS 1.0–Hotel Management System would provide basic set of features to add/update
clients, add/update rooms, search for rooms, and manage check-in / checkout processes.
2.2 ITEMS TO BE TESTED

Item to Test Test Description Test Date Responsibility

Basic Function Test Refundable/Non-refundable rooms 30/12/2019 All the basic inputs are tested
booking: and if they matched the data
then they are successful
Customer register

Search for room

Check in/out rooms

Update details

Pay fine

Pay net amount

Data Base Test Basic operations: 02/01/2020 All the basic operations of the
data base are performed in
Add/update/search for rooms
successful manner
Advanced operations:

Start/stop/backup/recover the
 database

GUI Test 04/01/2020 The GUI provided should be

System should provide a GUI for
user-friendly and interactive.
receptionists to interface with the
backend hotel database.

2.3 ITEMS NOT TO BE TESTED:

PERFORMANCE TESTING
STRESS TESTING
SYSTEM TESTING
SMOKE TESTING
ITERATION/REGRESSION TESTING
2.5 TEST PASS / FAIL CRITERIA

TEST CRITERIA
GUI TEST Pass criteria: Receptionists could use this
GUI to interface with the backend hotel
database without any difficulties
 DATABASE TEST
BASIC FUNCTION TEST
1. REFUNDABLE/NON-REFUNDABLE 1. Each Customer can room any of the above
provided type of rooms as per his/her desire
BOOKING:
after successful registration.
2. REGISTERING A CUSTOMER
3. SEARCH FOR ROOM:
4. CHECK IN ROOM:
5. CHECK OUT ROOM:
6. UPDATE/ DELETE ROOM:
7. PAY FINE:
8. PAY NET AMOUNT
PASS CRITERIA: Results of all
basic and advanced operations are
normal.
2. Each new Customer is given a
unique id when they provide their
details like name, address and phone
number.
3. The receptionist searches for a room
requested by Customer in the database
with the roomId. The result displays
the number of the rooms of the desired
type available and if there is
availability then the room is reserved
by adding the details of the room into
the Customer’s record.
4.a) Receptionist searches for rooms which
are not already allocated.
b) Receptionist does the check-in with the
room number and updates the customer
details.
5.a)Furniture damages made are checked and
fine is imposed if any.
6a) The room can be retrieved using room
number.
b) The room can be made available if no one
has booked it.
c) The updated values are reflected if same
room number is used.
7. Furniture damages made are checked and
fine is imposed if any.
 8.The net amount is calculated and the bill is
issued to the customer

2.6 TEST ENTRY / EXIT CRITERIA

Test Entry Criteria Exit Criteria

Unit Testing • Development of • All test cases
the software completed
interface is successfully.
completed • No outstanding
• Specifications for critical defects.
productare complete • All test results
and approved have been
• All test cases are documented.
documented.

System Testing • Unit testing has • All test cases

been completed completed
successfully
• Development has
been completed on • All defect
the entire product recorded in test
director
•Specifications for
the product/app • No outstanding
have been critical defects
completed and • All test results
approved have been
• All test cases are documented
documented • All code has been
migrated into the
model environment
System • Unit and system
Integration testing has been
Testing completed and
signed-off
 • All code and
applications are
present in the model
environment.
• Sit test plan is
approved
• All test cases have
been documented
and approved

User Acceptance • The application

testing works functionally
as defined in the
specifications
• No high category
defects outstanding
• All areas have had
testing started on
them unless pre
agreed by uat
manager/test
principal, sit
manager and project
managers
• Entire system
functioning and all
new components
available unless
previously agreed
between uat
manager/test
principal, site
manager and project
managers
• All test cases are
documented and
reviewed prior to
the commencement
of uat.
2.7 TEST DELIVERABLES
Test plan.
Test summary report.
Test Case log file.
Bug Reports
Test Strategy
Test Metrics
2.8 TEST SUSPENSION / RESUMPTION CRITERIA
Testing will be suspended on the affected software module test case bugs are
discovered.

A bug report should be filed by Development team. After fixing the bug, Development team will
follow the drop criteria (described above) to provide its latest drop for additional Testing. At
that time, adopters will regress the bug, and if passes, continue testing the module.

2.9 STAFFING / TRAINING NEEDS

Performance Training
Stress Training
System Training
Unit Training
Smoke Training
Iteration Training
3. RISK AND MITIGATION
3.1 TEST RISKS / ISSUES
 It might be possible that the data stored get lost due to damage of hard disk
 Fewer people than necessary are available (Or) People with specific skills required are
not available.
 The under-estimation of schedule also happens due to inexperience or optimism
 Development risk- availability and quality of the tool used to make the project.
 Data Communication issue- communication gap between members of team.

4. TEST ENVIRONMENT AND INFRASTRUCTURE

4.1 REQUIRED INFRASTRUCTURE
Hardware: Machines with configuration i3 or above.
Software: Windows 7/8/10
4.2 AVAILABILITY PLAN
 Change history of 6 months
 Performance Of available software on Different platforms
 Improvement schedule (for performance)
5. ROLES AND RESPONSIBILITIES
5.1 ROLES AND ASSIGNED RESPONSIBILITIES

Role Responsibility

Project manager Overall management and initiation

responsibility

Tester Designs the different scenarios for

unit testing of the prototype
designed.

6. TEST SCHEDULE
6.1 MILESTONES AND SCHEDULE

Milestone Deliverable Effort(Person Start Date End Date

Hour)

Completion of Test cases Senior tester-4 06/01/2020 09/01/2020

testing of
prototype days

Junior tester-5
 days

Managing all Development Project manager 10/01/2020 13/01/2020

the process
development (time can’t be
process estimated)

1. TEST PLAN APPROVAL

The undersigned acknowledge they have reviewed the . document and agree with the
approach it presents. Any changes to this Requirements Definition will be coordinated with and
approved by the undersigned or their designated representatives.

Signature: Akshita Date: 14/01/2020

Print Name: D.AKSHITA

Title:

Role: Team LEAD

Signature: Ch adi lakshmi Date: 14/01/2020

Print Name: CH.ADI LAKSHMI

Title:

Role:

Team Member

Signature: Sharmila Date: 14/01/2020

Print Name: CH.SHARMILA SRI

Title:

Role: Tester

2. Appendix A: References
 The following table summarizes the documents referenced in this document.
Document Description Location
Name and
Version
Test plan 1 The document is used for D:\522_stl
testing various cases which
Version 1.0
arise in the management of
hotel system

3. Appendix B: Key Terms And Acronyms

The following table provides definitions for terms relevant to this document.
Term Definition
QA QUALITY ASSURANCE

Availability Key indicator of service provided

*****End of experiment 5*****