Inf 43: Introduction to Software Engineering
Fall, 2015
Homework 2: Black-Box Testing of PrivatePractice
Due Wednesday, November 18, 11:55pm (through EEE)
This assignment is about testing, specifically partitioning the test-input domain for two requirements/use cases.
For this assignment, you are required to plan for testing of the PrivatePractice system using a "black box" or specification-based testing approach. In particular, you will develop tests for two of the use cases for PrivatePractice, 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 PrivatePractice as the requirements specification for this assignment.
Use Case 1: Calculate Body Mass Index (BMI)
In this use case, the doctor asks the system to calculate a patient’s BMI. To accomplish this, the user must input three items:
1. The “feet” portion of the patient’s height (must be a valid non-negative number, or else the user will get an error message)
2. The “inches” portion of the patient’s height (must be a valid non-negative number, or else the user will get an error message)
3. The patient’s weight in pounds (must be a valid non-negative number, or else the user will get an error message)
Once all three items are inputted, the user can ask the system to calculate the BMI. Assume that the user interface does not allow any of these three items to be blank (e.g., the button to calculate BMI is grayed out unless all three items are entered.) (Hint: none of your test cases should include a blank entry!)
The output of this use case would be their BMI as a floating point number with exactly one digit after the decimal point (round to the nearest tenth). The system should calculate BMI using the following formula:
(weight in pounds * 703) / ((height in inches) ^2)
For example, for a 6-foot, 3-inch person with a weight of 215 pounds, the formula would become:
(215 * 703) / (75 ^2) = 151,145 / 5,625 = 26.9
Thus, a BMI of 26.9 would be calculated for these inputs.
*Note: Regardless of what your basis is for a particular test case, all test cases for this use case must consist of all three items (feet, inches, weight)
*Note 2: If the input results in division by 0, “NaN” is displayed as the BMI.
Use Case 2: Find Earliest Available Appointments
In this use case, the patient asks the appointment system to find the (at most) 5 earliest available appointments for the next 5 days. Some assumptions:
1. There are 3 doctors that work at the hospital: Dr. Khode, Dr. Kumar, and Dr. Sethi.
2. Each doctor works from 8am-5pm every day (with no lunch—sorry guys.)
3. Appointments are only schedule at times that end in :00, :15, :30, or :45.
4. An appointment can be 15-, 30-, or 45-minutes long.
5. If there are multiple appointments available at the same time with different doctors, the system will return them in alphabetical order by the doctor’s last name.
6. The system should return no more than 5 appointments.
7. If there are no appointments matching the criteria, the system will display the message “No available appointments.”
For this use case, the user is asked to specify:
1. The length of the desired appointment (15, 30, or 45 minutes). This is a mandatory field chosen from a drop-down list that does not allow the field to be left blank or contain any invalid data.
2. Their preferred doctor(s). The user can specify 0 or more doctors through checkboxes (which allow no invalid input). This input is optional. If no doctors are checked, the system will search for the earliest appointments available with any doctor.
The input for each test case is:
1. The current schedule (which appointment times are taken for the next 5 days for each doctor)
2. Appointment length
3. Preferred doctor (can be left blank).
For example, let’s first define a schedule, calling it SCHEDULE_A (remember, the times specified here are the times that are already taken by existing appointments).
SCHEDULE_A:
Khode: Day 1: 8:00am-5:00pm; Day 2: 8:00am-5:00pm; Day 3: 8:00am-5:00pm; Day 4: 8:00am-5:00pm; Day 5: 8:00am-8:30am, 9:15am-5:00pm
Kumar: Day 1: none; Day 2: none; Day 3: none; Day 4: none; Day 5: none
Sethi: Day 1: 8:30am-10:45am, 11:00am-4:45pm; Day 2: 8:00am-3:15pm, 3:45pm-5:00pm; Day 3: 8:00am-4:45pm; Day 4: 8:00am-5:00pm; Day 5: 10:15am-10:30am, 10:45am-3:15pm
Then, one of my test case inputs might be:
{SCHEDULE_A,
45 minutes,
Khode/Sethi}.
The expected output of this test case would be:
{Day 5/Sethi: 8:00am-8:45am,
Day 5/Sethi: 8:15am-9:00am,
Day 5/Khode: 8:30am-9:15am,
Day 5/Sethi: 8:30am-9:15am
Day 5/Sethi: 8:45am—9:30am}.
All of your test cases could use the same schedule, 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. (<- DO NOT OVERLOOK THIS REQUIREMENT—YOU WILL LOSE BIG POINTS IF YOU DO!) Make sure your subdomains cover the whole range of possible inputs. You should avoid overlapping your subdomains whenever possible.
Record your test cases in a collection of 6 test matrices. Your homework should start from the Homework 2 template. Be sure to turn it in as a Word file! 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.)