Group 4 STS final version

2014
Vinny Khao, Stephen Gubenia, Shaun
Williams
Developed for CMIS 330 Dr. Almarzooq
11/29/2014
Software Test Specification
(STS) for John and Joan Bed &
Breakfast

1
Table of Contents
1. Introduction ................................................................................................................................ 3
1.1 Objectives............................................................................................................................... 3
1.2 Background............................................................................................................................ 3
1.3 Scope...................................................................................................................................... 3
1.4 References.............................................................................................................................. 3
1.5 Test Environment .................................................................................................................. 3
1.5.1 Software........................................................................................................................... 4
1.5.2 Hardware ........................................................................................................................ 4
1.5.3 Communications............................................................................................................. 4
1.5.4 Tools................................................................................................................................ 4
1.5.5 Data ................................................................................................................................. 4
2. Architectural Context Diagram Mappings................................................................................. 6
2.1 User Interface......................................................................................................................... 6
2.2 Services.................................................................................................................................. 7
2.3 Domain Objects..................................................................................................................... 8
3. Traceability Matrix...................................................................................................................... 9
4. Test Case Specifications............................................................................................................ 11
4.1 User Interface Test Cases..................................................................................................... 11
4.1.1 Specification ID: BBRMS.UI.01...................................................................................... 11
4.1.2 Specification ID: BBRMS-UI-02..................................................................................... 13
4.2 Service Test Cases................................................................................................................ 25
4.2.1 Specification ID: BBRMS-SV-01..................................................................................... 25

2
4.3 Domain Object Test Cases................................................................................................... 37
4.3.1 Specification ID: BBRMS-DO-01 ................................................................................... 37

3
1. Introduction
1.1 Objectives
The purpose of this document is to outline the framework of testing strategies for the three
functional levels of the Bed & Breakfast Reservation Management System (BBRMS). The
framework will provide the testing team with the ability to perform black-box algorithmic
(white-box) and component requirements (black-box) tests against the software to validate both
requirements and design.
1.2 Background
The BBRMS will be used by the management and staff of small bed & breakfast (B&B)
establishment to process guest reservations, store guest information, and assist in the financial
management of the business. The software is designed to automate many of the business
processes thus increasing efficiency and driving revenue. This document should be used to
validate and verify the software to ensure the delivery of a quality product to our customer.
1.3 Scope
This document encompasses the test cases specific for the three architectural modules of the
system:
1. User Interface – Section 2.1
2. Services – Section 2.2
3. Domain Objects – Section 2.3
Concepts such as data persistence and database configuration are not covered in this document.
1.4 References
References for the software test specification include:
1. IEEE Std. 829-1998 – IEEE Standard for Software Test Documentation
2. Software Requirements Specification (SRS) for BBRMS
3. Software Design Document (SDD) for BBRMS
4. IEEE Std. 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
5. IEEE Std. 730-1998,IEEE Standard for Software Quality Assurance Plans.
6. IEEE Std. 828-1998,IEEE Standard for Software Configuration ManagementPlans.
1.5 Test Environment
The BBRMS has limited requirements and interaction with other components, making the
testing environment relatively simple. The software is designed to run on a single
server/workstation so the hardware and software requirements are small. All that will be
required for the testing environment is a single commercial desktop with Windows OS, a single
monitor, keyboard, mouse, and printer.

4
1.5.1 Software
The BBRMS will run on a Windows operating system, thus the computer(s) used for testing
must be running Windows version 7 at the minimum. The BBRMS software should be also be
installed.
1.5.2 Hardware
A commercially available computer(s) should be used for the testing. The minimum
specifications required for the computer(s) is:
 Core Duo processor or above;
 4GB RAM or more;
 500MB hard disk drive (HDD) or solid state drive (SDD);
 Mouse (wired or wireless);
 Keyboard (wired or wireless);
 Display at 1280x1024 for optimal viewing of all GUIs during testing.
