Chapter 10. User Story Breakup

“Life affords no higher pleasure than that of surmounting difficulties, passing from one step of success to another, forming new wishes and seeing them gratified.”

Samuel Johnson

The triad meets to discuss another story. Cathy discovers how stories can emerge from the details. Tom shows some boundary tests.

Acceptance Tests Help Break Up Stories

Cathy begins, “I tried out the Check-Out story on Tom’s computer. Obviously, you need to add more customers and CDs, but at this point, it looks okay to me. So what’s next?”

Debbie replies, “I worked with Cary on the user interface screen. Mary and Larry need to try it to see if it’s usable for them. We could do the Check-In story next, but it’s along the same lines as Check-Out. To save your time, Tom and I created some tests, and we’ll review them with you. The Charge Rentals story is related to Check-In, so let’s do that now. The story is”:

Debbie states, “When we initially discussed the story, we thought about breaking it into two stories with these acceptance criteria.”

“I’d keep these as two separate stories, based on the tests. The tests for the first one relate to computing the correct charge. The tests for the second one revolve around transactions and interfaces with third parties.

Business Rule Tests

Debbie continues, “Cathy, could you explain the details for the computer rental fee?”

Cathy answers, “Sure. Sam and I created three categories of CDs: Regular, Hot Stuff, and Golden Oldie. We have different rental rates for each category. They are as follows.”

Debbie requests, “To make it clearer, I’d like to put the values for these rates in a table.” Cathy replies, “Sounds fine to me.”

Debbie asks, “We need some names for the column headers for those values like $2 and 2 days. What do you call them?”

Cathy replies, “Sam and I just talk about rates. But I can understand that you need more clarity. So I’ll call the rates Rental Rate, which is the base rate for the Rental Period Days, and Extra Day Rate, which is for days over the Rental Period Days.”

Debbie shows the following.

Cathy replies, “This is the way it works now. I know we discussed a late fee in our original talks. Sam and I agreed we should just make a single charge when the CD is returned, rather than two separate charges.”

Debbie asks, “Do these rates ever change?”

Cathy answers, “Not too often. But I obviously would like the ability to change these rates.”

Debbie comments, “Let’s make up another story for that. As you can see, there are often new stories that emerge when we get to the details. The story could be this one.”

Debbie continues, “We’ll get everything done for this current set of rates. I have the big-picture idea that the rates will change. When I program this story, I’ll code it so that the effort to add modifiability won’t be a big deal. If it would take a lot of work to make the code easy to change, I’d code what I needed now and make the alterations later. When I eventually add modifiability, I’ll know that my alterations did not affect the original story, because there will be all the acceptance tests we are going to develop around this story.”

Tom says, “So let’s make up some tests.” He writes the following on the whiteboard.

Cathy replies, “That doesn’t seem like enough. You don’t have an example for Golden Oldie.”

“We can add one,” Tom responds. “We’re going to have a test for the rate table you proposed. So we’ll have already made sure that the Rental Period Days and so forth are correct for Hot Stuff. The test cases in the table show that we can compute the Rental Fee correctly for a normal and an extra day rental. If we had 50 different CD categories, repeating the same calculation for each one would be redundant. We don’t want to over-test a low-risk situation, such as a simple calculation. If we had all 50 calculations in this table and you changed the formula, we’d have to change all 50 results.”

“There could be a reason for adding Golden Oldie. The test case would show that our calculation worked for cents. So the new row looks like this.”

Tom continues, “If the values for Rental Rates are fixed, we need a test that checks that the values are correct in the application. In essence, it would make sure they matched the values in the Rental Fees table. If values are modifiable, we need a test to ensure that when you change a value, the new value is stored correctly.”

“The application can check when you change rates that the new values are in a reasonable range, such as a Rental Rate greater than $.99 and less than $10. However, if you entered an incorrect Rental Rate, for example $1 for Hot Stuff instead of $4, that rate would seem reasonable to the application and it would be stored. Trying to prevent an input error like that can be difficult and often is practically impossible.”

“I’d like to ask about some more test cases. I always think about the boundary conditions, so let me see if I’ve interpreted your rule correctly.”

“Wow!” exclaims Cathy. “You really do have an active mind. I never even thought about those last two test cases. That one charging someone $100 for a rental seems right according to your calculations. But that doesn’t seem right for the business. I think we need to cap the amount of the Rental Fee to the price of the CD. It will take a little bit of time for Sam and I to get together to determine how that should work—whether a rental that goes on for a number of days is automatically terminated and the CD is sold to the customer or whether we give the renter a call or so forth. I think there may be a couple of new stories:”

Cathy continues, “So what do you mean by that test for 0 Rental Days? We never rent anything for 0 days. We wouldn’t make any money doing that.”

Tom replies, “It’s unclear to me how you determine rental days. Is it a 24-hour period? What if someone checks out the CD and then immediately returns it? How long is that?”

Cathy smiles, “You are really being picky. I guess I need to be more precise so that you can give me exactly what I want. If a rental is returned by 11:59:59 p.m. on a particular day, we count that as being returned on that day. We charge the Rental Rate for anything that is returned on or before the Rental Due Date. So it doesn’t matter if a customer returns it on the same day. It’s still charged the full Rental Rate.”

Tom answers, “I might make up a table that gives examples of what you just said. But I can’t see ambiguity, like when I worked on an application for one place where they were using time periods based on minutes.”

Cathy asks, “How did that create a problem?”

Tom answers, “This was a case of where they needed to calculate days, hours, and minutes. I came up with the following table.”

“What’s that last one?” Cathy inquires. “You can’t have an end time that is before the start time.”

Tom answers, “It’s when daylight savings time ends. There is a small window between 1 a.m. and 2 a.m. If the start falls within this window and the stop occurs within one hour of setting the clock back, it’s possible to get negative time. Even if you have a start before this window and a stop after this window, you get one less hour than exists in reality.”

“Okay, so what did you do?” Cathy asks.

Tom responds, “The customer said he didn’t want us to spend the time figuring out how to handle it. The situation would occur so rarely that it’s not worth trying to solve it. So we just limited the number of minutes not to be less than zero.”

Debbie says, “Testers tend to think of edge conditions, like what Tom showed. Often, these edge conditions relate to decisions that businesses have to make. So it makes sense to bring up these conditions as part of a requirements discussion.”

A Story with a Business Rule

Debbie starts off, “Let’s see how the business rule calculations fit into a check-in scenario. I had a preliminary acceptance test for Check-In. Let’s add the Rental Fee calculation to it.”

The triad works together to create this test.

Debbie continues, “We don’t have to run through all the combinations that we tested in the rental fee computation. One will do. We could do a second one to ensure that the check-in flow is correctly tied to the rental fee computation and it wasn’t just luck that we happened to get the right rental free. If Cathy wanted a different outcome between an on-time check-in and a late check-in, such as sending an e-mail for every late check-in, we would come up with two test cases. We should also create test cases for exceptions, such as trying to check-in a CD that hasn’t been rented or an ID that does not exist in the CD data. These cases essentially follow the same form as the Check-Out test cases.”

Summary

• Creating acceptance tests can yield additional ideas.

• Break acceptance tests into ones for business rules and ones for scenarios.

• Business rule tests verify all combinations.

• Scenario tests each instance where a business rule produces a different outcome.

• Determine the edge cases and how the system should respond.