Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

I am a developer in the scrum master role and need to get the whole team (specially our product owner) more involved with clearly defining the boundaries of stories. I suspect acceptance criteria is the way to go.

In our team, we struggle to define clear acceptance criteria while grooming/planning our user stories. This alienates our QA members as they don't really have complete understanding of what to test. Often, our acceptance criteria defines what we expect the story not to be, rather than what it should be and this feels wrong.

Are there any good resources on how to come up with good acceptance criteria? I've found a lot on how to write effective user-stories, but nothing specific to acceptance. Does anybody have any ideas of how to approach the problem or resources I could use?

share|improve this question
1  
As a QA person in that position, I write down my best guess at the acceptance criteria, and run them by the developers for validation. Do your QA members do that now, and if so, what feedback do they get? –  user246 May 13 '11 at 15:42
    
They don't do that now. I'll suggest it for the upcoming sprint. Sounds like an easy way to start. –  ale May 13 '11 at 16:38
add comment

2 Answers

up vote 7 down vote accepted

There is a concept of "steel thread" that we used back at one of my previous jobs where the user story itself is a specific requirement that has a very particular expectation. Anything outside of that particular expectation should be its own user story. The acceptance tests can then be focused and targeted to verifying that the user story's "steel thread" has been verified. This doesn't mean that there is only one acceptance test, but that the acceptance tests that are written cannot go outside of that limited scope of the "steel thread".

When you get to acceptance tests that defined what is NOT supposed to happen, that actually, in my opinion, should be its own user story.

For example, a user story may read:

"As a web master, I can configure widget B to display in one of the three primary colors of blue, red, and yellow"

A set of acceptance tests would be:

  1. The web master has access to the configuration options for widget B
  2. The web master has a selection list available of the three primary colors of blue, red and yellow
  3. When the web master sets widget B to blue, it displays in blue
  4. When the web master sets widget B to red, it displays in red
  5. When the web master sets widget B to yellow, it displays in yellow
  6. The web master has no other options other than blue, red or yellow

That would be it. If, however, you need to check and make sure no one else has those abilities, you should write a different user story to say:

"As a web user, I do not have access to widget B's configuration options"

And then write appropriate acceptance tests.

The bonus of this approach is the granularity of requirements so you can easily prioritize those stories you MUST do and backlog those that can wait and then maintain focus among your developers, testers, and product owners to ensure that the user story is completed in any particular iteration without any unnecessary bleed over.

Edited: Added acceptance test 6 as an example of one acceptance test for "It shouldn't do this" that would be valid within a user story. The user story indicates the three primary colors. There should be no other options available. The user story does NOT mention anything about any other users, configuration options for any other widgets, or anything else like that so those are then relegated to different user stories.

share|improve this answer
1  
I like the idea of the "steel thread". I started under the assumption that our user stories were good enough, but maybe we need to start from there. If the user story is good, coming up with the acceptance is easier. Thanks, taking it as an answer, it gives me something to work with. –  ale May 13 '11 at 16:42
    
I've found that, when using this methodology of softare development and design, the user story is definitely the key. Get a good handle on that, and everything just falls into place. If the user story is too general, you end up getting bogged down and dragging out development. If it's too specific, then you get bogged down in a lot of little detailed stories. Finding that balance is key. –  TristaanOgre May 13 '11 at 16:54
add comment

We keep it simple: I either ask the support manager or cull through customer bugs. The ones that sound like they would apply to 80% of the customers I try to work into my test scenarios in acceptance (or smoke) testing.

share|improve this answer
    
For creating acceptances tests for new features, I'm not sure how researching past bugs will help a lot in creating those acceptance tests. While it may help in understanding pit-falls experienced in the past and, therefore, informing other areas of the process (design, additional user stories, etc), writing acceptance tests for a specific user story I think should be linked to the expectations of that user story. –  TristaanOgre May 13 '11 at 15:48
    
Agreed on new features. I was referring to test scenarios in general. –  Laura Hensley May 13 '11 at 15:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.