1.5.3 Communications
There are no external communications requirements as specified in section 2.1.1.4 of the SRS.
1.5.4 Tools
Testing of the BBRMS must consist of a usable computer environment as defined in sections
1.5.1 and 1.5.2. The API and domain object layers of the software are private and their access is
limited to testers, thus the primary method of testing will be through the BBRMS user interface.
Data entry into the database through the three modules should be tested by utilizing an SQL
tool, such as Oracle SQL Developer, MySQL Workbench or other equivalent RDBMS tool. The
tester will need full administrative rights to the testing database to be able to access both the
database and the fields which store the domain objects.
1.5.5 Data
Testers of the BBRMS will need to be provided with the following data in order to perform the
use cases outlined in section 4 of this document:
1. Date ranges to input into the calendar
a. Non-overlapping ranges to create successful reservations;
b. Overlapping ranges to generate unsuccessful reservations attempts.
2. Guest data
a. Names (first, last);
b. Addresses (street, city, state and zip code);
c. Credit card information (valid and invalid formats);
d. Phone numbers (valid and invalid formats);
e. Email.
3. Reservation data
a. Varying room rates (valid and invalid formats);
b. Guarantee dates for reservation.

5
4. Establishment Data
a. Set of room numbers to assign reservations and manage vacancies.
The data listed above will accommodate all of the test cases for the user interface, service, and
domain objects listed in this document.

6
2. Architectural Context Diagram Mappings
2.1 User Interface
This module is for the end users of the system, such as management and staff of B&B. The users
are able to interact with the system exclusively through this interface. The only external
interfaces needed to interact with this UI are the keyboard, mouse, and monitor. Figure 1 below
outlines the architectural context for this system.
Services
User Interface
Calendar Query
Room
Reservation
Make
Payement
Guest
Reservation
Guest
Information
Domain ObjectsStore Data
<<interacts>>
<<interacts>>
<<interacts>>
<<interacts>> <<interacts>>
<<interacts>>
<<interacts>>
<<manages>><<stores>
<<retrieves>>
Figure 1. Architectural Context Diagram – User Interface

7
2.2 Services
This module contains the business logic for the processes that the BBRMS needs to conduct in
which domain objects are involved, such as looking up a reservation date or saving a payment.
The service module provides output to the user interface, and manages the domain objects
through input from the user interface. The service module also manages persistence of the
domain objects to the database. Figure 2 below outlines the architectural context of this system.
Services
1.1 Room
Reservation
1.2
Calendar
Query
1.3 Make
Payment 1.4 Guest
Reservation
Store Data
2.0 User
Interface
3.0 Domain
Objects
1.5 Take
Guest
Information
1.6
Reservation
Query
Out: RoomNumber, In: isVacant
Out: startDate, endDate, in: Room In: Payment In: Reservation
<<delete>>
In: Guest
<<manages>>
<<store>>
<<retrieve>>
<<interacts>>
<<interacts>>
Figure 2. Architectural Context Diagram – Services

8
2.3 Domain Objects
Domain objects are entities that hold data about a particular function in the BBRMS system.
Figure 3 below outlines the architectural context of this system.
Services
Store Data
2.0 User
Interface
3.0 Domain
Objects
3.1 Guest
3.2 Finances
3.3 Payment
3.4 Room
3.5 Reservation
<<manages>>
<<store>>
<<retrieve>>
<<interacts>>
<<interacts>>
<<create>>
<<delete>>
<<edit>> <<create>>
<<delete>>
<<edit>>
<<create>>
<<delete>>
<<edit>>
<<create>>
<<delete>>
<<edit>>
<<create>>
<<delete>>
<<edit>>
Figure 3. Architectural Context Diagram – Domain Objects

