Exercise 3 ( Chapter 9 )


Exercise 3 (Chapter 9)

Q1:

Define high-level acceptance tests for the following story from the XTrack application (same project as Exercise 2 in the previous chapter). Don't look for hidden assumptions; just do it based on the bare bones of the story:

Story: The user can provide an estimate for how long it will take to implement a story, prioritize the story, and assign the story to an iteration.

A1:

Based on the bare bones of the story, we came up with just one test:

Test for Exercise 3.1

Action

Data

Expected Result

1. Update story with estimate, priority, and iteration

A story already added to the repository, estimate, priority and iteration number

Success: story is updated with appropriate information

Q2:

Use the technique from the previous chapter (or your own) to identify problematic hidden assumptions in this story and define additional acceptance tests that make them explicit.

A1:

Assumptions

We used the method from Chapter 8 to come up with the following (see below for the details):

  1. The system provides a list of stories not already assigned to an iteration.

  2. The system provides a list of the stories assigned to a particular iteration.

  3. The system provides a running total of estimates for all stories in an iteration.

  4. Estimate, priority, and iteration number aren't required fields.

  5. The user can list stories and see the current values for estimate, priority, and iteration.

  6. The user can select a story for update and update these fields at any time.

  7. The system will not validate for duplicate story names. It's up to the user to make sure names are unique.

Additional Tests

Based on the assumptions, we came up with the following additional tests:

Additional tests for Exercise 3.1

Action

Data

Expected Result

2.

Existing story, no values entered in iteration, priority, or estimate

Success: these aren't required fields

3.

Existing story, exceed maximum values for estimate, priority, and iteration

Failure: should not be able to enter a number that large

4. Add a new story with estimate, iteration, and priority

New story with valid values for estimate, iteration, and priority

Success: story is added with appropriate information

5. Search for stories not assigned to an iteration and select one to update

Search criteria and existing stories with nothing in the iteration field

Success: stories are listed with current values for estimate, priority, and iteration. When user clicks on story name, story fields appear on update screen and are modifiable.

6. Search for stories assigned to an iteration and select one to update

Search criteria and existing stories for a particular iteration

Success: stories are listed with current values for estimate, priority and iteration. When user clicks on story name, story fields appear on update screen with current values and are modifiable.

Details of how we identified assumptions:

Step 1: Customer view

  • I'm the customer. How does this relate to my project? We need a way to track estimates for stories, to help with choosing stories for an iteration. We need to be able to track the stories included in an iteration and know what progress we're making, based on the estimates. Priority will help us decide which story to start first. We could use the priority field outside iteration if we wanted to prioritize the stories in advance, to make choosing stories for the next iteration go faster. But we may want to change our minds at any time.

  • What business problem is it solving? How does it solve it? Customers need to know how much a story costs before they can choose stories for an iteration. The team needs a way to prioritize and track the stories within the iteration. By storing this information online, it's available to the whole team, even if we're not all in the same room. It's also easily available to management. The online screen can list all the stories available to the iteration, those assigned to the iteration, and totals of the estimates.

  • How could the system implement this and not solve the problem? As with Exercise 2, this story gives us a way to estimate a story and assign it to an iteration, but someone still has to input and maintain the online data. Some stories may not have estimates yet. That's why it has to be easy to update the priority, iteration, and estimate. None of these fields can be required, because we'll have stories for which we don't know this information yet.

  • Are there alternate solutions? Are there related problems? We could put the information on a whiteboard, story cards, or a spreadsheet, but that makes it harder to share the information with others who aren't in our location and has the same problem of needing to be kept current.

A2:

Step 2: User view

  • I'm a user, searching for information about a story or release. What are the worst and best things that can happen? What would really irritate me?

    Worst thing: I can't locate the story or iteration I want it's in the system, but I can't find it. I can't figure out how to assign a new story to an iteration. Two stories are similar I can't tell which one I want.

    Best thing: I can see all the stories for an iteration and all the pertinent information about them online and select the one I want from a list.

    Irritating: How, exactly, am I locating the story? Can I search by iteration? By name? By number?

  • How can I screw up? How should the system respond? Can I accidentally assign the same story to more than one iteration? Assign the same story twice to one iteration? Is it worth having the system prevent me from doing that, or do we think the few people using this system will be able to avoid that kind of mistake?

  • How often will I do this? What will I do before and after? During release planning, we'll write the stories and estimate them. During iteration planning, we'll choose the stories for that iteration and prioritize them. Or maybe we'll prioritize them outside of iteration, as an aid to choosing stories for future iterations.

A3:

Step 3: Programmer view

  • I'm the programmer. What's the simplest implementation that could possibly work? A list of all the stories, with columns for estimate, iteration, and priority. Click on the story to select it to update these fields. We need some way to identify the iteration, probably by number.

A4:

Step 4: Identifying the mismatch

  • How likely is the implementation to solve the business problem? Fairly likely.

  • How likely is the implementation to solve the related problems? We need to be able to unassign stories from an iteration, in case the customer changes his mind or we can't complete all the stories.

  • How likely is the implementation to avoid irritating the user? Respond appropriately to user mistakes? As with Exercise 2, we aren't likely to have a lot of user mistakes, but we want to accommodate our managers who just want to get the high-level information.

A5:

Step 5: The assumptions

See Exercise 3, Step 5.



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net