User stories (also called requirements cards
) can play a useful role throughout the project lifecycle. They can help with the separate stages of planning, development, testing, and implementation. Ideally, user stories will be documented as early as possible in the project, because they help identify the scope and sequence of the project work. The user stories are then reviewed throughout the requirements process, with an eye out for changes to the feature or the business value that might impact prioritization, sequencing, and testing.
User stories can also help establish acceptance criteria for deciding which functionality must be delivered at each project milestone. In other words, the testing process must validate that the acceptance criteria meet the requirements established in the user story. The system testing process should also include validating that the feature has been delivered, and that the business value can or will be realized.
User stories cannot stand alone within the testing process. Typically, in addition to testing for required functionality, test cases will typically be built and executed to test around or outside the user story. These test cases might, for example, include negative testing, where the tester tries to do something the system shouldn't allow, to verify that it doesn't allow it.
Even though a user story doesn't capture many of the details that would be tested, user stories are helpful for framing and prioritizing a test plan.