Chapter 8. Test Anatomy

“Whoever named it necking was a poor judge of anatomy.”

Groucho Marx

Tests for scenarios are now developed (see Figure 8.1). The basic structure of tests—given, when, then—is explained. Examples are shown in tables and text.

Figure 8.1. Creating Tests

---

Triad Creates Tests

All three members of the triad create tests. The customer usually leads with examples for the basic workflow tests, and the developers and testers come up with ones from their training and experience. Testers are responsible for ensuring that there is a set of tests that is as complete as practical. For example, Tom might envision more tests that can be run for the use case in the previous chapter:

Ideally, the triad should come up with all tests prior to Debbie starting to implement the story. But sometimes, they may discover a test during implementation or later. During exploratory testing, Tom or the team may discover missed conditions or other issues that suggest new tests. If the need to create tests post-implementation occurs frequently, the team should investigate the root cause.

---

Test Context

A system’s operation is defined by its inputs and its outputs, as shown in Figure 8.2. This is a context diagram. What is external to a system is outside the circle. These externalities define the context in which the system operates. An input or sequence of inputs should result in a determinable output. For example, if the clerk inputs a rental for a particular customer and a particular CD, the output should be a rental contract. If the clerk inputs another rental for the same CD without its being checked in, he should get an error.

Figure 8.2. Context Diagram

The response of the system is different the second time someone tries to rent the CD, because the system has stored (that is, made persistent) the rental information for the first check-out.

A system can store the rental data internally or externally. If it stores the data internally, it changes the internal state of the system. If it stores the data externally, the data is simply another output and input to the system.

For Sam’s system, the data will be treated as internally persistent. Renting a CD the second time causes a different output because the state of the system is different. Part of a test involves specifying what the current state of the system is.

---

Test Structure

There is a basic flow to a test, shown in Figure 8.3. The test starts with setting up the state of the system. Then a trigger occurs—an event or action is made to happen. The test has an expected outcome of that event—a change in the state of the system or an output from the system. The test compares that expected outcome to the actual outcome of the system under test. If the two are equal, the test succeeds; otherwise, it fails. The flow is often shown in text like this:

Figure 8.3. Test Flow

For simple calculations, like the discount in Chapter 4, “An Introductory Acceptance Test,” the action is just calling some module to perform a calculation. So the form could look like this:

The computations looked like this.

So a single test case could be as follows:

In the discount example, there are six combinations of values for the input. Each combination (or row in the table) is a test case. For something like a calculation, the group of these test cases can be referred to as a calculation test or a business rule test.

The flow for the tests for Check Out CD would be something like this:

There can be multiple ways to flow through a use case. Each exception or alternative in a use case is called a scenario, because there is a different flow. For each scenario, a different test scenario is needed that has a different setup or a different action. A test case is a test scenario with the actual data. The term acceptance test, as used in this book, may refer to a single test case or a group of test cases for either calculations or scenarios.

Business rule tests are usually not as complicated as test scenarios. The business rules often have no initial state setup, and the verification is simply comparing a single result to the expected result.

Because a test scenario is more complicated, you should not duplicate it just for a different business rule case. Separately testing the business rule can reduce the number of test scenarios that need to be written.

When writing a test, use the same domain language you use to write up the stories. The consistency reduces misunderstandings. If you discover during the test writing that the terms are ambiguous, go back and fix the glossary and the stories.

To complete a test case, the case needs values that are setup, input, and output. These values can be specified in tables or in text, whichever way the customer prefers.

Customers who have experience with spreadsheets may like having the values in tables because that is more familiar. Tables come in many forms. Three common ones are the calculation table, the data table, and the action table.

Calculation Table

The table structure used in the previous discount calculation example in Chapter 4 followed this form.

This structure is used primarily for calculations.¹ A question mark (?) appears after names that represent outputs. Following is an example of this table with only one input and one output.

The name of the input is CD ID, and the name of the result is Rented. The value for the input is CD2, and the expected output is No.

Another example of this table is the one that was used for discounts. The two input names are Item Total and Customer Rating. The result is Discount Percentage. The input values are $10.00 and Good, and the expected output is 0%.

Data Table

Another table structure declares that information in the system exists (or should exist). Part of the name of the table can indicate that it is a data table rather than a calculation table.

Here’s an example for customer data. This shows that there should be a customer whose name is James and whose customer ID is 007 and a customer named Maxwell whose customer ID is 86.