9
3. Traceability Matrix
The traceability matrix provides a nexus between the initial software requirements (SRS),
software design (SDD), and use cases defined below, as well as accountability of the testing
framework for pass/fail completion of each test.
Category Description System
Req.
Use Case Software
Req.
Test Case Pass/Fail
User Interface Calendar Query 3.1.1.2 App. F,
Case 1,
S#1
5.1 4.1.1
User Interface Room
Reservation
3.1.1.3 App. F,
Case 2,
S#1
5.2 4.1.2
User Interface Guest
Reservation
3.1.1.3 App. F,
Case 2,
S#1
5.4 4.1.3
User Interface Guest
Information
3.1.1.3 App. F,
Case 2,
S#1
5.4 4.1.4
User Interface Make Payment 3.1.1.3 App. F,
Case 2,
S#2
5.3 4.1.5
User Interface Reservation
(Create with
guaranteedate)
3.1.1.3 App. F,
Case 2,
S#1
5.2 4.1.6
(Update)
3.1.1.3 N/A 5.2 4.1.7
(Delete)
3.1.1.3 N/A 5.2 4.1.8
Services assignReservation 3.2.2 N/A 6.1.1 4.2.1
Services takeGuestInfo 3.2.2 N/A 6.1.5 4.2.2
Services takeGuestInfo
(cancel)
3.2.2 N/A 6.1.5 4.2.3
Services makePayment 3.2.4 N/A 6.1.3 4.2.4
Services makePayment
(cancel)
3.2.4 N/A 6.1.3 4.2.5
Services createReservation 3.2.2 N/A 6.1.4 4.2.6
Services deleteReservation 3.2.2 N/A 6.1.4 4.2.7
Services createRoom 3.2.3 N/A 6.1.1 4.2.8
Services deleteRoom 3.2.3 N/A 6.1.1 4.2.9
Domain
Objects
ValidateGuest
(name)
3.2.1 App. F,
Case 2,
S#1
6.2.1 4.3.1

10
Domain
Objects
ValidateGuest
(Credit Card)
3.2.1 App. F,
Case 2,
S#1
6.2.1 4.3.2
Domain
Objects
InvalidateGuest
(name)
3.2.1 App. F,
Case 2,
S#2
6.2.1 4.3.3
Domain
Objects
InvalidateGuest
(Credit Card)
3.2.1 App. F,
Case 2,
S#2
6.2.1 4.3.4
Domain
Objects
Validate
Guarantee
3.2.3 App. F,
Case 2,
S#1
6.2.3 4.3.5

11
4. Test Case Specifications
Test cases are outlined for the three core modules (as defined in section 2 of this document) of
the BBRMS. These tests encompass the necessary steps to validate both white-box and black-
box components. These test case specifications are derived from the SRS and SDD documents
for the BBRMS.
4.1 User Interface Test Cases
These cases for the comprehensive testing of the BBRMS through the user interface (UI).
4.1.1 Specification ID: BBRMS.UI.01
Objective: To provide a black-box test for the Calendar portion of the UI defined in section 3.1.1
of the SRS.
Test Items: This test will simulate a user interacting with the Calendar, Room Vacancy Status
and Make Reservation functions in the CalendarQuery GUI.
Input Specifications
1. Click on “Calendar” option in the main menu;
2. Click on a day in the calendar view;
3. Click on the arrow on the top left corner of the calendar view;
4. Click on the arrow on the top right corner of the calendar view;
5. Click on the calendar icon on the bottom left side of the calendar GUI;
6. Enter 28 December 2014;
7. Click on the calendar icon on the bottom right side of the calendar GUI;
8. Enter 3 January 2015;
9. Click on 2 January 2015;
10. Click on each Room displayed in the panel on the top right corner of the GUI;
11. Click Make Reservation button.
Output Specifications
1. CalendarQuery GUI opens;
2. Calendar view highlights selected day, vacant rooms are displayed in upper right panel;
3. Calendar display changes to previous month;
4. Calendar displays changes back to current month;
5. Starting date calendar menu appears;
6. Calendar view starts with 28 December 2014, vacant rooms are displayed in the upper
right panel;
7. Ending date calendar menu appears
8. Calendar view ends with 3 January 2015, vacant rooms are displayed in the upper right
panel;
9. Calendar view highlights 2 January 2015, vacant rooms are displayed in the upper right
panel;

12
10. Room selected is highlighted in the panel;
11. Panel button reacts to action with graphical response and Room Reservation GUI is
displayed.
Environmental Needs
1. Commercial desktop computer with;
a. Core Duo processor or above;
b. 4GB RAM or more;
c. 500MB hard disk drive (HDD) or solid state drive (SDD);
d. Windows 7 OS installed;
e. BBRMS software installed.
2. Mouse (wired or wireless);
3. Keyboard (wired or wireless);
4. Display at 1280x1024 for optimal viewing of all GUIs during testing.
Special Procedural Requirements
BBRMS services will require manager's permissions starting in the CalendarQuery Entity.
Inter-case Dependencies
None

