Typically the tester’s unique perspective will improve the user story for missing details or non-functional requirements. Good approach for testers is to ask open questions from product owner concerning the user story or to ask product owner how he would test the user story as a tester. It will also help product owner to see what level of information is required by the team to produce working software per iteration. For example, a story can describe a feature that will be coded by a developer of the Agile team. But this feature will interact with another application, or add information in a database used by another application. In this case, it will be useful for the developer, the tester and business stakeholders to have user stories that describe how the feature will work internally and with other applications via the database. A coded function will extract data from a database which will be used with a business intelligence tool. A user story may state, “As an analyst I want to view data in a statistics tool after extraction so that I can analyze it”. The developer will write and test the “extract” function per the functional user story, and an interoperability user story, or a sub-task of the user story will explain how data will be used. Each story will specify acceptance criteria for these functional and non-functional characteristics. These criteria provide the developer and tester with an extended vision of the feature that the product owner and business or operation stakeholders will validate.
The text above is a sample from the upcoming Agile Tester Add-On that will be released in early 2014. Please note that Agile Tester Add-On is in its alpha phase, which means that its content may change. Visit www.istqb.org to get latest information.