Chapter 19. Triads for Large Systems

“It always takes longer than you expect, even if you take Hofstadter’s Law into account.”

Douglas Hofstadter

This chapter shows how larger systems can have more and different triads. Some projects do not require new customer acceptance tests. This chapter also examines a lack of acceptance tests.

Large Systems

Sam’s system had just two people, Debbie and Tom, as developer and tester. Debbie was an omnipotent developer. She did everything from creating the overall architecture to designing the user interface to administering the database. Tom did all sorts of testing, from helping with acceptance test development to running performance testing tools to checking usability and performing exploratory testing. Teams for larger projects are sometimes composed of such ambidextrous individuals. But often the range of technology involved and the scope of the project do not allow individuals to cover the entire gamut of development and testing. Nor does a single customer, such as Cathy, know every detail about what needs to go into the system. Subject matter experts specify the requirements in their own particular area of expertise.

The triad still exists, just with different people. It becomes the subject matter expert, the developer (or developers if you are doing pair programming), and the functional tester (or people whose focus is one of these roles). They develop acceptance tests for the particular stories or requirements with which the expert is familiar.

For projects with larger implementations, teams often have an architect or technical lead focus on the overall structure of a system to keep it consistent with other systems. The system may encompass a single application or multiple applications.

For teams like this, you have another triad: the architect, developer, and tester (see Figure 19.1). The architect, Al, helps the developer unit make design decisions that are consistent with the larger picture. The three work together to determine a system’s modules and their interrelationships. The responsibilities of each module are specified with acceptance tests, like the ones Debbie created in Chapter 16, “Developer Acceptance Tests.” The triad develops these tests collaboratively. Because all involved people are of a technical bent, the tests may incorporate many non-customer-related terms. But everyone in the triad needs to understand the terms and their implications.

Figure 19.1. The Technical Triad

Some tests for the modules are derived from the customer acceptance tests, just as unit tests are derived from them. The process of deciding how many modules are required and which modules are responsible for fulfilling which parts of the acceptance tests is a major facet of the architectural design process. This process is covered in other books, such as [Fowler01].

One key that the team should focus on is getting an end-to-end system working soon after the start of the project. One customer acceptance test should be demonstrated on the entire system. The feedback from the ease or non-ease of developing for that test can yield helpful information to the triad as to whether a particular architecture is suitable for the project. It also gives a baseline against which to measure additions. When a new story is implemented, a customer acceptance test may fail because an implementation changed its behavior. If the behavior represented by the test is still required, the triad can review and possibly revise the architecture. This is before much work has been spent writing code dependent on the architecture.

With larger systems, you may have a database architect, Dana. Dana creates the persistent storage that multiple applications require. She ensures that there is no redundancy of information, such as storing a customer’s address in two different places. A different triad—the developer, the tester, and Dana (see Figure 19.2)—works to ensure that the developer has a way to make persistent all the information needed to solve the story that the developer is working on. This collaboration operates the same way as the customer-developer-tester triad. Debbie states what she needs and creates an acceptance test. Dana delivers the persistence methods required. Tom may suggest additional tests. Again, the three people in the triad may not have these titles; they are just the roles they play.

Figure 19.2. Another Technical Triad

As we have seen, the triad concept can work all the way up and down the chain, from an overall software application down to the individual modules. The triad consists of the requester, the implementer, and the tester who ensures that all bases are covered. The triad is meant as a minimum for the number of people in collaboration. You may have a quad, a penta, or a larger group as required. However, it is often the case that the larger the group, the less members interact and the less effective they are. So limit the number to those actually required rather than those who just have a possible “want to know what’s happening.”

When a Customer Test May Not Be Required

Sam’s business is booming. He now rents not just CDs, but electronic books, videos, and games. He has bought up a number of competitors. So now Al, the architect, has the work of keeping a large set of diverse programs working together. Al needs to combine systems so that the counter clerks use the same system if they switch stores. The combination involves taking the data, such as customers, from one system, and converting it to another. There are projects like these that may not necessarily involve new customer acceptance tests.

Data Conversion

Al and Dana work together on the data conversion project. This conversion is a mostly technical project, not a customer project. Al will be the one to write the acceptance tests for the conversion. He will specify the measures of the cleanliness of the conversion. For example, he may create the rules to determine that a customer who resides on two systems is a duplicate. Al knows that Sam does not want a customer showing up twice on the converted system.