13
4.1.2 Specification ID: BBRMS-UI-02
Objective: To provide a black-box test for the RoomReservation portion of the UI defined in
section 3.1.1 of the SRS.
Test Items: This test will simulate a user interacting with the RoomReservation Entity to create
and update vacancy statuses.
1. Click Vacant checkbox;
2. Click Vacant checkbox again;
3. Click Vacant checkbox again;
4. Click Save Room
1. Checkmark disappears from the Vacant checkbox;
2. Checkmark appears in the Vacant checkbox;
3. Checkmark disappears from the Vacant checkbox;
4. Panel button reacts to action with graphical response, RoomReservation panel closes,
and CalendarQuery GUI is displayed.
Environmental Needs
b. 4GB RAM or more;
BBRMS services will require manager's permissions starting in the RoomReservation Entity.
BBRMS-UI-01 must be completed first in order for the BRBMS to initiate the reservation
workflow. The room number of the selected room from the BBRMS-UI-01 test case will
populate in the Room Number text box confirming vacancy assessment operated correctly.

14
Objective: To provide a black-box test for the GuestReservation portion of the UI defined in
Test Items: This test simulate a user interacting with the GuestReservation Entity for entering
data related to a guest's intended stay.
1. Click on the calendar icon to the right of Start Date text box;
2. Choose 28 December 2014 from pop-up calendar;
3. Click on the calendar icon to the right of Start Date text box;
4. Choose 3 January 2015 from pop-up calendar;
5. Click on Room Rate text box;
6. Enter 250.00;
7. Click Guaranteed checkbox;
8. Click Save Reservation button;
9. Click “OK” button.
1. Reservation start date calendar menu appears;
2. Reservation Start reflects 28 December 2014;
3. Reservation end date calendar menu appears;
4. Reservation End reflects 3 January 2015;
5. Cursor should appear within the Room Rate text box
6. $250.00 should appear in the Room Rate text box;
7. Checkmark should appear in the Guaranteed checkbox;
8. Save Reservation button reacts to action with graphical response, pop up panel displays
reservation saved with “OK” button;
9. Pop up panel closes.
Environmental Needs
b. 4GB RAM or more;

15
BBRMS services will require manager's permissions starting in the GuestReservation Entity.
BBRMS-UI-01 and BBRMS-UI-02 must be completed first for the user to continue workflow.

16
Objective: To provide a black-box test for the GuestInformation portion of the UI defined in
Test Items: This test will simulate the user interacting with the GuestInformation Entity for
inputting contact and credit card information for a guest.
1. Click the Guest Information button on the Guest Reservation panel;
2. Click on First Name text box;
3. Enter “Mary”;
4. Click on Last Name text box;
5. Enter “Jane”;
6. Click on Address text box;
7. Enter “123 Shady Lane, Adelphi, MD 20783”;
8. Click on Phone text box;
9. Enter “240-555-1212”;
10. Click on Credit Card Number text box;
11. Enter “1111222233334444”;
12. Click on the calendar icon to the right of the Credit Card Exp: text box;
13. Select 30 May 2015;
14. Click on CVV: text box;
15. Enter 777;
16. Click Save Guest button;
17. Click “OK” button.
1. Guest Information button reacts to action with graphical response and Guest
Information GUI is opens;
2. Cursor appears in First Name text box;
3. “Mary” appears in First Name text box;
4. Cursor appears in Last Name text box;
5. “Jane” appears in Last Name text box;
6. Cursor appears in Address text box
7. “123 Shady Lane, Adelphi, MD 20783” appears in Address text box;
8. Cursor appears in Phone text box;
9. “240-555-1212” appears in Phone text box;
10. Cursor appears in Credit Card Number text box;
11. “1111222233334444” appears in Credit Card Number text box;
12. Pop up calendar appears;
13. “05/30/2015” appears in the Credit Card Exp: text box;

17
14. Cursor appears in the CVV text box;
15. “777” appears in the CVV text box;
10. Save Guest button reacts to action with graphical response, pop up panel displays
“Guest Information Saved” with “OK” button;
16. Pop up panel and Guest Information panel close and Guest Reservation GUI reappears
Environmental Needs
b. 4GB RAM or more;
BBRMS service will require guest's limited access starting in the GuestReservation Entity
(interface section through service section and management).
BBRMS-UI-01, BBRMS-UI-02,and BBRMS-UI-03 must be completed for the user to continue
workflow.

