Exercise 9 ( Chapter 15 )

Exercise 9 (Chapter 15)

Q1:

For the above story from the XTrack application, identify which of the following details you would a) assume responsibility for defining yourself, b) ask for confirmation on, or c) ask open-ended questions about:

• Constraints on the allowable inputs for start and end dates during update.

• What should happen when invalid data is input during update.

• The units in which to display the velocity, estimates, and actual totals.

• What determines that an iteration is complete.

• Which information will be included about each story.

• What happens when a story is moved from one iteration to another.

• Can completed stories in a completed iteration be moved to another iteration?

• The order in which the stories appear.

A1:

Item

Type

Constraints on the allowable inputs for start and end dates during update.

b

What should happen when invalid data is input during update.

b

The units in which to display the velocity, estimates, and actual totals.

c

What determines that an iteration is complete.

b

Which information will be included about each story.

c

What happens when a story is moved from one iteration to another.

a

Can completed stories in a completed iteration be moved to another iteration?

a

The order in which the stories appear.

b

Q2:

For the above story, identify some additional details based on

• The happy path

A1:

Happy Path

1. Add an iteration with start and end dates and projected team velocity. Select stories and associate them with the iteration. Verify the total estimates.

2. Select an iteration and update both dates and the velocity.

3. Update some stories in the iteration to mark them completed.

4. Update all the stories in the iteration as completed. Verify the total actual time for the iteration.

5. Display the iteration in read-only mode.

Data conditions for happy path:

1. Remove a completed story from the iteration. Verify that total actual time and total actual velocity are updated accordingly.

1. Add or update an iteration, enter alpha characters in the velocity field.

2. Add or update an iteration, enter alpha characters in the date fields.

1. User clicks to save an iteration with no data in any fields.

2. User adds an iteration, clicks the Back button in the browser, updates the data to add another iteration, clicks to save again.

3. User who is not authorized to add or update iterations enters the URL for the update or add page.

4. User enters every special character on the keyboard into the data fields.

1. Maximum database connections exceeded.

2. Server goes down in the middle of an add or update.

Q3:

Based on risk, where would you focus the most attention in designing tests for the following first four XTrack stories?

 Story 1: Be able to create, read, and update a story via a Web interface. The data fields in a story are number, name, author, description, estimate, iteration, timestamps, and state.

 Story 2: 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.

 Story 3: The user can create, update, display, and delete a task. A task has a name, a description, assignee, estimate, actual time spent, state, and created/updated timestamps.

 Story 4: The user can display and update information about an iteration. The iteration display shows the iteration start and end dates, the projected team velocity, all stories assigned to the iteration, and the total of the estimates for those stories. For completed iterations, it displays the sum of the actuals for each story and the actual team velocity for that iteration. The user can update the estimated velocity, start date, and end date.

A1:

We've found it best to concentrate on two types of outcomes when identifying the areas of risk: the worst possible outcomes and the most likely (though not necessarily worst) bad outcomes. To do this, we need to look at the system's intended purpose, how it could fail, and the impact of these failures.

The XTrack system has three major purposes:

1. Allow the team to track stories, tasks, and estimates while working on them

2. Provide snapshots of the project's status to management and other interested parties

3. Capture a record of what happened for retrospectives at the ends of iterations, releases, and projects and for "tuning" the XP practices

In our opinion, the first purpose is the least important, because an Extreme team will have simpler mechanisms that work as well or better (story cards, standup meetings, pairing, and so on). Likewise, the second purpose can be handled by judicious involvement of the interested parties in standup meetings, by providing periodic briefings, or by writing status reports. If the XTrack system fails to fulfill the third purpose, however, retrospectives will have to rely only on team members' memories, which will become increasingly unreliable about the earlier iterations as the project continues.

So we think the worst thing that could happen would be for the system to fail to provide historical data for retrospectives and tuning. This leads us to focus on the system's capability to retain whatever data is entered and to reproduce it accurately when needed. Although each of the first four stories involves this kind of function, story 4 addresses data entered in multiple places: the story description, title, and so on from story 1, the estimates and iteration assignment from story 2, and the actuals from story 3.

In terms of the most likely (though not necessarily the most serious) failures, our experience with this type of system is that problems usually arise when validating input fields. Some of these won't matter: who cares if the title contains a misspelling, for instance?

On the other hand, consider the state field in story 1. If this field determines whether the story displays or is counted into the totals of an iteration, then not validating an incorrectly typed state could cause the iteration totals and velocity calculations in story 4 to be wrong. Likewise, failure to validate a numeric input for an estimate or actual (a negative number, for example) could have the same result.

Based on this, we would focus our attention on designing tests for story 4: validating that all the stories assigned to an iteration show up on the display, that the totals are correct for estimates and actuals, and that velocity calculations are correct. Examples might be sad and bad path scenarios where stories are assigned to iterations with bad state values or negative estimates or are moved back and forth from one iteration to another.

Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238
Similar book on Amazon