Appendix D. Tables Everywhere

“It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

Abraham Maslow

“Everywhere around the world

There’ll be dancing

They’re dancing in the streets”

Marvin Gaye, William Stevenson, and Ivy Hunter

Tables can be used to drive manual acceptance tests and to clarify not just functional requirements, but quality attribute requirements.

User Interface Tests with Tables

In Chapter 4, “An Introductory Acceptance Test,” Debbie and Tom presented the test cases used for a discount business rule. The cases were as follows.

That chapter presented several ways to execute the test. One way was to use a test script for the user interface. No test script was presented in that chapter. You could express the test script with tables that give the information needed to run the test. For example, the following tables have the setup necessary for all the test cases and an example of the table flow for the first test case.

The setup for this test could be part of a standard setup for all the tests for the system. It would usually not go through the user interface but be a programmatic setup, as shown in Chapter 31, “Test Setup.”

You could execute this test manually or automatically. When driven manually, the tester should be able to determine from the screens how to enter the information in this table. If not, the user interface probably has issues.

As an automatic test, each table could be associated with a script that drives the corresponding user interface screen. These scripts could then be reused in other tests that employ the same tables with the same or different data.

Requirement Tables

The original requirement for the discount was expressed in textual form. The requirement itself could be put into a table for clarification [Parnas01]. Here was the original discount business rule:

If Customer Type is Good and Item Total is less than or equal to $10.00,

Then do not give a discount,

Otherwise, give a 1% discount.

If Customer Type is Excellent,

Then give a discount of 1% for any order.

If Item Total is greater than $50.00,

Then give a discount of 5%.

In table format, this rule could look like one of the following tables. The form of the table should be whatever is appropriate to the problem, as discussed in Chapter 21, “Test Presentation.”

Or it might be like this.

The table format clarifies what was potentially unclear or ambiguous in the text. For example, the “any” of the original text statement appears more unclear when it is placed in this table. In addition, filling out the tables may bring to light suppressed premises, unstated requirements, or assumptions. In this example, having a column for Type may suggest that there are other types for which the discount rule may be applicable. For example, is there a regular customer who is neither good nor excellent? If so, there needs to be another entry, such as this one.

Another Table

To be complete, the discount percentage example assumes that a customer has a rating of Good or Excellent without specifying how that rating was arrived at. The separation of concerns of what discount to apply from the determination of the customer type makes the tests for both more robust.

Similar to what was done in Chapter 13, “Simplification by Separation,” here is a business rule for determining the customer rating.

When rules are expressed as tables, making up the tests often is straightforward. In this example, you simply create tests at each of the transition points between each rating.

Now you need a test that shows that the Total of Orders for a particular customer is correct. Creating tables showing a set of orders for customers that total up to the amounts in this table is left as an exercise for the reader.

Quality Attribute Requirements

You can use tables to indicate the required quality attribute measures that an application must meet. For example, in Chapter 12, “Development Review,” Tom showed a table for performance of check-outs.

If platform capacity was a constraint, the triad could create a resource table, such as this one.

Data Tables

Can you use the customer tables as the data? Sure. You need to have a translation mechanism, but that’s fairly simple. For example, Chapter 10, “User Story Breakup,” had a table for rental rates.

This table could be the actual source for the rates. The program would read this table and use the values as the rates. If Sam wants to change the rates, he just changes this table and tells the program to reread it.

Summary

• You can use tables to drive user interface tests manually or automatically.

• Use tables for requirements for clarification and to expose unexpressed details.