18
Objective: To provide a black-box test for the MakePayment portion of the defined in section
3.1.1 of the SRS.
Test Items: This test will simulate a user interacting with the MakePayment Entity for receiving
a payment from a selected guest and adjusting a Finances balance.
1. Click on Guest drop down menu;
2. Hover pointer over each guest name;
3. Chose the last name that appears on the guest list;
4. Click on Total data text box;
5. Enter the value $1750.00;
6. Click on Payment text box;
7. Enter the value $1750.00;
8. Click Make Payment button.
1. Drop down menu should populate with guest names;
2. The name that the pointer is over should be highlighted in the drop down menu;
3. Chosen guest name should appear in the Guest text box;
4. Cursor should appear within the text box;
5. The text box should display $1750.00 value entered;
6. Cursor should appear within the data text box;
7. The text box should display $1750.00 value entered;
8. Panel button reacts to action with graphical response, MakePayment panel closes,
display returns to the main menu.
Environmental Needs
b. 4GB RAM or more;

19
BBRMS services will require manager's permissions starting in the MakePayment Entity.
BBRMS-UI-01, BBRMS-UI-02,BBRMS-UI-03, and BBRMS-UI-04 must be completed for the user
to be able to process a payment. BBRMS-UI-04 must be completed to initiate a payment
workflow.

20
Objective: To provide a black-box test for the Create Calendar Reservations portion of the user
interface as defined in section 3.1.1 of the SRS document.
Test Items: This test will simulate a user interacting with the CalendarReservation entity for
creating a Reservation.
Input Specifications:
1. Navigate to January 2015 on Calendar Screen;
2. Select Start Date box;
3. Enter “01/01/2015”;
4. Click on End Date box;
5. Enter “01/10/2015”;
6. Select “Room 1”;
7. Click Make Reservation button;
8. Click Room Rate;
9. Enter “250.00”;
10. Click on Guarantee Date box;
11. Enter “12/25/2014”;
13. Click Guest Information button;
14. Enter Guest Information;
Output Specifications:
1. Calendar displays date range for January 2015;
2. Cursor appears in Start Date box;
3. “01/01/2015” appears in Start Date box and does not disappear once Start Date box is no
longer selected;
4. Cursor appears in End Date box;
5. “01/10/2015” appears in End Date box and does not disappear once End Date box is no
longer selected;
6. “Room 1” is selected;
7. Page navigates to the Make Reservation screen. “01/01/2015” is displayed in the Start
Date box and “01/10/2015” is displayed in the End Date box;
8. Cursor appears in Room Rate box;
9. “25.00” appears in Room Rate box and does not disappear once Room Rate box is no
longer selected;
10. Cursor appears in Guarantee Date box;

21
11. “12/25/2014” appears in the Guarantee Date box and does not disappear once Guarantee
Date box is no longer selected;
12. All entries for the reservation are now saved;
13. Page navigates to the Guest Information screen;
14. Entry cursor appears on each box in the Guest Information screen. Entered information
appears in each box and remains once the box is no longer selected;
15. Guest Information is saved to the reservation and page navigates to the Make
Reservation screen. All prior entered information is still present on the Make
Reservation screen;
Environmental Needs
b. 4GB RAM or more;
None.

22
Objective: To provide a black-box test for the Update Calendar Reservations portion of the user
updating a Reservation.
1. Navigate to desired Calendar month and year range;
2. Select a date that falls within reservation to be updated;
3. Select room that is assigned to reservation to be updated;
4. Select Make Reservation button;
5. Select Reservation Start Date box;
6. Enter “02/01/2015”;
7. Select Reservation End Date box;
8. Enter “02/05/2015”;
1. Calendar displays desired month and year date range;
2. Date selected is highlighted on calendar. Window on right side of the screen shows
rooms for selected date;
3. Room selected is highlighted;
4. Page navigates to Make Reservation screen. Reservation information for select room
and date is displayed;
5. Cursor is displayed in Start Date box;
6. “02/01/2015” appears in the Start Date box and does not disappear when Start Date box
is no longer selected;
7. Cursor is displayed in End Date box;
8. “02/05/2015” appears in the End Date box and does not disappear when End Date box is
no longer selected;
9. All entries for the reservation are now saved;

