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 Management Plans.

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 QueryRoom

ReservationMake

PayementGuest

ReservationGuest

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 Data2.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 Guest3.2 Finances

3.3 Payment

3.4 Room

3.5 Reservation

<<manages>>

<<store>><<retrieve>>

<<interacts>>

<<interacts>>

<<create>><<delete>>

<<edit>> <<create>><<delete>>

<<edit>>


<<edit>>


<<edit>>


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

guarantee date)

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

Validate Guest

(name)

3.2.1 App. F,

Case 2,

S#1

6.2.1 4.3.1

10

Domain

Objects

Validate Guest

(Credit Card)

3.2.1 App. F,

Case 2,

S#1

6.2.1 4.3.2

Domain

Objects

Invalidate Guest

(name)

3.2.1 App. F,

Case 2,

S#2

6.2.1 4.3.3

Domain

Objects

Invalidate Guest

(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”;

12. Click Save Reservation button;

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”;

9. Click Save 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. 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.

4.2.4 Specification ID: BBRMS-SV-04 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 payment test.

4.2.5 Specification ID: BBRMS-SV-05 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.

4.2.6 Specification ID: BBRMS-SV-06 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

4.2.8 Specification ID: BBRMS-SV-08 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 Number text 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

4.2.9 Specification ID: BBRMS-SV-09 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 Number text box;

3. User clicks on Delete Room button.


1. Room Reservation GUI opens;

2. setroomNumber() destroys Room object domain;

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

4.3.2 Specification ID: BBRMS-DO-02

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

Documents

specification id

backgroundthe bbrms

test environmentthe

software test documentation2

test environment31

software design document

test cases specific

user interface test