Multiple (similar) scenarios with different roles...

[George Cover]

As with a lot of software we have various roles involved, and a lot of these roles can carry out the same scenario.

I'm currently having trouble organizing the features/scenarios into logical groupings. Some people think from the base point of the role (What can this role do) and others come from the feature (who can do this feature).

I realize that the advice might be along the lines of "get everyone on the same page first" which makes sense, and we're trying.

My specific conundrum is whether to create a single feature file with multiple scenarios detailing a different Given (to setup role)...or more likely multiple 'role-feature' files per feature such as:

 - ViewRoomStatus-Owner.feature

 - ViewRoomStatus-Manager.feature

 - ViewRoomStatus-Staff.feature

Has anyone got insight or thoughts into organizing feature files for discoverability?

Thanks

George

[George Dinwiddie]

Hi, George [catchy name!]

On 6/15/18 8:46 AM, George Cover wrote:
> As with a lot of software we have various roles involved, and a lot of
> these roles can carry out the same scenario.

Is the system behavior the same for the different roles?

>
> I'm currently having trouble organizing the features/scenarios into
> logical groupings. Some people think from the base point of the role
> (What can this role do) and others come from the feature (who can do
> this feature).

I would start from the point of "why would this person do this?" Or
"what does the system do to further this person's agenda?"

An example I often use is that of a library system. When a patron looks
at their list of reserved books they need different affordances than
when the librarian does. And you'll want to deny those affordances when
an unidentified person tries to view the list of reserved books.

>
> I realize that the advice might be along the lines of "get everyone on
> the same page first" which makes sense, and we're trying.
>
> My specific conundrum is whether to create a single feature file with
> multiple scenarios detailing a different Given (to setup role)...or more
> likely multiple 'role-feature' files per feature such as:
>  - ViewRoomStatus-Owner.feature
>  - ViewRoomStatus-Manager.feature
>  - ViewRoomStatus-Staff.feature

Something like "view room status" sounds smaller than a feature, to me.
In fact, it sounds like a mis-aimed step. The system you're building
isn't viewing the room status, is it? And the behavior you're specifying
isn't the behavior of the user. What is it that the system is doing for
the user? At least think of "display room status," though I think there
is an unstated reason for displaying it. Getting to that will be helpful.

"Status" is also a troublesome word, but for a different reason.
"Status" is such a non-specific word, and can mean so many different
things. What are the possible values of room status? Rented, available,
and unavailable? Renovated, in-progress, and not renovated? Peon,
ordinary, and VIP?

>
> Has anyone got insight or thoughts into organizing feature files for
> discoverability?

I would need to know more about the domain and expected behavior before
I could organize the features for discoverability. If you'd like to
pursue this further, I'd be glad to do so.

>
> Thanks
> George

You're welcome,
George :-)

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[George Cover]

Thanks for replying George! Viewing the status of something is a bit of a weak feature, you're right. The system that's being built is a virtual desktop infrastructure project - 'room' is the name given to a set of resources that enable a 'whiteroom' situation with various machines, routers, etc. As you said, it's really a step in "Connecting my network to the room" feature...some of our features are probably written in a more test case style than specification, something we're learning as we go, and correcting where we can.

Probably a better feature we have is desktop session recordings. Anyone who can use a desktop will create a recording, however only certain roles have access to view them. For the sake of completeness we want to have specifications for how the system behaves when being accessed by those different roles - let's say for three roles, the recordings are available and for two roles they are not.  Pursuing a 'complete' spec is where we end up with a "feature" that could be too small - View Recordings.

We've discussed having multiple feature files inside a larger theme of "Session Recording" - due to the user story changing it's perspective (role to role), understanding that the mini-feature "View Recordings" is broken for one role, or many roles, has some attraction to some of our team. This was in contrast to a single step with a table (or multiple steps) saying "And a <role> can view the recording" inside the "Connect to Desktop" feature. This perceived nesting of features is causing a few discussions here.

And now I've wound myself all the way back to "View Recordings" which is probably just as weak a 'feature' as "View Room Status" :)

