E-mail List Archives
Thread: how to write proper user case stories
Number of posts in this thread: 2 (In chronological order)
From: Nathan Clark
Date: Tue, Oct 04 2022 1:11PM
Subject: how to write proper user case stories
No previous message | Next message →
Dear list
I am trying to write several user case stories for my ieee standards
group. We are trying to write a new accessibility standard through the
ieee organization. As part of our standards writing process, our
group leader assigned us homework to write a bunch of user case
stories for different disabilities. I was wondering is their any sort
of guidelines/best practices/template on how to write an effective
user case stories. We can write these user stories for any disability.
Thanks for any help.
Sincerely,
Nathan Clark
--
Nathan Clark
QA Automation Analyst Tech team
Accessibility assistant
CPACC
cell: 410-446-7259
email: = EMAIL ADDRESS REMOVED =
101 Village Blvd
Princeton, NJ 08540
SMBE & Minority Owned Business
From: Steve Green
Date: Tue, Oct 04 2022 10:39PM
Subject: Re: how to write proper user case stories
← Previous message | No next message
If you're going to write user case stories, their structure should be agreed between all the relevant stakeholders, such as the developers, testers, business analysts, project manager etc.
There are a variety of options, such as unstructured narrative, behaviour-driven development (BDD) and specification by example (SBE).
https://en.wikipedia.org/wiki/Behavior-driven_development#Behavioral_specifications
https://en.wikipedia.org/wiki/Specification_by_example
There are pros and cons to each approach. Unstructured narrative is easy to write, but it may lack testable requirements. BDD is more difficult to learn, but the stories are relatively easy to convert into automated tests (if that's what you want to do). I don't have any experience of SBE, but it seems weird.
With all these approaches there is a balance between giving the developer the freedom to find the optimum solution and specifying exactly how something should be implemented. It's up to the stakeholders to decide where this balance should be. For instance, if your story says that error messages for forms must be implemented using ARIA live regions, that would preclude the developer from choosing to use server-side data validation instead of client-side validation.
That said, writing user stories for accessibility requirements seems odd to me because you wouldn't do this for security requirements such as sanitising input data, avoiding buffer and counter overflows etc. - these should be in development standards documents, not project specifications. You could implement them as acceptance criteria for your existing user stories, but that would result in a lot of duplication. The exception would be for accessibility tools, such as a style switcher, which could be a story in itself.
Steve Green
Managing Director
Test Partners Ltd