When is a step a "given" or a "then"?

[George Cover]

Hi (again)...

My situation:

 - An Organization has Members. These Members can have one of three Roles - Admin, Manager, Staff

 - A Room can also have Members. These Members can have one of two super states (active, inactive)

 - A Feature of "Start a desktop in a room"

 - A Feature of "Rejecting a user from a room" (makes them inactive (there are other ways to become inactive))

- A Feature of "Adding firewall rules to a room" (plus the other RUD actions)

We have a previous feature "Assigning desktops to room members"...

Given there is a Manager in a room

When they assign a desktop to a user

Then that user can start the desktop

Now we start talking about rejecting users from a room...so we can make this scenario

Given there is a user in a room

And they have been assigned a desktop

When they are rejected from the room

Then they can not start the desktop

Now we start to talk about firewall rules...

Given there is a Manager

When they add a firewall rule

Then traffic is permitted from a desktop

(there are examples of what rules look like)...

So, here's the question...did I paint enough of a background...

Do you put the "Rejected Manager" as a Given in the "Add firewall rule" feature....or do you add another scenario (and probably multiple) into the "Reject User" feature (which is becoming ever bigger with the increasing number of features in the system)?

How to keep things discoverable - for instance, how do we easily tell who can add firewall rules? Surely checking the "Add firewall rule" feature would be the place...but taking that to it's logical conclusion, would mean there are very little consequences written up in the feature file for "Reject a user" (and we may miss a spec because of this - in fact, I'm beginning to think we'll miss specs either way we do it)...

Does this mean for every feature addition we don't have encapsulated feature files? Our functionality is spread out across different feature files? We add another feature called "Add a secret password to a room" but in order to maintain system integrity, we also need to add a feature to "Reject User" again...

Thoughts? (does it matter in the long run?) :)

I realize I've posted something very similar to this - I hope my thinking has moved on, or at least been distilled a little further, and this question isn't just a repeat of my previous one. I also have a nasty habit of brain dumping and letting my mind wander a bit. Apologies if the final few questions don't come across very well - I work better face to face with a scribbling surface in front of me.

[George Dinwiddie]

Hi, George,

I'm confused. I see no mention of "Rejected Manager" above, so I don't
know how they relate to adding a firewall rule.

>
> How to keep things discoverable - for instance, how do we easily tell
> who can add firewall rules? Surely checking the "Add firewall rule"
> feature would be the place...but taking that to it's logical conclusion,
> would mean there are very little consequences written up in the feature
> file for "Reject a user" (and we may miss a spec because of this - in
> fact, I'm beginning to think we'll miss specs either way we do it)...

Consider

Scenario: add a firewall rule
When a Manager adds a firewall rule

Then traffic is permitted from a desktop

for the happy path. (Though this doesn't describe the relationship
between the rule and the desktop, to me.)

Scenario: fail to add a firewall rule
When a stranger adds a firewall rule
Then the rule is not added
And a siren sounds

You could, of course, use scenario outlines to list all the roles
permitted and forbidden from adding firewall rules. In my experience,
this is mostly a duplication of a list of roles in the application, so
it doesn't really add anything. Rather than checking functionality, it
becomes an exercise in creating the same list twice in two places.

>
> Does this mean for every feature addition we don't have encapsulated
> feature files? Our functionality is spread out across different feature
> files? We add another feature called "Add a secret password to a room"
> but in order to maintain system integrity, we also need to add a feature
> to "Reject User" again...

I don't understand what you mean hear. I also think that what you're
calling features sound more like scenarios to me. Features are things
you might include on the box. "New feature: secret passwords!" Then you
can have scenarios for adding a secret password, someone entering the
room with the password, someone failing to enter the room with an
incorrect password, removing the password for a room, ....

Features are attributes of the product. Scenarios are activities.

>
> Thoughts? (does it matter in the long run?) :)
>
> I realize I've posted something very similar to this - I hope my
> thinking has moved on, or at least been distilled a little further, and
> this question isn't just a repeat of my previous one. I also have a
> nasty habit of brain dumping and letting my mind wander a bit. Apologies
> if the final few questions don't come across very well - I work better
> face to face with a scribbling surface in front of me.

I hope that helps.

- George

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

[George Cover]

>> Sorry - Regardless of your role within the org, you can also be a member of a room.

>> A Manager role (regardless of their status within the room) can add a firewall rule.

>> Now I've spelled it out like that, I guess I don't need to write any features/scenarios about a Manager, who has had their room access rejected, being able to add firewall rules...

>>

>> Let's now say we find a bug where if a Manager happens to be an inactive member of a room, they can no longer add firewall rules.

>> We'd need to write a scenario to document the system should behave like that (I'd suggest that given it's definitely a scenario we knew about, we should document it anyway).

>> Would you write a scenario in the "Reject User From Room" feature about a Manager being rejected...or a scenario in the "Add Firewall Rule" feature about a Manager with an inactive room membership...

 

