Stack Exchange Network
Stack Exchange network consists of 181 Q&A communities including
Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
Visit Stack Exchange
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
Anybody can ask a question
The best answers are voted up and rise to the top
3 years, 11 months ago
One of the biggest problems from my daily work in the team is the acceptance criteria are mostly too unclearly defined. What this means in detail:
Stands inquiries, because the PO or a developer has expressed itself
in the acceptance criteria again wrong or too broad
Acceptance is sometimes very difficult because acceptance criteria
have to be added
Constant post-processing of test cases by supplementing or adapting
the acceptance criteria
I have addressed the topic several times in retroperspective, but so
far you can not adapt to it, or refer me to the Scrum process.
Despite my many years of experience, I am reaching my limits and unfortunately can not continue. Maybe you?
Apr 26, 2019 at 12:40
1,107 1 1 gold badge 8 8 silver badges 21 21 bronze badges
prevent them ? hmmm
how to write them the right way Educate on
why to write them the right way Dducate on
consequences of writing poor ones Have a review step before they are used
Create published standards
Agree to follow standards
Sep 24, 2019 at 23:32
Michael Durrant Michael Durrant
24.9k 3 3 gold badges 39 39 silver badges 112 112 bronze badges
The standard format to write a user story is below, but it does not guarantee that user stories would be written well. But it should be followed.
**As a < role >
I want to < do something >
So that < business value >**
Few suggestion you can try that I have followed in my software testing services organization.
Ask for business use case for each story from PO, it will help you to understand the real problem and you can relate the feature functionality with it.
Ask as many questions, when story reaches you
Ask for most-granular information in the story so you can estimate it properly
Ask for outcome (RESULTS) of acceptance criteria that is always testable with minimal ambiguity.
Ask your questions related to stories in sprint planning or product backlog grooming meeting, where stories are discussed
Create one liner short test cases, so you can change it later if required
Apr 26, 2019 at 13:39
755 4 4 silver badges 8 8 bronze badges
User stories are a good approach. have a look at the
INVEST pattern. it states that a story has to be testable. So when working at a story, it should be clear what to test and if the test succeeds, than the story is done.
If you then encounter changing acceptance criteria, treat it like a new user story. When you still feel an unreasonable test maintenance per story, you could maybe look for improvements in you test automation.
Apr 27, 2019 at 21:16
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our
Accept all cookies
Necessary cookies only