0

A rather complicated library/subsystem has to be integration tested and smoke tested, and for that purpose we need to develop a non-trivial test fixture/runner.

The details are not important, but assume that the test fixture we need will be generating complicated, interacting, state-dependent input test vectors, and will be looking for complex result sequences.

The test fixture itself will require some significant development effort (though less effort than the subsystem itself). The question is:

  • Should this non-trivial test fixture be included in the project plan as a part of the iterations?
  • Should a set of user stories be created for this test fixture?
  • If so, how would the user stories be structured? And who would be the actors here: the test engineer running the tests, the subsystem, or the fixture itself?
David H
  • 1,461
  • 2
  • 17
  • 37

1 Answers1

0
  • If your 'non-trivial test fixture/runner' is estimated to take more than a day to be implemented, it's work that should be tracked proper and should go into your backlog. If you think it may take a week or longer, then I'd do a prototype first.
  • Probably the 'non-trivial test fixture/runner' doesn't bring any business value itself. I'd assume you're addressing technical dept. Writing user stories for technical tasks/ dept feels always wrong to me. Put them as technical tasks in your backlog.
  • You should know your business and your actors.
alpe1
  • 350
  • 1
  • 9
  • I know my business and my actors; the point is to communicate this information to others. I've edited the question a bit to clarify. – David H Jan 31 '14 at 14:54
  • Until you're building products for developers or test engineers I don't see them as actors. Neither are systems or the fixture itself. Think about user stories generally as a start of a conversation. Who benefits from this story in terms of business value? If you're addressing technical debt don't squeeze it into a (formal) user story format. There is nothing wrong selling a task saying: We want to do ... to address our technical debt, because ... Add acceptance criterias, estimates, etc – alpe1 Jan 31 '14 at 19:31