I guess how is this usually done? since a lot of times you don't get precise requirements from the client?

The User Stories change so often, and sometimes feel very vast. Is it typical to create an Acceptance test plans off of every User Story? ...especially when they aren't testable in the current states sometime.

2 Answers 2


The other thing that many companies neglect in Agile, Extreme and even Waterfall working is that you need to have a test section on board as well and while the developers are working to fulfill a given story point, feature or requirement the test team should be developing the tests, (in extreme these need to be developed before the developers start), and that in some industries the test team actually needs to be bigger than the development team. That said it is usually a good practice to rotate at least some of the development staff into testing this gives them insight into writing testable code and a break from coding.

In the agile model while the development sprint is addressing developing a given user story for development, (it can't change then otherwise it can't be developed), the test team should also be developing the tests, and agreeing with the product owner that the tests demonstrate that the story can be closed.

If the scope of a user story is vast then it is likely a spike so will need to go through a sprint to define it first after which it should be more testable.


There are a few clarifications needed here, before I can help you out in the right direction, as per your query.

1- Are you working in an Agile/Scrum model?

2- Why are the 'Requirements' unclear?

3- Why do the user stories change so often?

4- Why are the user stories so vast?

I think you may find that your testing is hampered, and you are being set up to fail by bad process.

In general, User stories should be small- less than 2 weeks worth of work to deploy to production. Requirements (acceptance criteria) should be clear and unchanging for the most part.

If these variables are controlled, you won't need acceptance test planning, just testing of the story to the satisfaction of the Product Owner so they may 'Accept' the User Story and deploy it to production.

Agile Testing

  • 1. Yes 2. I guess because the customers don't exactly always define them, and our team is new to the agile/scrum model...so there are a TON of user stories. 3. They don't change a "ton" so much as new ones get added a lot. 4. I feel like they are too specific but im not familiar enough with agil to know for sure
    – Mercfh
    Commented Sep 3, 2015 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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