23
10. Page navigates to Guest Information page. All Guest Information previously assigned
to the reservation is displayed;
11. Guest Information is saved to the reservation and page navigates to the Make
Reservation screen. All prior entered information is still present on the Make
Reservation screen;
Environmental Needs
b. 4GB RAM or more;
to be able to update a reservation.

24
Objective: To provide a black-box test for the Delete Calendar Reservations portion of the user
deleting a Reservation.
1. Navigate to desired Calendar month and year range;
2. Select a date that falls within reservation to be updated;
3. Select room that is assigned to reservation to be updated;
4. Select Make Reservation button;
5. Select Delete Reservation button;
1. Calendar displays desired month and year date range;
2. Date selected is highlighted on calendar. Window on right side of the screen shows
rooms for selected date;
3. Room selected is highlighted;
4. Page navigates to Make Reservation screen. Reservation information for select room
and date is displayed;
5. Reservation is deleted. All fields become blank;
Environmental Needs

25
b. 4GB RAM or more;
to be able to update a reservation.
4.2 Service Test Cases
These cases are designed to test the application programming interface (API) of the BBRMS,and
can be performed either by either manual or automated testing.
4.2.1 Specification ID: BBRMS-SV-01
Objective: To provide a white-box test for the reservations portion of the services to assign a
new reservation as defined in section 3.2.2 of the SRS document.
Test Items: GuestReservation( ), Reservation [ ] checkDates ( ), assignReservation, Make
Reservation button.
1. Click on desired date on Calendar;
2. Click on a vacant room;
3. Click on Make Reservation button;
1. Page navigates to Guest Reservation screen;
2. Reservation [ ] checkDates( ) function verifies dates for specified room are available;
3. New domain object is created by the assignReservation service with start and end dates
assigned;
Environmental Needs

26
b. 4GB RAM or more;
Information must be collected from the guest for date and room preferences.
None.
Objective: To provide a white-box test for the guest portion of the services to take a new guest’s
information, as defined in section 3.2.2 of the SRS document.
Test Items: Guest [ ] guests, takeGuestInfo( ), Save Guest button
2. Enter guest’s first name;
3. Enter guest’s last name;
4. Enter guest’s email;
5. Enter guest’s address;
6. Enter guest’s phone number;
7. Enter guest’s credit card number;
8. Enter guest’s CC exp date;
9. Enter guest’s CC CCV number;
1. takeGuestInfo ( ) creates a new domain object using entered information;
2. Page automatically navigates back to Guest Reservation screen;

27
Environmental Needs
b. 4GB RAM or more;
Page menu for Guest Reservation must be displayed prior to beginning this test.
BBRMS–SV–01 must be completed prior to the start of this test.
Objective: To provide a white-box test for the guest portion of the services to cancel the process
of taking a new guest’s information, as defined in section 3.2.2 of the SRS document.
Test Items: takeGuestInfo( ), Guest [ ] guests ( ), Cancel button
2. Enter guest’s first name;
3. Enter guest’s last name;
4. Enter guest’s email;
5. Enter guest’s address;
6. Enter guest’s phone number;
7. Enter guest’s credit card number;
8. Enter guest’s CC exp date;
9. Enter guest’s CC CCV number;
10. Click Cancel button;

28
1. takeGuestInfo( ) service will not create a new domain object;
2. Page automatically navigate back to the Guest Reservation screen;
Environmental Needs
b. 4GB RAM or more;
Page menu for Guest Reservation must be displayed prior to beginning this test.
BBRMS–SV–01 must be completed prior to the start of this test.
Objective: To provide a white-box test for payment service defined in section 3.2.4 of BBRMS’s
SRS.
Test items: makePayment(), assignGuest(), Payments[]payments, Finance[]finances.
Input specifications:
1. User entered data in the Make Payment GUI;
2. User click Make Payment button.
Output specifications:
1. makePayment() creates Payment object;
2. assignGuest() assigns a guest to a payment;
3. Payment[]payments stores payments information;
4. Finance[]finances stores finances information;
5. Make Payment GUI text boxes are cleared.
Environmental needs:

29
b. 4GB RAM or more;
4. Display at 1280x1024 for optimal viewing of all GUIs during testing;
5. Java or Visual Studio 2014.
Special procedural requirements:
Payment GUI must be displayed and data are filled in the text box.
Inter-case dependencies:
BBRMS-UI-05 must be completed prior to conduct paymenttest.
Objective: To provide a white-box test for cancel payment service as defined in section 3.2.4 of
the BBRMS’s SRS.
Test items: makePayment(), assignGuest(), Payments[]payments, Finance[]finances.
1. User clicks on Guest drop down menu;
2. User selects a guest from the list;
3. A MakePayment GUI displays;
4. User click on Cancel button.
1. makePayment() destroys Payment object associated to a guest;
2. assignGuest() destroys the payment to a guest;
3. Make Payment GUI boxes are cleared.

30
b. 4GB RAM or more;
Payment GUI must be displayed and data are filled in the text box.
BBRMS-SV-04 must be completed prior to cancel guest payment test.
Objective: To provide a white-box test for creating guest reservation service as defined in
section 3.2.2 of the BBRMS’s SRS.
Test items: createReservation(), takeGuestInformation(), takeRoomReservation(),
takePayment(), Reservation[]reservation, RoomReservation roomReservation, Guest[]guests,
MakePayment makePayment, TakeGuestInformation guestInformation.
1. User selects Guest Reservation from the pulled down menu;
2. User clicks on Guest Information button,takeGuestInformation(),
TakeGuestInformation guestInformation;
3. User filled in data in Guest Reservation GUI text boxes, Guest[]guests;
4. User clicks on Make Payment, takePayment(), MakePayment makePayment;
5. User clicks on Save Reservation button.

31
1. Guest Reservation GUI pops open;
2. Guest information GUI pops open;
3. Make payment GUI pops open;
4. takeRoomReservation() creates RoomReservation roomReservation;
5. createReservation() creates Reservation object;
6. Reservation[]reservation stores reservation information;
7. Guest Reservation GUI text boxes cleared;
b. 4GB RAM or more;
Guest Reservation GUI must be displayed and the text boxes must be filled in and Guest
Information button must be function with guest available to select prior to conduct this
reservation test.
BBRMS-UI-03,BBRMS-UI-04, BBRMS-UI-05,BBRMS-UI-06, BBRMS-UI-07,BBRMS-SV-01,
BBRMS-SV-02, BBRMS-SV-03 and BBRMS-SV-04 have to be completed prior performing create
reservation service test.

32
Objective: To provide a white-box test for the delete reservation service as defined in section
3.2.2 of BBRMS’s SRS.
Test items: deleteReservation(), takeGuestInformation(), takeRoomReservation(),
takePayment(), Reservation[]reservation, RoomReservation roomReservation, Guest[]guests,
MakePayment makePayment, TakeGuestInformation guestInformation.

33
1. User opens Guest Reservation GUI from the pulled down menu;
2. User clicks on Guest Information button,takeGuestInformation(),
TakeGuestInformation guestInformation;
3. User clicks on Delete Reservation button;
4. User clicks OK or Cancel on the pop-up warning windows;
5. User clicks on OK, to delete a guest’s reservation.
1. Guest Reservation GUI displayed;
2. Text boxes in the GUI prefilled with guest’s reservation data;
3. A warning pop-up windows remind the user the reservation will be deleted;
4. deleteReservation() deletes the reservation associated with the Guest[]guests;
5. takeRoomReservation() updates room status with RoomReservation
roomReservation;
6. takePayment() refunds with MakePayment makePayment.
b. 4GB RAM or more;
e. BBRMS software installed;
Guest Reservation GUI must be displayed and Guest Information button must function
correctly. The system will generate an information pop-up box if trying to delete non-existing
guest or a guest with no reservation.
BBRMS-UI-03, BBRMS-UI-04,BBRMS-UI-05, BBRMS-UI-06, BBRMS-UI-07, BBRMS-UI-08,
BBRMS-SV-01, BBRMS-SV-05 and BBRMS-SV-06 must be completed prior conducting delete
reservation test.

34
Objective: To provide a white-box test for create room service as defined in section 3.2.3 of the
BBRMS’s SRS.

