I need help understanding what user stories should look like for a web testing framework we are building for our organization's QA department. We are trying to run this project using Scrum.
The product will have 3 layers:
- utility classes to make working with underlying web automation tool easier.
- a page-object API layer which will allow our testers to write tests from the perspective of what services our web pages offer, instead from the perspective of the web automation tool.
- a declarative layer, which will allow writing of tests in an English-type language--perhaps Cucumber-like scenarios. This layer will be mapped to the page-object API layer, so that if a test can't be performed declaratively, the test author can drop down into the page-object API layer.
The end-user of this framework is our QA group who will be writing tests either at declarative level, or if they need to, the page-object API level.
My question is what should our user stories look like? Currently we have stories that cover what the web automation should be able to do (ie. find elements on the page, wait for elements to appear), but that can't be right. Firstly, we could deliver this kind of stuff already by giving the QA group the underlying automation tool. These stories are clearly not worth demonstrating in a sprint review.
Secondly, stories should indicate business value, which in this case is not in finding elements on a page, it's in:
- having tests based on an up-to-date, popular and effective web automation tool.
- having readable tests
- having the actual tests separated from the web automation tool which is driving them.
Fine, but how do I break the product up into more specific user-stories?