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
Context : A team working in agile , on an complex Front end Application.
Question:How an team working in agile come up with a definition of common guiding "entry criteria" for testing to decide when user stories should be rejected right away when not meeting the basic conditions without performing any further testing.
Basic entry condition for the user story testing could be:
Agree on the basic conditions for criteria for all stories.
This 'meta' conversation needs to be had. It doesn't arise of its own accord, not being related to a ticket.
This is where leadership (at all levels) comes in.
Take charge of the situation, organize the meeting, get an agreement and then live by it.
The result of this is that future discussions can now be about the agreement, if its being met, if it needs to be changed, rather than trying to raise an issue about any given particular story.
Making something up, it could be:
etc.
Make sure the Behavior of users is the Driver of the Development process
See also https://www.mountaingoatsoftware.com/agile/user-stories for Mike Cohn's take on user stories
So basically you are looking for Definition of Ready if I understood the question correctly.
Usually the INVEST matrix is used for this: A good user story should be:
There is also a good take on it by Vojtech Barta called Parallel of Rally Dakar and Agile - rediscover of DoR & DoD where he gives examples on how to start the process of defining the DoR. DoR should not be set in stone but should evolve along with the team development process.
I think if the application is complex then its complex for both the testers and the developer so i think all the team members should work as across functional so this may solve the complexity of user stories and facilitate to understand user stories .