>
> How to keep things discoverable - for instance, how do we easily tell
> who can add firewall rules? Surely checking the "Add firewall rule"
> feature would be the place...but taking that to it's logical conclusion,
> would mean there are very little consequences written up in the feature
> file for "Reject a user" (and we may miss a spec because of this - in
> fact, I'm beginning to think we'll miss specs either way we do it)...

Consider

Scenario: add a firewall rule
   When a Manager adds a firewall rule
   Then traffic is permitted from a desktop

for the happy path. (Though this doesn't describe the relationship
between the rule and the desktop, to me.)

Scenario: fail to add a firewall rule
   When a stranger adds a firewall rule
   Then the rule is not added
   And a siren sounds

You could, of course, use scenario outlines to list all the roles
permitted and forbidden from adding firewall rules. In my experience,
this is mostly a duplication of a list of roles in the application, so
it doesn't really add anything. Rather than checking functionality, it
becomes an exercise in creating the same list twice in two places.

>> I think I'm misunderstanding you here. You wouldn't write a few scenarios saying "Admin can add one", "Manager can add one", "Staff cannot add one"?

>> As for that first part, if the scenario read "When a manager adds a firewall rule to a room, Then network traffic is permitted from desktops in the room" does that make the relationship clearer? It's also a bit more specific as it definitely happens inside a room.

>
> Does this mean for every feature addition we don't have encapsulated
> feature files? Our functionality is spread out across different feature
> files? We add another feature called "Add a secret password to a room"
> but in order to maintain system integrity, we also need to add a feature
> to "Reject User" again...

I don't understand what you mean hear. I also think that what you're
calling features sound more like scenarios to me. Features are things
you might include on the box. "New feature: secret passwords!" Then you
can have scenarios for adding a secret password, someone entering the
room with the password, someone failing to enter the room with an
incorrect password, removing the password for a room, ....

Features are attributes of the product. Scenarios are activities.

 

>> You're right - in my original text, I did mean scenario. I think features can be as big or as small as needs be.

>> For instance, the feature file "Secret passwords" would now include a scenario for what happens when one is added, changed, or deleted.

>> If we also add the scenarios in about which roles can perform these actions, we increase the number of scenarios.

>> We may have different types of secret passwords that have different validation rules...so now we have some more scenarios about what happens users attempt to add invalid secrets.

>> Now we get lots of different "subtypes" of passwords...does this now become a higher level feature, with sub features of adding those different types (and the consequences).

>
> Thoughts? (does it matter in the long run?) :)
>
> I realize I've posted something very similar to this - I hope my
> thinking has moved on, or at least been distilled a little further, and
> this question isn't just a repeat of my previous one. I also have a
> nasty habit of brain dumping and letting my mind wander a bit. Apologies
> if the final few questions don't come across very well - I work better
> face to face with a scribbling surface in front of me.

I hope that helps.

>> It all helps. I wouldn't even say the solution we're building is large scale software, but adding in roles and authorization seems to make the software feel bigger.

>> Instead of a feature having a few scenarios, it could now easily have a few scenarios per role.

>> From a story perspective I've always found it strange when confronted with something like "As a Staff Member I don't want to add firewall rules..."

>> Flipping that around to "As a Manager I don't want Staff Members to add firewall rules in order to keep my room secure" sounds like a feature to me...

[George Cover]

Interestingly, adding that last part about a user story leads me to think I'd also have a very similar story:

"As an Organization Administrator I don't want Staff Members to add firewall rules in order to keep my room secure"

Most people try and translate a story to a feature - I think sometimes a story just translates to a scenario. That wouldn't match up with Liz's idea of "the one where..." - or rather, the user story for the feature that contains the scenario "the one where staff members cannot add firewall rules" would potentially be a little vague...As a Room Manager I want to manage firewall rules in order to keep my room secure". There could be an awful lot of scenarios in here...with potentially multiple all saying the same thing, the different just being how they came to be accepted as a Room Manager:

 - the one where an organization administrator adds a firewall rule

 - the one where an organization manager adds a firewall rule

[George Dinwiddie]

Scenario: A Manager inactive in the room can add firewall rules

> >> Would you write a scenario in the "Reject User From Room" feature
> about a Manager being rejected...or a scenario in the "Add Firewall
> Rule" feature about a Manager with an inactive room membership...

I would put it in the Firewall feature. Features should be nouns rather
than verbs, in my opinion.

If a feature gets unwieldy, it can be split into subfeatures then.

Not generally. Certainly not for testing through the UI.

You could write scenario outlines for the role-based authorization code
that checks

Then <role> should have firewall rule authority

and

Then <role> should NOT have firewall rule authority

These lists, though, would likely mirror the implementation of the code.
Given that, it's likely that a mistake in one would be also made in the
other. To me, that's a weak test.