The columns represent different fields in a data record, and each row represents a data record. But the table does not have to correspond to any specific database table. It can represent any collection of the data items. It is the user’s view of how the data elements are related, regardless of how they are stored. If the table is used for the setup part of a test, the data is put into the collection, if it does not already exist. If the table is used as expected values, the test fails if the data items do not exist in the collection or have different values.

There is a variation of the data table that shows only rows that meet certain criteria. The criteria are specified after the name. For example, if you only want to see customers whose names begin with J, you could have the following.

Action Table

The third table structure is an action table. The easiest way to describe the table is that it works like a dialog box, although it can be used for other purposes. If a team member needs to visualize a system through a user interface, an action table can often stand in for a dialog box.

The table starts with a title that represents a procedure or the name of a dialog box. The first column has one of three verbs: enter, press, and check. Each verb has an object that it uses. Enter enters data into an entry field; press initiates a process, such as a Submit button on a dialog box; check sees if a result is equal to an expected value.

Following is an example for Check Out CD.

Some people are horizontally oriented. Others are vertically oriented. The action table can be represented horizontally. If there is a repeated set of actions, using the previous layouts requires repeating the value names. So sometimes a table that looks like a calculation table is used for actions. For example, if a customer checked out two CDs, it could look like this.

---

Tests with Example Values

Tom starts off, “Let’s put some data into the test structure. Cathy, can you give me an example of a rental?”

Cathy puts up some values on the whiteboard. After the triad discusses them, they come up with this test:

Tom says, “The rental contract shows the information that will be printed on the form, but not all the surrounding text. This way, you can be sure that the correct information is on the contract. Later on, you can decide with Sam how the rental contract should be worded.”

Requirements Revised

“Now that you can see how the test is structured, does it look like anything is missing?,” Tom asked.

“Yes,” Cathy replied. “The tables definitely make things more apparent. Every CD has a rental period. If the customer returns the CD after the end of the rental period, we charge him a late fee. The rental contract should have the date of the end of the rental period. We also want the rental fee itself on this contract, but I think we covered that in another story.”

“Okay,” said Tom. “Let’s revise the tables to include this rental period. Let me make sure of something. To get the date for the rental period end date, you add the rental period to the start date. Is that right?”

“Sure,” said Cathy.

“Okay, so let’s make up a quick table to check out both the calculation and our terminology,” Tom stated. The triad came up with this.

Cathy says, “It looks like Tom came up with some odd cases. Thinking about leap years is not something I would normally consider.”

Tom continues, “So you want the rental due date on the rental contract. I guess we should keep it with the CD as well so we know when it’s due. I just have a feeling from the bigger picture—the Inventory Report story—that it would be a good idea. Because that story is coming up soon, it’s okay to consider it now as part of our big picture scope. “

Acceptance Test Revised

Tom continues, “So given that we have that simple calculation correct, what our tests need to do is set the current date. We do not want to have to change our test just because the date has changed. I’ll show how we set a date here and talk about it more when we discuss test doubles [see Chapter 11, “User Story Breakup”]. So the test could now read:”

The example tables have been presented with formatting that distinguishes between the column headers and the data. The formatting is not mandatory. When coming up with these on the whiteboard, headers are not bolded. Teams take pictures of the whiteboard, transcribe the information into tables, and have the customers review them to make sure no errors crept in.

---

Test with Values in Text

Some triads use what looks like regular text to specify the tests. So they might write something that looks like this:

There is a table form that is halfway between the text and a table [Martin02]. The entry field names and the values are in a single row. An example of this layout for the When part of the test looks like this.

The examples of tests in this book are presented with tables. It is usually easier to translate a table into narrative text than it is to do the reverse. For business rules, such as discount percentage, that have multiple test cases, it is usually less repetitive to express these cases in a table, rather than in free text. The names and column headers, which represent the domain language [see Chapter 24, “Context and Domain Language”], are separate from the values. This can make it easier to check for consistency.

---

When and Where Tests Are Run

The acceptance test for the Check Out CD test can be on multiple levels. It can be run as a user acceptance test through the user interface. It can also be tested though the middle tier by simulating the input from the user interface.² Or a unit test can be written to ensure that the rented value is changed to Yes when the check out occurs.

---

Summary

• The structure of a test is

• Given <setup>

• When <action or event>

• Then <expected results>

• For calculation tests, the structure is

• Given <input>

• When <computation occurs>

• Then <expected results>

• Following are three types of tables:

• Calculation—Gives result for particular input

• Data—Gives data that should exist (or be created if necessary)

• Action—Performs some action