Agile Scrum – How to Write User Stories for a Framework API

agilescrum

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:

  1. utility classes to make working with underlying web automation tool easier.
  2. 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.
  3. 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?

Best Answer

I would suggest to slice vertically for stories, not horizontally:

As a QA group member, I can write a test using a page API that goes to a specific page, click on a button and verifies that I navigates to the right target page.

Then implement the page API layer and base layer necessary to support that, and no more. This is demonstrable and has business value: you can actually write a test and run it.

Then follow up with other vertical slices:

As a QA group member, I can write a test that goes to a specific page, fill in a text box, click on a button and verifies that I navigates to the right target page.

And incremental improvements (Cuke for instance)

As a QA group member, I can write a test using a cucumber like DSL that goes to a specific page, click on a button and verifies that I navigates to the right target page.

Related Topic