Basic Acceptance Test Definitions
| Defining tests at this level is usually pretty straightforward. Tests often come to mind just by reading the story and posing the question "How could you tell if this was in the system?" Go ahead and write down what immediately comes to mind. It's probably going to be, at a high level, exactly what needs to be tested. If not, noting it is still productive, because you're going to learn something as soon as someone else sees it. With some experience you'll find this intuitive, but getting started can be intimidating, especially working within a short time window. If you have trouble coming up with acceptance tests for a story, try the following algorithm:
For instance, the story from Example 1 has just one action: Search. Example 2Of course, this was pretty obvious from the story (see Table 9.2). It's about searching. If you search for something that's there, you should find it. If you search for something that's not there, you'd better not find it. Yes, it's easy, but don't let that bother you. Remember, you'll be doing this right at the beginning, after having read the story for the first time, maybe on the fly during the release planning meeting.
Just because these are high-level tests doesn't mean they aren't useful. When these tests pass, you'll have demonstrated one case where you can search for something that exists and find it, and one case where it doesn't exist and you don't find it. On the other hand, if these tests fail, you know without a doubt that the story isn't finished. For a traditional software development project, this would be a long way from saying the story is acceptably implemented, because of all the low-level defects in the code when tests like this are run. The fact that one search returns results when it should and another doesn't when it shouldn't doesn't provide much confidence in that case. The code on an XP project will be much cleaner by the time you run acceptance tests on it. It'll be doing what the programmers intend it to not just programmers individually but with a separate pair of eyes verifying each assumption, confirmed by a 100% pass rate on the unit tests. You'll be adding additional cases with more detail later but not nearly what would be required for a traditional software project, where the acceptance tests often do the job of unit and integration tests as well. Even defining acceptance tests as simply as in Example 2 will generate beneficial discussion during release planning. Take, for instance, the "empty list" result when no businesses match the specified category and location. The customer is likely to pick up on this and ask what, exactly, an "empty list" is. Does it mean no response at all? How will the user know the request has been processed? How about some kind of message like "No business matched your search criteria. Please try again"? How about some suggestions of related categories for which the database contains businesses? Don't feel that all these questions need to be answered at this point, or even documented. What's important is that they become part of the team's public discussion rather than being privately interpreted in different ways by different members. The discussion is the key element. We may decide that having the search respond with suggestions of related categories is too expensive at this point and we're not going to do it. We've still accomplished something by bringing the questions up early and discussing them. Another thing we can accomplish with these high-level acceptance tests is making the hidden assumptions visible. As we discussed in the previous chapter, once these have been identified, one approach is to write them right into the stories. This works just fine in some cases. For others, hidden assumptions might affect more than one story, or including them may make the story too long, or you might find it hard to phrase the assumptions correctly within the story. In these cases, it's often quicker and easier to define the assumptions as acceptance tests. For instance, we can take the assumptions we identified in Example 1 and add them to the base acceptance tests for the story. Example 3This isn't difficult if you don't get hung up on the details (see Table 9.3). Notice that in both Examples 2 and 3, we're not trying to define how we're going to go about performing the test. We don't, for example, need to worry about whether we have to log in to the system first, or how long the fields on the search screen are, or exactly what a location is, or what information is included in the list for a matching business. Likewise, we're not trying to specify any particular values of test data we're just saying we want some with this type of characteristic (searches with hits) and some with that (no hits, more than 20 hits, and so on). As soon as we get a chance, though, we're naturally going to start thinking about how we're going to simulate 6,000 concurrent users or make up searches with a misspelled category and determine if the returned list contains the right one. Similarly, the programmer will be thinking about how to write the code that makes these tests pass, and the customer will be thinking about what else has to work before it's acceptable. We want these things firmly in mind when estimating during release planning and also later on in iteration planning. We'll think them over while we're enjoying our first lunch break on our test drive.
This is actually a lot of tests for one story. We're doing this for the sake of example. In a real project, we'd start with a much smaller story, probably just basic search functionality. Things like searching within results and suggesting other searches need to be separate stories. We could write stories about handling load and performance now, but they'll probably be implemented in a later iteration. If stories that came out of release planning discussions are still too big in scope, defining the high-level tests will help show your team where you need to break them into smaller chunks. In the next chapter, we'll discuss estimating the time for the acceptance tests. |
EAN: 2147483647
Pages: 238