Custom non-trivial test fixture -- Do we create user stories for it? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

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?

Answer 1

• 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.