Chapter 9. Scenario Tests

“I did then what I knew how to do. Now that I know better, I do better.”

Maya Angelou

The triad creates tests for the exceptions in a use case. Tom explains the levels at which the tests are run. Debbie shows how early implementation can give quick feedback on meeting the charter’s objectives.

---

Tests for Exception Scenarios

Cathy starts off, “We’ve finished the test for the main course of the Check Out CD use case. I suppose we should do tests for the other scenarios, because we’re focused on that use case. Where should we start?”

Tom replies, “If you had limited time, Debbie and I would create tests for the exceptions and alternatives and then review them with you. You’ve already told us how the system should respond to many of the exceptions and given us an example for the main course. But because you have the time and interest, let’s create a test for the scenario Check Out Rented CD. The customer attempts to rent a CD that is already rented. The change is in the setup. What do you want to see as a result?”

Cathy replies, “I think the clerk should see an error message.”

Tom states, “So the test looks like the following:”

Tom continues, “You can see that the customer data is the same. We could put the Customer Data table into a common location and reference it from the other tests. There is a trade-off between using a common setup and redoing the setup for every test. We’ll talk about that later [see Chapter 31, “Test Setup”]. The difference in the setup in this case is that the CD is already rented. The difference in the result, which we put as the final step in the action, is that an error is produced. The Check in the last table verifies that the error message is reported as CD_Already_Rented. This name could be what is output, or it could represent text that is determined later. No contract is printed out since the error occurred.”

“Another test scenario is CD Rental Limit. This is when a customer who has three CDs rented tries to rent another one. We need to setup the situation where a customer has rented three CDs. Without repeating the Customer Data, the setup looks like this:”

“We included one additional aspect in this setup. It’s customer ID = 007. This table reflects the rentals for which the customer ID is 007 or James. That way, we do not have to duplicate the 007 in every row for the Customer ID column. Also, if the CD data in the system has rentals for customers other than 007, this table only reflects those for 007. Now, you might notice that Rented is Yes for every row. So we could move that up to the first line.

“In this case, the error message is different from the previous test. To check that the CD limit was applied correctly, we should make up a test where two CDs are currently rented. If this story was critical, I might try more conditions. For example, I could try to rent lots of CDs and make sure that the error occurs on every attempt after the third CD.”

“The given part of this test could be simplified. In this case, the title of the CD and the rental due dates are not needed by the test. So it could be shown as the following:”

Tom continues, “This is a simple business rule test. You can test it by connecting to the module that implements the rule. Then you need to create a test that ensures the business rule is correctly connected to the check-out process. That test would look like the uncondensed one.”

---

Tests for Business Rules

Cathy states, “I think I’ve gotten the idea now. Sam and I were thinking of another business rule. We won’t let a customer rent another CD if he has one that is late. So, based on your examples, here’s what I think the test should look like:”

---

Cross-Story Issues

Tom notes, “It’s possible that both the CD Limit and the Late Rental conditions occur at the same time. For example:”

Cathy interrupts, “I can see from the test what the issue is. Should the system report Customer_Has_Late_Rental or CD_Rental_Limit_Exceeded? In this case, even if the customer returns the two CDs that are not late, he cannot rent a CD. So I’d have the system report as Customer_Has_Late_Rental. When the customer return the late CD, the CD limit will not be reached.”

Tom resumes, “This is an example of cross-story issues. As best as we try, some stories have issues with other stories. Many times, we can identify these in advance. At other times, we may not discover the issues until later.”

---

Don’t Automate Everything

Tom starts off, “Cvathy, we’ve created a couple of exceptions for entering a bad customer ID.” Debbie could program this into the system. She could track the number of times a bad customer ID was entered and put up an appropriate error message. I’d have to write some tests to ensure that was coded correctly.” Cathy replies, “It seems like this exception could be handled by manual instructions to the clerk. It could be:”

Tom continues, “Then we just have to write a test for one bad customer ID.”

“The cost of implementing and testing for the number of bad entries is probably not justified by a business value. But that’s your call. Part of our job is not just to deliver software to you, but to deliver software that delivers business value.”

---

Multi-Level Tests

Tom starts off, “The tests we created can be used on multiple levels within the system. For example, the CD Check Out Test can be applied at the user interface level or the middle tier (see Figure 9.2). If we apply the test at the middle tier, we check that the functionality works in Debbie’s code. Once we design the user interface, we test that the user interface is coupled properly to the correct functionality in the middle tier.”

Figure 9.2. Multi-Level Tests

“As a side note, running the test at the middle-tier level ensures that business rules are not coded in the user interface. This makes a clean separation of responsibilities between the two levels.”