In summary, I think I have two problems in breaking down stories/features/scenarios:

 - How to 'layer' functionality throughout the system. We introduce notifications about certain actions - does that become a step in a whole bunch of scenarios, does it warrant it's own feature? Does that change if we can enable/disable notifications?

 - How to represent multiple roles being able to carry out the same behavior. What features/scenarios would we write for a venn diagram of roles versus read/write capability?

Thinking about that last statement of read/write makes me think our features might be too closely aligned with CRUD...perhaps they are too much like test cases rather than specifications (however I also think the two are very closely related).

George

[George Dinwiddie]

George,

On 6/18/18 8:00 AM, George Cover wrote:
> Thanks for replying George! Viewing the status of something is a bit of
> a weak feature, you're right. The system that's being built is a virtual
> desktop infrastructure project - 'room' is the name given to a set of
> resources that enable a 'whiteroom' situation with various machines,
> routers, etc. As you said, it's really a step in "Connecting my network
> to the room" feature...some of our features are probably written in a
> more test case style than specification, something we're learning as we
> go, and correcting where we can.

One of the difficulties of creating infrastructure or frameworks is the
lack of specificity. I find I do best if I create a thin client using
what I'm building, so that I can better visualize how it will be used.
Sometimes I do that as a demo client that can be shipped as
documentation. Sometimes that client is just part of the test code.
Usually it starts out in the test code and gets extracted when it has
value elsewhere.

>
> Probably a better feature we have is desktop session recordings. Anyone
> who can use a desktop will create a recording, however only certain
> roles have access to view them. For the sake of completeness we want to
> have specifications for how the system behaves when being accessed by
> those different roles - let's say for three roles, the recordings are
> available and for two roles they are not.  Pursuing a 'complete' spec is
> where we end up with a "feature" that could be too small - View Recordings.
>
> We've discussed having multiple feature files inside a larger theme of
> "Session Recording" - due to the user story changing it's perspective
> (role to role), understanding that the mini-feature "View Recordings" is
> broken for one role, or many roles, has some attraction to some of our
> team. This was in contrast to a single step with a table (or multiple
> steps) saying "And a <role> can view the recording" inside the "Connect
> to Desktop" feature. This perceived nesting of features is causing a few
> discussions here.

What does "And a <role> can view the recording" mean? Does it mean they
can see that it exists? Or that they can play it back?

I would suggest a scenario for "Viewing recording is forbidden" and one
for "Viewing recording." Perhaps something like:

Scenario: Viewing recording
When a <role> requests to view a recording
Then the recording starts playing

Scenario: Viewing recording is forbidden
When a <role> requests to view a recording
Then the system refuses to play it

This expresses that the recording actually cannot be played. This is
more powerful than checking that it's not listed in a list of
recordings, as it provides protection in the event of an emailed URL or
other action bypassing the GUI.

If you want to check specific presentation information in the GUI, you
can do that. This is a slippery slope, however. I would rather unit-test
the GUI code for that rather than treat it as system behavior.

(Side note: While I'm not as anti-scenario outline as Andrew, I do
suggest writing and implementing a bare scenario first before converting
it to an outline. You'll get much more natural expression that way, and
sometimes will find you don't need to resort to an outline.)

For recording, something simple can suffice:

Scenario: Making a recording
When a least_privileged_role records a session
Then a session recording is created

>
> And now I've wound myself all the way back to "View Recordings" which is
> probably just as weak a 'feature' as "View Room Status" :)
>
> In summary, I think I have two problems in breaking down
> stories/features/scenarios:
>  - How to 'layer' functionality throughout the system. We introduce
> notifications about certain actions - does that become a step in a whole
> bunch of scenarios, does it warrant it's own feature? Does that change
> if we can enable/disable notifications?

I would treat notifications as a feature of its own. Test scenarios
where notification happens successfully and where it fails or isn't
permitted. Don't try to be comprehensive in testing all permutations
through Cucumber. If you want that, consolidate the functionality for
those permutations into one method and unit-test that method.

>  - How to represent multiple roles being able to carry out the same
> behavior. What features/scenarios would we write for a venn diagram of
> roles versus read/write capability?
>
> Thinking about that last statement of read/write makes me think our
> features might be too closely aligned with CRUD...perhaps they are too
> much like test cases rather than specifications (however I also think
> the two are very closely related).

