Scrum: Should user story acceptance criteria be mapped to test cases?

Question

Should the acceptance criteria for a user story form the basis for the test cases when testing that feature?

Or, should there be a separate story for testing, whose acceptance criterion is that the feature being tested passes the relevant section of the function specification?

For example:

Story: As a user, I want to click a 'Show Map' button which will show a Google Map with the reported address marked, so that I can visualize where the event is occurring.

What might the acceptance criteria be and how would this relate to the testing?

Answer 1

TL;DR

The acceptance criteria should be part of the feature story and be the basis for the test cases. There shouldn't be a separate test story, they might be a subtask of the story!

Long answer

Should the acceptance criteria for a user story form the basis for the test cases when testing that feature?

Of course they should be! You define which criteria have to be met, that the story fulfills its use case. These criteria should be tested to make sure the story is done. This means you have to implement different kinds of tests (unit tests, regression tests...).

Or, should there be a separate story for testing, whose acceptance criterion is that the feature being tested passes the relevant section of the function specification?

The Scrum guide is really clear about that, when defining the term "Done": "Each Increment is ... thoroughly tested, ensuring that all Increments work together." Meaning that the story is complete, when all tasks are done - including testing. So no extra story or even an extra team for that!

Example

What might the acceptance criteria be and how would this relate to the testing?

I modified your story example by removing implementation details, there should only be customer need described. The "Click-part" has been move to the acceptance criteria.

Story

As a user, I want to be able to display a map with the reported address marked, so that I can visualize where the event is occurring.

Acceptance criteria

• There is a button 'Show Map' to open the map view (Google maps)
• The reported address is marked on the map
• If there is no address marked, the button is disabled
• ...

These criteria should now be tested, try to think about sunshine scenarios and common errors - don't forget the edge cases.

I don't know your application, so I try to keep it generic. You have some kind of user tests, where a team mate clicks through the app and clicks the "Show Map" button (marked map appears). Another thing would be to make sure the google maps api is able to understand your address format (might be automated) or you tests whats happening if Google Maps is down. Furthermore you have some kind of unit tests, that might test what's happening when the address field is empty.

Answer 2

User story should write by focusing on business value rather than functionalities.

E.g. As a user, I need option to see event location in Google map so that I can visualize the location.

You can write specific features which user is expecting as acceptance critical.

E.g. Map should display/pop-up once user click on "show map" button.

Testing team can test individual acceptance criteria when they are testing the story.

E.g. Tester can click on the button to verify that map is showing property.

Answer 3

What's the difference to user stories then?

You could also define following user stories instead of "acceptance criteria":

• As User I want a button 'Show Map' so that I can open the map view (Google maps)
• As User I expect that the reported address is marked on the map
• As User I want the 'Show Map' button to be disabled, when there is no address marked

Makes it easier to plan, prioritize, and track implementation.