I'm a new QS tester in a company in an Agile environment. During the sprint commit I was told that one of my tasks was going to be testing user stories? How exactly do you test something like that. If anyone can give me any insight into this it would be greatly appreciated. Thanks.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
As ByteBuster indicated, user stories are a very high level description of a goal an actor or customer wants to achieve with the product, but doesn't detail exactly how that goal is going to be achieved.
Developers often break user stories down into discrete development focused tasks that are necessary to achieve that goal. Developers should also be writing unit tests against those tasks.
A tester's goal in testing user stories is to put yourself in the shoes of the actor or person and think of the different ways (tests) that persona might achieve the objective of the user story. Also, think of things that might go wrong along the way, or other actions or flows that might block the objective of the user story from being achieved.
Remember, developers often look at software in task or functional chunks. While testers also frequently test discrete functional attributes of software, one of the primary roles of the tester is to look at software more holistically and approach testing from the eyes of the customer.
As the other answers have said, you will probably not test the user stories directly. The method I've used in the past works like this:
My preference is that the user story is not tested until all tests have passed or the functionality behind non-passing tests has been put on the backlog for another sprint or deemed out of scope - that is, every test has been accounted for and every task has been tested.
Of course, circumstances can make a mess of this, but it's a decent starting point. Good luck.
User Stories are the highest-level requirement artifacts in the software development lifecycle.
As you see, the User Stories are pretty broad by their nature. Often, highest level means lowest details, minimal structure, and therefore they may be interpreted differently by different people. This is why
Usually, QA do not test the User Stories directly.
Instead, most issue tracking tools allow to manage mapping User Stories to individual development tasks.
As soon as Tasks are being implemented, they are tested by QA, you may be quite familiar with the normal process.
I should make an important note. I've seen some teams that do have direct testing of User Stories. They assign specific Success Criteria to each individual User Story, just like in @Pangea's answer. The choice is yours; probably you should consider the size of the project and the dev team, and maybe some more criteria to decide if you really need direct testing of User Stories.
There is usually a Definition of Done/Acceptance Criteria associated with each of the user stories. You can start from there.
I'd recommend watching the video "James Bach on testing in an agile software development team" - he talks about testing during sprints, covers user stories, things testers should be looking for / asking questions about. He has a lot of ideas and since you are new to the Testing game it might be worth watching. Plus the video is only about 30 minutes long. Enjoy!