> >> As for that first part, if the scenario read "When a manager adds a
> firewall rule to a room, Then network traffic is permitted from desktops
> in the room" does that make the relationship clearer? It's also a bit
> more specific as it definitely happens inside a room.

I don't know what "desktop" or "room" means in your domain. Are these
physical or virtual? Are there rules other than to allow a specific
desktop to access the network? These things are not clear from your
scenario. I would want them to be made clear somewhere in the feature file.

>
> >
> > Does this mean for every feature addition we don't have encapsulated
> > feature files? Our functionality is spread out across different
> feature
> > files? We add another feature called "Add a secret password to a
> room"
> > but in order to maintain system integrity, we also need to add a
> feature
> > to "Reject User" again...
>
> I don't understand what you mean hear. I also think that what you're
> calling features sound more like scenarios to me. Features are things
> you might include on the box. "New feature: secret passwords!" Then you
> can have scenarios for adding a secret password, someone entering the
> room with the password, someone failing to enter the room with an
> incorrect password, removing the password for a room, ....
>
> Features are attributes of the product. Scenarios are activities.
>
> >> You're right - in my original text, I did mean scenario. I think
> features can be as big or as small as needs be.
> >> For instance, the feature file "Secret passwords" would now include
> a scenario for what happens when one is added, changed, or deleted.

Yes, but I suggest thinking of it in terms of what it means to the user
and/or business, rather than CRUD operations.

> >> If we also add the scenarios in about which roles can perform these
> actions, we increase the number of scenarios.

Yes, that's the nature of role-based permissions. Often you can group
roles and test the functionality of representative samples.

> >> We may have different types of secret passwords that have different
> validation rules...so now we have some more scenarios about what happens
> users attempt to add invalid secrets.
> >> Now we get lots of different "subtypes" of passwords...does this now
> become a higher level feature, with sub features of adding those
> different types (and the consequences).

I think you're worrying about the combinatorial explosion of checking
all the permutations. Check these aspects separately so that doesn't happen.

>
>
> >
> > Thoughts? (does it matter in the long run?) :)
> >
> > I realize I've posted something very similar to this - I hope my
> > thinking has moved on, or at least been distilled a little
> further, and
> > this question isn't just a repeat of my previous one. I also have a
> > nasty habit of brain dumping and letting my mind wander a bit.
> Apologies
> > if the final few questions don't come across very well - I work
> better
> > face to face with a scribbling surface in front of me.
>
> I hope that helps.
>
> >> It all helps. I wouldn't even say the solution we're building is
> large scale software, but adding in roles and authorization seems to
> make the software feel bigger.
> >> Instead of a feature having a few scenarios, it could now easily
> have a few scenarios per role.
> >> From a story perspective I've always found it strange when
> confronted with something like "As a Staff Member I don't want to add
> firewall rules..."
> >> Flipping that around to "As a Manager I don't want Staff Members to
> add firewall rules in order to keep my room secure" sounds like a
> feature to me...

Some advice:
Drop the Connextra template. It's a thinking tool, but often gets
used to bypass thinking.
Security is not about adding access, but about denying it. Flipping
it around as you did above is the right way to go.
Don't expect to automate every possible combination of conditions.
And don't write the system that you need to do that to feel confident it
works.

[George Dinwiddie]

George,

On 7/26/18 3:28 PM, George Cover wrote:
> Interestingly, adding that last part about a user story leads me to
> think I'd also have a very similar story:
> "As an Organization Administrator I don't want Staff Members to add
> firewall rules in order to keep my room secure"
>
> Most people try and translate a story to a feature - I think sometimes a
> story just translates to a scenario.

I think a story should generally be described by one or a small handful
of scenarios. In fact, that's a great way to split stories that are too
large. You can spot that because they need a lot of scenarios to verify
that they're complete. Group those scenarios in related clumps, and
represent each clump as a story.

> That wouldn't match up with Liz's
> idea of "the one where..." - or rather, the user story for the feature
> that contains the scenario "the one where staff members cannot add
> firewall rules" would potentially be a little vague...

"The one where a staff member tries to add a firewall rule" doesn't seem
vague to me. The Three Amigos should be able to decide what behavior is
desired when that happens.

> As a Room Manager
> I want to manage firewall rules in order to keep my room secure". There
> could be an awful lot of scenarios in here...with potentially multiple
> all saying the same thing, the different just being how they came to be
> accepted as a Room Manager:
>  - the one where an organization administrator adds a firewall rule
>  - the one where an organization manager adds a firewall rule

Are these really different? Perhaps there's a domain term that's
missing--one that would represent anyone who is allowed to add a
firewall rule? Maybe "room manager" is that term; I don't know. Is a
room manager authorized only for that room and not other rooms? That
could be another scenario.

The point is to figure out what examples are needed to verify each rule.
Sometimes you realize there's a hidden rule as you're listing the
examples. I *really* like Example Mapping for this.

Beware the word "manage." It's a squishy word that can cover a lot of
territory.