There may be some business issues, such as differences in customer status from one system to another. For example, Sam’s business rule for allowing someone to reserve may be different from the business rule for an acquired competitor. You can keep track of where a customer came from and incorporate both rules. But that is Sam’s call.

There should be no new customer acceptance tests, because they have already been created for the working system. The only exceptions would be tests that check that the business issues, such as customer status, have been appropriately handled.

Database Conversions

Dana has been informed that there is not going to be support for the current database version that Sam’s systems use. Dana needs to convert to the next version, or perhaps to a different system. This is not a customer need, but a technical issue. There are no new customer acceptance tests because the behavior of the system should not change. All acceptance tests can work as a regression suite. When the conversion is complete, the tests should still run as before.

If a project involves lots of stories for which there are no customer acceptance tests, it may well be a technical project. Often, large technical issues such as database conversion are incorporated into customer-focused projects. The customer often does not have knowledge of the underlying issues and therefore has no ability to provide acceptance tests. If this is the case, the technical parts should be broken into a technical project with a technical lead playing the part of the customer. Projects such as an upgrade to a new database, a new version of a language, or a new operating system are technical infrastructure issues.

What If There Are No Tests?

You have a system that has been acquired and for which there are no acceptance tests: no manual ones, and no automated ones. You need to make some changes, but what can you do? Let’s look at a couple of conditions. In one, you may acquire the system from a vendor; in the other, you may inherit it from an acquisition.

When you buy a vendor application, it may be configurable or customizable. Configurable means that you set up values to make the application run in your environment or with your set of data. The logic in the application uses this configuration information to alter its operation in predetermined ways. You may be able to add some additional features, such as a Microsoft Word macro, but these macros use existing operations. Because the vendor should have tested all operations, having acceptance tests is less critical.

Customizable means that you are provided with some source code for the system that you alter to make a system work for your particular purpose. The code provides some existing behavior that you are changing. In this case, you should ask the vendor for acceptance tests—either manual or automatic. The vendor response might be as follows:¹

• Don’t have any

• Have some, but all manual

• Have full set, but all manual

• Have full set: some manual, some automated

• Have full set, completely automated

If a vendor doesn’t have a full set, ask him how he knows the system works. It could be that he has a full set, but contractually he is not required to provide them to you. If you can’t find another vendor that will provide acceptance tests, you are in the same situation as from an acquisition.

You have to change an acquired system that has few or no acceptance tests in the area that you want to change. Chances are that the system has not been designed to be tested [Feathers01].

First, create acceptance tests for the functionality you are going to change. Inject the tests beneath the user interface if you can. Otherwise, run the tests through the user interface, and automate the tests if possible. Every test should pass as it documents the current working of the system. These tests will now run as a regression test. Create an acceptance test for the change you are going to make. Determine which of the current tests, if any, should fail once the change is made. Then implement the change and test.

Legacy Systems

One common issue with legacy systems is the lack of tests: both external acceptance tests and internal unit tests.² And often when there are external acceptance tests, they are not automated. Making changes in the system and ensuring that the changes do not have unintended effects is difficult.

Just as for an acquired system without tests, before making a change, create acceptance tests around the portion of the system that is involved with the change. The acceptance tests document how the system currently works. You sometimes have more control over legacy systems, then those acquired from a vendor. So the acceptance tests you write may be able to be run beneath the user interface.

Then write acceptance tests for how the system should work once the change is implemented. Initially, they should fail. Otherwise, the system is already doing what the change request asks for. The feature was just not documented.

In many instances, you may have to write the tests as user interface tests. If it’s possible, automate these tests. If the system design allows it, write the tests to the middle-tier layer and automate them. Then proceed with the change. When your new tests pass and any identified as “should break” fail, the system has been changed correctly.

Suppose you don’t have tests around every functional piece of the system. With the tests around the part of the system you are changing, you ensure there are no side effects in that part. But you cannot be sure that the change has not affected anything else.

Summary

• Larger teams have more triads consisting of the requester, the implementer, and the tester.

• Focus on getting an end-to-end system passing the simplest tests.

• Some projects are developer related and should have developer-created acceptance tests.

• If there are no acceptance tests for the portion of a system that needs to change, create acceptance tests before making the change.