Negative scenarios

[Vingador]

Hi,

We have been working as 'three amigos' (Dev, Test, PM) to write our requirements in a Given/When/Then format using example tables.  We find this works well for happy path/positive test cases, but that it is more difficult to distill the negative scenarios down into a few key examples.  Do you have any advice as to how we could apply SBE better to negative requirements - i.e. things we don't permit / want the system to do / capabilities that should not be available to a user in a given screen etc.

Testers can write tests around the inverse of a requirement, but this doesn't fulfill the idea of 'running the requirements' as tests - i.e.we are extrapolating from what is written in the requirements rather than using what is written there as the basis of any test cases. 

Cheers

[Gojko Adzic]

Kick-start a workshop by asking people to list things that should
always happen or that should never happen. This is the typical
Always/Never heuristic from Elisabeth Hendrickson's book. then
challenge each of those... eg if someone says 'always record the
transaction', then try applying testing heuristics on the structure of
that example to come up with ideas when this shouldn't happen.

gojko

> --
> You received this message because you are subscribed to the Google Groups
> "Specification by Example" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to specificationbyex...@googlegroups.com.
> To post to this group, send email to
> specificati...@googlegroups.com.
> Visit this group at https://groups.google.com/group/specificationbyexample.
> For more options, visit https://groups.google.com/d/optout.

[Vingador]

Thanks for the reply. We've been considering 'Always/Never', but perhaps not challenging these statements, so will try to always do that.  However, we have a specific discussion right now around 'capabilities' (e.g. controls on the UI) that should appear in some use cases and not in others.  We're finding it difficult to specify these, particularly in the 'negative' (i.e. the controls we don't want to be available at a certain time):

e.g. 

when we are in mode x 

then we expect to be able to complete an action on the UI (.... this infers that the user can use buttons a,b and c, so they must be available otherwise the rqmnt is not met) 

and we also expect the user NOT to be able to do a bunch of other possible user actions ( i.e. buttons e,f,g,h,i,j, are not available)

Whilst the above is testable it becomes very verbose when we consider the different screens and capabilities under different circumstances.  We began drawing up a big reference table outside of the specific requirement we were focusing on, but no one on the team much like this approach.  It began looking like a  'what buttons should and should not be on what screen' reference.

Any ideas how we can handle this better?

Cheers,

[Justin Forder]

How about:

Given ....

When ....

Then the only operations available are a, b, c

regards

     Justin

--
You received this message because you are subscribed to the Google Groups "Specification by Example" group.

To unsubscribe from this group and stop receiving emails from it, send an email to specificationbyexample+unsub...@googlegroups.com.
To post to this group, send email to specificationbyexample@googlegroups.com.

[Justin Forder]

...but if the design is driven by required behaviour, won't you only put (or enable) the controls on the screens that are needed for your positive specifications to be met?

regards

     Justin

To unsubscribe from this group and stop receiving emails from it, send an email to specificationbyexample+unsubscri...@googlegroups.com.

[Chris Matts]

Hi

The trick here is to work backwards through the GIVEN WHEN THEN format. Start with the THEN, then do the WHEN, finally the GIVEN.

I'll illustrate with the example I use in training ( see here https://www.infoq.com/presentations/cynefin-product-management ). We are creating a mobile app that lets people know where key events occurred in Bono's life (example celeb).

First then

THEN the app displays a map

AND I am marked at the center

AND "bono sites" are displayed

AND description of "bono sites" are displayed.

We can know consider the "Quality Paths" i.e. the times when things are not happening according to the happy path, each line at a time. We can get as silly as we like. e.g. :

THEN the app displays a map
TODO: Cannot access map server (Google is down)

AND I am marked at the center

TODO: I cannot get a fix on where I am. The GPS satalitte has been knocked out of orbit or my phone cannot get a signal. Perhaps I could enter a post-code for my location instead, especially if I've taken the sim out of my phone.

AND "bono sites" are displayed

TODO: There are no "Bono Sites" in the area.

AND description of "bono sites" are displayed.

TODO: There are no descriptions of the "bono sites"

Then we do the WHEN. Everyone jumps to WHEN I open the app or search for bono or something. Instead, we decided on

WHEN I'm reach <my preset distance> from a bono site.

TODO: We need to add 'AND App beeps" to the THEN bit.

TODO: When user enters app and searches

TODO: When user turns on phone and within <my preset distance>

Now the GIVEN

GIVEN I'm within <preset distance> of bono site

AND there is a description for the "bono site"

AND I have notification turned on

AND my GPS is switched on

More todos:

TODO: Notification not turned on. Need to send daily e:mail to user telling them what they missed.

TODO: GPS is switched off

TODO: Not within <preset distance> of bono site.

Each GIVEN becomes a THEN in another scenario. i.e.

THEN I have notification turned on. etc etc.

Works a treat when you have the three amigos working backwards this way. When I say three amigos, I mean the PO, UX Researcher, UX designer, Tester, Service Designer and Dev.

Regards

Chris Matts

co-creator of the GIVEN-WHEN-THEN syntax.

--
You received this message because you are subscribed to the Google Groups "Specification by Example" group.

To unsubscribe from this group and stop receiving emails from it, send an email to specificationbyexample+unsub...@googlegroups.com.

To post to this group, send email to specificationbyexample@googlegroups.com.
Visit this group at https://groups.google.com/group/specificationbyexample.
For more options, visit https://groups.google.com/d/optout.

--

Regards

Chris Matts

[Vingador]

Appreciate the responses, its given us some ideas to try in future sessions.  

Justin, the 'only' approach is neat, but it does seem to hide the other details - i.e. we'd still be testing that other things cannot be done on the UI at a given point, but this wouldn't be explicit in the requirement.  Arguably it doesn't need to be, as the list of things we can't do in a given context could be huge

 Chris, the idea of working backwards is a new one to me, we'll give this a shot.

 

I'll update once we've done that.

Cheers!