I think a problem arises when you try to make your specification
examples as complete and detailed as the system you're building.
Especially if you're trying to test it all through the GUI. The
scenarios should provide examples of the intended behavior, not check
all permutations. If you need to check permutations, check that at as
low a level as possible. You CAN do it that with gherkin, but if you do
it using unit tests in the same language as the implementation, it will
be much easier to refactor and keep up to date as the system changes.

- George

[George Cover]

Thanks again for your comments - the last paragraph about aiming for complete and detailed specifications is the problem I think I'm really butting up against. Its an awfully attractive proposition to be able to map out system functionality completely in language that everyone can understand and contribute to.

All the scenarios we have are aimed at the GUI - we're starting to drive the majority of these scenarios 'down' the stack to target the HTTP API, and potentially lower. This should give us the confidence that the domain is well specified...but we may be getting caught up on some scenarios really being GUI test cases, and not understanding how they might translate to a core behavior - for example, enumerating things (either permission based or not). "See list of recordings" is a behavior that exists in both the GUI and API layers...whereas "Play recording" is only available in the GUI - do we we shift the "See list of recordings" down to the API and create a separate feature for it (even though it sounds like a weak feature). Again, sounds a bit like death by specification!

I've got a few more resources to read about organization of features/scenarios. There's probably a workshop or two I (and probably the team) should attend as there's nothing like practical work and demonstrations to unlock understanding.

[Liz Keogh]

Hi George,

Just reading the thread through... would thinking of this as "capabilities" help?

Each piece of software you ship allows someone to do something, perhaps in some context. So your staff can request to view a recording; your owner can see what recordings they've already made; your admin can delete a recording, etc.

Each of those "can" phrases is a capability. They're usually a pretty good match for an "epic" in most orgs. You can break them down by context if they're too big.

I find these a really great way to map out system functionality; you can just pop them on a post-it note and move them around and decide what's in and out of scope. You can decide what's in and out of scope for each release, or narrow one by contexts you're going to support, and have great conversations around them without diving into the detail. The business usually latch onto the language pretty quickly as well; it's how they think.

Capabilities are usually very closely tied to the "when" of each scenario:

- When <staff> views a recording

- When <owner> looks up the list of recordings they own

- When <admin> deletes a recording

etc. - so it's a great way to organize scenarios too! You can split further by context if needed, e.g.:

- When <staff> view publically available recordings

- When <staff> view recordings on suspended accounts

If you do need to go down into detail of what scenarios are included, before the devs actually come to do the work, try just using the title of the scenarios. Dan North likes to name them like "Friends" episodes, so "The one where...."

- The one where <staff> views a recording

- The one where <staff> tries to view a recording but it's been deleted

etc.. (Of course you don't need "the one where"; I just find it helpful for the naming.) This leaves the conversations until the devs are available, so they remember them more easily, and you avoid investing in things you aren't going to deliver. You can dive into the nitty gritty of the scenarios early if you really need to, but normally that's just for very weird ones that are likely to go wrong otherwise.

I'd teach the devs then to ask, "Can you give me an example?" in the 3 amigos sessions when they pick up a ticket... and there you go, now you're doing BDD again.

Cheers,

Liz.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendevelopment+unsub...@googlegroups.com.
To post to this group, send email to behaviordrivendevelopment@googlegroups.com.
Visit this group at https://groups.google.com/group/behaviordrivendevelopment.
For more options, visit https://groups.google.com/d/optout.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[George Cover]

Thanks for adding to the conversation Liz - funnily enough, material on your site is in my reading list; particularly acceptance criteria versus scenarios.

I really like the capabilities idea...especially thinking of them as the when. This is definitely a mental model I've been working with alongside the scenario title approach.

If we used the Friends approach I still think we'd end up with something like the following:

The one where an owner looks for the recordings

The one where a manager looks for the recordings

The one where a developer looks for the recordings

My initial confusion was perhaps that these might have been features - they have a different story, well, different actor with the same goal. If the developer shouldn't be able to find the recordings, then that can be mapped in more detail in that scenario.

Definitely food for thought in this conversation and others. Time to start doing, then retro'ing and improving! (or trying to).