Exercise 4 ( Chapter 10 )

Exercise 4 (Chapter 10)

Q1:

Define high-level acceptance tests for the following story from the XTrack application, using the techniques from the previous chapters or your own favorite method:

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

A1:

We came up with the following tests (the details are below):

Tests for Exercise 4.1
Action	Data	Expected Result
1. Add a new task	An existing story, values for the task fields	Success: the task is added
2.	An existing story, values only for task name, description, and state	Success: none of these is a required field
3.	An existing story, no values for task name, description, or state	Failure: these are required fields
4. Select an existing task and update	An existing task, new values for estimate, assignee	Success: task fields are updated
5.	An existing task, empty values for description, status	Failure: these are required fields
6. Select a task and click to delete	An existing task	Success: task is deleted

Details

Step 1: Customer view

• I'm the customer. How does this relate to my project? Tracking tasks is important to the success of the project. I always want to know how close the team is to finishing the iteration and whether it's possible for all the stories to be completed on time.

• What business problem is it solving? How does it solve it? Tasks can be tracked with cards or spreadsheets, but an online system works better if the team is not located in the same place. It will also retain important historical information for example, to see how accurate estimates are. An online system also allows stakeholders who aren't involved with the team on a daily basis to track the team's progress.

• How could the system implement this and not solve the problem? If the data is not maintained on a daily basis, it won't be useful.

• Are there alternate solutions? Are there related problems? We could put the data into a simple spreadsheet and put it on a shared drive on a LAN or put a link to it on a Web site. It would have the same problem of someone needing to keep it current and would take more work for users to find information.

A2:

Step 2: User view

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

  Worst thing: I can't locate the story or task it's in the system, but I can't find it. I can't figure out how to add a new task. I can't tell which is the task I want two tasks are similar.

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

  Irritating: How, exactly, am I locating the task? Can I search by story? By name? By number? When I add the task, is the system going to do a lot of picky field validation?

• How can I screw up? How should the system respond? What if I enter the same task name twice for the same iteration? Does the name have to be unique? Do any of the fields have special formats? Do I have to enter the timestamps myself, or are they automatically generated?

• How often will I do this? What will I do before and after? We'd need to update the information about a task on a daily basis. The tracker will get data on time spent per task from each team member and input it. Stakeholders who want to see the team's progress can see up-to-date information after a certain time each morning.

A3:

Step 3: Programmer view

• I'm the programmer. What's the simplest implementation that could possibly work? A form with text input fields for name, description, assignee, estimate, actual time spent, and state. Timestamps would be automatically generated. The user would select a story from a list and see a list of tasks. He would be able to click a button to add a new task or select an existing task to update it.

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 business problems? It doesn't really solve the problem of someone needing to keep the data current, wherever we decide to store the data.

• How likely is the implementation to avoid irritating the user? Respond appropriately to user mistakes? Fairly likely, as it's a simple application and users will be familiar with it. The biggest risk is for users outside the project team who want information and don't access the system as often. So we have to satisfy both "expert" and "occasional" users.

A5:

Step 5: The assumptions

• The system has fairly low transaction volume, used only by members of the project team, managers, and stakeholders outside the team. Team members will input the information; everyone will access the system for tracking and information.

• The user can find a task by selecting a story and browsing tasks for the story.

• The user can select the task from a list for updating or click a link to add a new task.

• Required fields are name, description, and state.

• All fields can be updated at any time, except timestamps, which are automatically generated.

• The system will not validate for duplicate task names within the story; this is up to the user.

• Name and assignee have a maximum of 50 characters. Description has a maximum of 4,000 characters. Estimate and actual time spent can be up to 3 digits long. State is a select list consisting of Started, Not Started, and Complete.

Q2:

Assume the programmers have estimated that it will take D ideal days to develop this (we're not going to tell you what number D is, so it doesn't influence your answer to question 3). Using the first method in this chapter, estimate the acceptance-test time (hint: your answer will be in terms of D).

A1:

This looks like fairly straightforward Web testing. The test data isn't hard to get. However, we're testing through the user interface, which is more work than testing at a lower level. Our estimate is that we'll spend 30% of the development time creating these automated tests. So the answer is 0.3D.

Q3:

Use the second method in this chapter to estimate the acceptance-test time in ideal days.

A1:

Test for Exercise 4.3
Action	Data	Expected Result
1. Add a new task	An existing story, values for the task fields	Success: the task is added

Estimate for Exercise 4.3 (in hours)
Test	Preparation		Execution		Special		Estimate
3	Define details	0.5	Setup	0.0
	Create test records	0.3	Run	0.1
	Automation spike	0.5	Evaluate	0.0
	Automation	0.3	Report	0.0
	Total	1.6	Total	0.1	Total	0.0	Total	1.7

All these tests look to be fairly similar, so we can use this same estimate for them, too, except we expect to save on the automation spike on all but the first. Here's the summary:

Summary for Exercise 4.3 (in hours)
Test	Preparation	Execution	Special	Estimate
1	1.6	.1	0.0	1.7
2	1.1	.1	0.0	1.2
3	1.1	.1	0.0	1.2
4	1.1	.1	0.0	1.2
5	1.1	.1	0.0	1.2
6	1.1	.1	0.0	1.2
				Total: 7.7

So the answer is 7.7 ideal hours, or about 1 ideal day.