35
Test items: setroomID(), getroomID(), togglevacancy(), isVacant(), setroomNumber(), and
getroomNumber().
1. User selects Create Room from BBRMS pull down menu;
2. User enters room number in the Room Numbertext box;
3. User select vacant;
4. User click on Save Room.
1. Room Reservation GUI opens;
2. setroomNumber() creates Room object domain;
3. togglevacancy() updates room vacancy status.
b. 4GB RAM or more;
Three rooms created by BBRMS system. The Create Room GUI is used for updating the vacancy
status.
BBRMS-UI-02 must have been completed prior to conducting this test.

36
Objective: To provide a white-box test for the delete room service as defined in section 3.2.3 of
the BBRMS’s SRS.
Test items: setroomID(), getroomID(), togglevacancy(), isVacant(), setroomNumber(), and
getroomNumber().
1. User select Room Reservation pull down menu;
2. User enters a room number in the Room Numbertext box;
3. User clicks on Delete Room button.
1. Room Reservation GUI opens;
2. setroomNumber() destroys Room objectdomain;
3. Room Reservation GUI closes.
b. 4GB RAM or more;
5. Java or Visual Studio 2014
Requires room number exist.
BBRMS-UI02 must completed prior conducting this service test.

37
4.3 Domain Object Test Cases
These cases are designed to test the data encapsulation and storage portion of the BBRMS, and
can be performed either by manual or automated testing.
4.3.1 Specification ID: BBRMS-DO-01
Objective: To provide a white-box (process) test for the Guest domain object validating the
guest name data type.
Test Items: The “get” and “set” methods of the for guest name in the guest domain object. This
case will test for the output after valid data entry.
1. The user of the BBRMS enters a valid customer name (e.g. Dave Brown) of variable
character data type in the valid format which contains no numbers or special characters.
1. Guest object created successfully;
2. Guest[]guests contains the new guest object.
Environmental Needs
b. 4GB RAM or more;
None
BBRMS-SV-02

38
Objective: To provide a white-box (process) test for the Guest domain object validating the
credit card data type.
Test Items: The “get” and “set” methods for credit card information in the guest domain object.
This case will test for the output after valid data entry.
1. The user of the BBRMS enters a valid 16 digit credit card number in the valid format
which contains no spaces or special characters and is of variable character data type.
1. Guest object created successfully;
2. Guest[]guests contains new guest object.
Environmental Needs
b. 4GB RAM or more;
None
BBRMS-SV-02

39
Objective: To provide a white-box (process) test for the Guest domain object when invalid data
is entered for guest’s name.
Test Items: The “get” and “set” methods for the guest name in the guest domain object. This
case will test for the output after invalid data entry.
1. The user of the BBRMS enters a guest name that includes a numeric or special character.
1. Error message displayed saying “Invalid guest name.”;
2. No guest object created.
3. Guest[]guests contains no new objects.
Environmental Needs
b. 4GB RAM or more;
None
BBRMS-SV-02

40
Objective: To provide a white-box (process) test for the Guest domain object when invalid data
is entered for credit card number.
Test Items: The “get” and “set” methods for credit card information in the guest domain object.
This case will test for the output after invalid data entry.
1. The user of the BRBMS enters a credit card number that includes spaces or any character
other than 0-9.
1. Error message displayed saying “Invalid credit card number.”;
2. No guest object created.
3. Guest[]guests contains no new objects.
Environmental Needs
b. 4GB RAM or more;
None
BBRMS-SV-02

41
Objective: To provide a white-box (process) test for the Reservation domain object to validate
guarantee status.
Test Items: The isGuaranteed() Boolean method and the setGuaranteeDate() method of the
Reservation domain object.
1. The user of the BBRMS attempts to create a reservation for a room that has a guarantee
date for another guest.
2. The user enters reservation data for a room that already has a guarantee date.
3. The user clicks “Save Reservation.”
4. Click “OK”
1. The isGuaranteed Boolean method returns true for the room during the specified date
range.
2. Error message displayed indicating the room is guaranteed to another guest, and asks
the user to click “OK” to select another room for the date range, or change the date
range for the selected room; or click “Cancel” to end the reservation process.
3. The display returns to the reservation GUI.
Environmental Needs
b. 4GB RAM or more;
None
BBRMS-SV-06

Group 4 STS final version

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Group 4 STS final version

Similar a Group 4 STS final version (20)

Group 4 STS final version