Inf 43: Introduction to Software Engineering
Fall, 2014
Homework 3: Black-Box Testing of BeachBurnManager
Due Tuesday, December 9, 5:00pm (hard copy to be turned in in lecture)
This assignment is about testing, specifically partitioning the test-input domain for several requirements of your choice.
For this assignment, you are required to plan for testing of the BeachBurnManager system using a "black box" or specification-based testing approach. In particular, you will develop tests for two of the use cases for BeachBurnManager, listed below. (These two use cases were not necessarily given in the interviews, so don't worry if you did not include them in your requirements specification.) You will not execute any test cases since there is no code available. Use the following two use cases for BeachBurnManager as the requirements specification for this assignment.
Use Case 1: Schedule band
In this use case, the schedule manager schedules a band to (a) time slot(s) as part of the 5-day schedule for the event. To accomplish this, the user must input three items:
1. The day (1, 2, 3, 4, or 5), chosen from a drop-down list.
2. The time slot(s), chosen through some type of user interface that does not allow invalid input. Each day of the event lasts from 10am-6pm. There are 8, 1-hour time slots available per day (10-11am, 11am-12pm, 12-1pm, 1-2pm, 2-3pm, 3-4pm, 4-5pm, 5-6pm). A band can be scheduled for a 1-hour, 2-hour, or 3-hour time slot.
3. The name of the band (chosen from a drop-down list of bands that the system already knows about--you can imagine the contents of this list to be whatever bands you like for the purposes of this assignment)
The output of this use case would be a band being scheduled for a particular date and time (as reflected in the schedule). For example, if one of my test cases consisted of: {Day 3, 11am-1pm, The Go-Go's}, the expected output for this test case would be the Go-Go's being scheduled for Day3 of the festival in the 11am-1pm time slot.
Use Case 2: Find best available seats
In this use case, the ticket seller asks the system to find the best available seat(s) in a given price range. For simplicity's sake, assume that the stadium has 100 total seats, set up in 10 rows, labeled A through J, and there are 10 seats in each row. Individual seat names consist of their row and seat number (e.g., C10, I8, G2). All seats in a row must be in the same price sector (i.e., all seats in row E must have the same price, all seats in row G must have the same price, etc.)
For this use case, the user is asked to specify:
1. The number of consecutive seats desired (through a text field that only allows numerical characters). This is a mandatory field.
2. A lower bound for the price range (seat(s) found must cost at least this amount) (through a text field that only allows numerical characters). This field is optional. If left blank, it means that there is no lower bound for the price range.
3. An upper bound for the price range (seat(s) found can cost no more than this amount) (through a text field that only allows numerical characters). This field is optional. If left blank, it means that there is no upper bound for the price range.
The upper bound must be greater than or equal to the lower bound. If not, the system will generate an error message. If both lower and upper bound are left blank, the system finds the best seat in any price range.
The algorithm for finding the "best available" seat(s) should find the seat(s) that is/are closest to the front (row A is the front row, and row I is the back row). If there are multiple available seats or sets of seats that meet the criteria in the same row, the system should choose the one(s) that are closest to the middle. (If there are multiple possible candidates for the "best seats," the system should just pick one.) The input for your test cases is a set of seats that have been sold, a set of price sectors that the different rows have been set at, and the three criteria listed above. For example, one of my test case inputs might be:
{Seats sold: A3-10, B8, C3-5, D9-10, G1-10, H2-3, I2-3, 5-8, 10,
Prices set: Rows A-C: $100; Rows D-G: $50; Rows H-I: $25,
Num seats desired: 2,
Lower bound: $25,
Upper bound: $50}.
The expected output of this test case would be {D5, D6}. All of your test cases could have the same set of seats sold inputted, and the same set of price ranges inputted, and that would be ok.
You will follow the equivalence class partitioning approach to black box testing. For each of these two use cases, determine exactly three bases, making sure that each of them is a reasonable criterion that can be used to divide the domain of possible test cases into interesting subdomains. For each basis, list at least three subdomains and two test cases for each subdomain (in some cases, there may exist only one test case for that subdomain, and in that case you can list just one).
Record your test cases in a collection of 6 test matrices. Your homework should start from the Homework 3 template. DO NOT CHANGE THE FORMAT OF THE TESTING MATRIX. You can add/remove space in between the matrices to keep all of each table on one page, and you can add/remove rows (but not columns) from the matrices. No other edits are allowed. If you do, you will be deducted points. (If you see that an edit is necessary, ask me about it first to makes sure that it's ok.)
Your input to a test case will often be one of more seats, price ranges, etc. so feel free to define some of these inputs in the "Notes to help understand..." section of your document so that you can use them in a shorthand way throughout the rest of your document.