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
Then <role> should have firewall rule authority
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
> > files? We add another feature called "Add a secret password to a
> > but in order to maintain system integrity, we also need to add a
> > 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.
> > if the final few questions don't come across very well - I work
> > 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...
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