“We may run some tests just against the middle tier, such as Calculate Rental End [see Chapter 8, “Test Anatomy”]. To clarify the context, I created a diagram (see Figure 9.3). The results of that calculation show up in an output in the rental contract. I’ve added an additional screen, CD Data Screen, to allow viewing of CD data for setup and expected outcomes. We will use this additional screen just during testing, not in the deployed system. It is not a good idea to keep test-related functionality in production. It can cause security problems and other issues.”

Figure 9.3. Tests for Different Layers

Cathy states, “If this screen shows all the data on a CD, we could use it on a regular basis. It made me think of a situation where the clerk might want to know whether a particular CD was rented. Let’s make it into a requirement. What will it look like?”

Tom displays the screen in Figure 9.4.

Figure 9.4. The CD Screen

“The Calculate Rental End test goes into the heart of the application. You probably would not use it in regular operations, so we are not going to create a user interface for it. Just use a test that goes to the middle tier. However, we do need the ability to set the date for the application, not for the entire computer. Otherwise, other programs may be affected. So we could either have a Set Date screen that allows the tester to manually set the date, or we could have an input at the start of the program (called a command-line parameter) that sets the date.”

“Another reason that we run Calculate Rental End to the middle tier is that we can run many test cases on this business rule without the user interface. As we talked about earlier [see Chapter 4, “An Introductory Acceptance Test”], tests run directly to the middle tier allow execution of lots of test cases without getting carpal tunnel syndrome.”

“All the test scenarios from the use case should be run through the user interface. But sometimes the business rules are so numerous that it could take a long time to create test scenarios. For example, if there were hundreds of discount levels, creating an order to test every one of them would be onerous. In cases like that, if Debbie, you, and I agree that there is little risk for a particular aspect of a story, it makes more sense for us to concentrate our time elsewhere. We will run at least one case for each scenario that causes the user interface to generate a different display, such as an error message.”

---

User Interface Tests

Tom starts off, “If you need a more visual representation of how the user interface works, we could work together to create a prototype. We might come up with something like this display [see Figure 9.5]. We could get preliminary feedback from you and the clerks. After Debbie implements the first version of the user interface and tests it against the acceptance tests, you and the clerks can start using it. The interface may change dramatically based on your comments. For example, the order and position of the two input fields might change. Or we might not have a Submit button on the check-out screen. When both fields are filled in, the rest of the rental process would commence.”

Figure 9.5. Check-Out Screen

“For each of the error messages that appeared during the Check Out tests (such as Customer_Has_Late_Rental), Debbie will create an indication on the display. The message could appear on the entry screen or in a separate dialog box. The error could create a loud beep or just a quiet ding.” Cary, Mary, and Harry will tell Debbie what they want. We will talk later [see Chapter 14, “Separate View from Model”] about ways to capture tests for displays.”

---

Check the Objectives

Tom continues, “Once we have a user interface for the Check Out CD story, we can see how the check-out time compares to the objective stated in the project charter. Remember that the measure is to achieve 50% less time [see Chapter 5, “The Example Project”]. We are going to start with the easiest way to implement the check-out screen. The benefit of this approach is that it requires no hardware. However, it does take more clerk time and introduces the possibility of errors, even if appropriate check digits are incorporated in the IDs. If we meet the objective, we are done.”

“If we come shy of the 50%, we have a system that is faster than before. You and Sam can decide whether there is a business reason for spending more money to reach the 50% measure. If there is little financial justification, you may want to revise the objective.”

“If the measured time is far off, we could investigate ways to cut it down. We could add a handheld barcode scanner for either or both IDs. A customer might forget to bring his customer card with a bar code, so we might have to figure the potential time savings for just scanning the CD. And we need to take into account unreadable bar codes. If the handheld scanner isn’t fast enough, we could look at an in-counter scanner.”

“If the bar code scanner doesn’t look like it will be fast enough, well, Debbie has been dying for an opportunity to try out those new radio frequency ID (RFID) microchips. With an RFID embedded in the CD case and one in the customer identification card, you could check out the customer as he walked past the clerk’s desk.”

Debbie’s responds to the mention of RFID, “I’m pretty sure that’s overkill for this size operation. But when Sam ramps up the marketing for this place after the software is developed, it might be a thing to try.”

Tom resumes, “If we had a larger system to measure, we might record a log file that monitors the speed and correctness of entries. The time delay due to errors or slowness could be converted to dollars based on some conversion ratio. Unfortunately, the negatives caused by the delay or customer impatience are harder to measure. When the dollars that are lost due to delay justify the cost of additional hardware, we can upgrade the system.”

---

Summary

• Create a test for each exception and alternative in a use case.

• Do not automate everything.

• Run tests at multiple levels.

• Create a working system early to check against objectives.