how to write good scenarios for GUI oriented App

[David Shavit]

Hello there

I`m pleased to join this respected forum

I have been applying BDD practices at my project for the last three years

gladly, the development ended, and now I have some time for retrospective

My question is about writing right scenarios where the examples regard a lot of gui work to do. 

In our system we need to "record" events during experiments, and most of the business of the users is to put all kind of widgets that giving the user a clue on the tested platform

consequently,  most of the scenarios inevitably detailed those user commands and so

after reading and watching some of the articles and lectures I got the impression that mixing the solution area eg what user do with the gui with the problem area (all the pure logic and business rules) is certainly bad practice

I`ll be thankful if you can help me to dispel the fog 

thanks 

david

[Konstantin Kudryashov]

Hi David,

I personally like to strive for my scenarios to closely reflect both the language and the scenarios that are specific and relevant for the product’s core domain. The rule of thumb I use here is to ask what examples and what terminology people local to said domain (domain experts) would use when talking between themselves without solution engineers present.

As you can imagine, this view makes it so that the way my scenarios are structured and written is very dependent on the particular problem space. Ignoring that context, it might seem to you that scenarios I write jump from one extreme to another between different products. This is intentional.

“Business” often means very different things in different domains. I would be strongly against using any GUI terminology when working on a system to handle and monitor financial transactions. At the same time I would have scenarios full of GUI terminology (such as “widget”) if the product I’m working on is a general business dashboard builder.

GUI is very often a support domain for a product. Which is why you see repeat advice to steer away from that terminology in scenarios. But that doesn’t mean that there aren’t products or needs where GUI is the core domain. When you work on a product like that, it would be detrimental to not use the language that most of your users would use most of the time.

- Konstantin

On 2 Nov 2020, at 08:45, David Shavit <shavi...@gmail.com> wrote:



--
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 behaviordrivendeve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/adb8a3f7-fd76-4428-bdb3-7a1beaf142b0n%40googlegroups.com.

[George Dinwiddie]

David,

On 11/1/20 8:03 AM, David Shavit wrote:
> Hello there
>
> I`m pleased to join this respected forum
> I have been applying BDD practices at my project for the last three years
> gladly, the development ended, and now I have some time for retrospective
>
> My question is about writing right scenarios where the examples regard a
> lot of gui work to do.
> In our system we need to "record" events during experiments, and most of
> the business of the users is to put all kind of widgets that giving the
> user a clue on the tested platform
> consequently,  most of the scenarios inevitably detailed those user
> commands and so

Step back a bit, and consider what the user wants to accomplish by using
your system. They use those commands in their attempts to accomplish
their goals, not for the sake of using the commands.

>
> after reading and watching some of the articles and lectures I got the
> impression that mixing the solution area eg what user do with the gui
> with the problem area (all the pure logic and business rules) is
> certainly bad practice

If you can describe an example of use, we could talk in more specific terms.

- George

>
> I`ll be thankful if you can help me to dispel the fog
> thanks
> david
>

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach https://pragprog.com/titles/gdestimate/
----------------------------------------------------------------------

[David Shavit]

Thanks you  Konstantin and George for the thoughtful response

i thought about it again, and I think it is right to say that the core problem domain is gui oriented and therefore it is crucial to use gui terms when formulating the examples because this is the main issue

the foggy thing here that it is quite difficult to find the differences between GUI business terms like as Widgets, builder etc and detailed and perhaps over detailed layout work that not should be part of the spec`s steps (when the user push that button and so on)

to make it more clear, this is typical scenario in our specs:

Scenario: Playback mode – login process with data files       in the library

       Given there are the following drives: 'X:, C:'

       And under drive 'X:' there are the following projects: 'A,B'

       And under project 'G280' there are the following A/C: '88,89'

       And under A/C '2001' there are the following TSN/FLT: '"FL002/TSN009","FL003/TSN011"'

       And under TSN/FLT '"FL002/TSN009"' there are the following Format: 'PCM1,PCM2'

       And TSN/FLT '"FL002/TSN009"'contains the following run numbers '300, 310, 320'

       And run number '300' connected to layout file 'Test Name 01'

       And run number '310' connected to layout file 'Test Name 02'

       And run number '320' connected to layout file 'Test Name 01'

And under Format 'PCM1' there are the following Files and options: '"Rdf_A_009_PCM1_F002_MAIN_20032015_A", "Rdf_A_009_PCM1_F002_MAIN_20032015_B", 'choose another file''

And under File '"Rdf_B_009_PCM1_F002_MAIN_20032015_A"' there are the following Sample rate options: '"60", "300", "10"'

And under File '"Rdf_B_009_PCM1_F002_MAIN_20032015_A"' there are the following Audio: '"None", "Combine", "Audio Only"'

And under File '"Rdf_B_009_PCM1_F002_MAIN_20032015_A"' there are the following exercises taken '"300-A", "300-B", "310-A"'

When the FTE selects in field 'mode' the value 'Playback'

       And selects in field 'drive' the value 'X:'

       And selects in field 'project' the value 'A'

       And selects in field 'A/C' the value '88'

       And selects in field 'TSN/FLT' the value 'FL002/TSN009'

       And selects in field 'Format' the value 'PCM1'

And selects in field 'File' the value ' Rdf_A_009_PCM1_F002_MAIN_20032015_A '

And selects in field 'Audio' the value 'Combine'

       And The FTE presses “login”

       Then the options selected in fields 'mode', 'drive', 'project', 'A/C', 'TSN/FLT', 'Format' are saved for the next entry

And the options selected in fields 'File', 'Audio' are not saved for the next entry

       And The FTE continues to the Playback main screen

And the "Playback timeline" is displayed

       And the actual run number is the first run number in the rdf or ethernet file

       And the screen file of the actual run number is displayed on the canvas

       And the actual run number is marked on the "Playback timeline" 

And the actual first exercise in the rdf or ethernet file is displayed on the canvas

And the actual first exercise in the rdf or ethernet file is marked on the "Playback timeline" 

       And the "exercise running toolbar" is enabled

And the "player toolbar" is enabled

       And "Generals" tab is enabled

       And the "Go to exercise" tab is enabled

       And "Flight and test run data" is displayed

       And the 'Test Name' is displayed

       And the "SETTINS" tab is enabled

       And the "EXERCISE" tab is enabled

       And the VIEW tab is enabled

       And the FILE tab is displayed as BUILDER

       And the BUILDER tab is enabled

       And the ELEMENTS tab is enabled

       And data is displayed on all the elements in the screen  

what you think about it? 

thanks 

David

ב-יום שני, 2 בנובמבר 2020 בשעה 20:21:06 UTC+2, li...@idiacomputing.com כתב/ה:

[George Dinwiddie]

David,

Your scenario is unreadable to me. I can't even tell what your problem
domain is. How would you describe your problem domain to an outsider who
doesn't have a clue what A/C or TSN/FLT means?

- George

> --
> 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 behaviordrivendeve...@googlegroups.com

> <mailto:behaviordrivendeve...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/behaviordrivendevelopment/074a9f5d-fe77-44b1-aa70-d58bc3112705n%40googlegroups.com
> <https://groups.google.com/d/msgid/behaviordrivendevelopment/074a9f5d-fe77-44b1-aa70-d58bc3112705n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Konstantin Kudryashov]

Hi David,

I don’t think I’d be able to understand this scenario unless I wrote it myself. And even then I’m not so sure :)

In my mind, written examples in BDD should strive to fulfil three responsibilities:

1. Enhance communication of the team

2. Provide narrative-driven documentation for the system

3. Validate actual system’s behaviour against its documentation

And I often find teams get the most value from the first two.

Your scenario, in my view, leans heavily towards validation of the system behaviour against your expectations. And these expectations lack narrative coherence. I don’t think biggest challenge here is terminology. Because even if I knew what “TSN/FLT” meant, I don’t think I’d be able to retell your scenario in my own words (or understand what or why I’m saying). There is too much detail and not enough story.

I would suggest you to focus on structure of your example (scenario) as a starting point. It needs to read like a documentation for people instead of automation script for the machine. It’s not the machine that you have to convince to keep reading and maintaining your scenarios.

Imagine someone new joined the business team of the discussed company and one of the first things their new boss said to them was reciting of this entire scenario as-is, followed by “understood?” :) Write your scenarios like an engaging story to tell someone new in your company. Not like a list of instructions and assertions for computer to execute.

Hope this helps.

- Konstantin

-- 
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 behaviordrivendeve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/074a9f5d-fe77-44b1-aa70-d58bc3112705n%40googlegroups.com.

Konstantin Kudryashov

— stakeholder whisperer

[a] http://about.me/everzet

[b] http://everzet.com

[c] https://github.com/everzet

[David Shavit]

Hello again 

and thanks again for your informative responses, I would explain more about this scenario:

the story here is about login to the one of the main mode of the system - playback of recorded piece of some telemetry data.

the story start with some preconditions of the typical state  of the system needed for this example of this action to work

the point here that there is recording  ready to replay. 

after that the story continues and the user need to enter some entry settings and then press the LOGIN button (the WHEN phase)

at last, in the THEN phase it`s describe the excepted system state and behavior : 

       a. first  the system records the preferred state of current user to the next time he will login

       b. next The whole system mode is changing to Playback: some gui elements appearing (canvas, timeline, toolbar) some enabled and some are not,  and the data is played  from specific agreed point (without more user actions).

hope that I success to make the scenario more clear.

I understand that this is more technical story but in our case the user are very technical guys

anyway something is telling me that we missed something, maybe too much machine todo list instead of short but summarized sceanrio. 

will be glad to your advice 

David

ב-יום שלישי, 3 בנובמבר 2020 בשעה 22:11:37 UTC+2, ever...@gmail.com כתב/ה:

[Konstantin Kudryashov]

So here’s what you just wrote, massaged a bit into Gherkin format:

Scenario: Playback of the recorded telemetry data

  Given the system is in typical state

  And there is telemetry recording ready to be replayed

  When user enters necessary entry settings and presses LOGIN

  Then the system should record the preferred state of current user

  And the system mode should change to Playback

It misses some important detail for me to follow. Like what is so specific about these “necessary entry settings”. And why do they press “LOGIN” instead of “replay”. Or why does the system store preferred state of current user.

But even so, above scenario is major improvement on the one you originally shared. You can judge that by the fact that now I know which questions to ask you (above). Now just work on the above scenario, balancing introduction of necessary details against conciseness and coherence of the overall story.

To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/a6c533e4-21e8-4336-979f-b15e68c71936n%40googlegroups.com.

[George Dinwiddie]

David,

Thanks for the greater detail. It helps.

On 11/4/20 6:27 AM, David Shavit wrote:
> Hello again
> and thanks again for your informative responses, I would explain more
> about this scenario:
>
> the story here is about login to the one of the main mode of the system
> - playback of recorded piece of some telemetry data.

First, login is an implementation detail, not core functionality. See
http://blog.gdinwiddie.com/2011/06/11/dont-you-have-to-login-first/ for
more about that. The real stories around login is that
1. you don't have access to protected data if you're unknown
2. your data is separated from others' data when the system knows who
you are

When you playback telemetry data, is this
1. something the user sees or hears, or
2. something that operated on by this or another system?

>
> the story start with some preconditions of the typical state  of the
> system needed for this example of this action to work
> the point here that there is recording  ready to replay.
>
> after that the story continues and the user need to enter some entry
> settings and then press the LOGIN button (the WHEN phase)
>
> at last, in the THEN phase it`s describe the excepted system state and
> behavior :
>        a. first  the system records the preferred state of current user
> to the next time he will login

Recording the users preferences for the next login seems like an
ancillary story, and I would make that a different scenario.

>        b. next The whole system mode is changing to Playback: some gui
> elements appearing (canvas, timeline, toolbar) some enabled and some are
> not,  and the data is played  from specific agreed point (without more
> user actions).

Here you can have a number of scenarios:
1. a simple one playing simple data
2. the "agreed point" setting and starting the playback somewhere
other than the beginning
3. what happens if there is no data
4. ... there are numerous other variations possible. The existence of
a toolbar suggests there are other settings that affect the playback

What is the goal of the user? What do they gain by playing the data?

>
> hope that I success to make the scenario more clear.
> I understand that this is more technical story but in our case the user
> are very technical guys
> anyway something is telling me that we missed something, maybe too much
> machine todo list instead of short but summarized sceanrio.
> will be glad to your advice

"Technical" doesn't have to be in implementation terms. What sort of
telemetry data is this? What does it represent? That's likely technical,
but is different from the details of the software.

- George

>> li...@idiacomputing.com <http://idiacomputing.com/>כתב/ה:

>> <http://blog.gdinwiddie.com/>
>> Software Developmenthttp://www.idiacomputing.com
>> <http://www.idiacomputing.com/>
>> Consultant and Coachhttps://pragprog.com/titles/gdestimate/

>> ----------------------------------------------------------------------
>>
>>
>> --
>> 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 tobehaviordrivendeve...@googlegroups.com.
>> To view this discussion on the web
>> visithttps://groups.google.com/d/msgid/behaviordrivendevelopment/074a9f5d-fe77-44b1-aa70-d58bc3112705n%40googlegroups.com

>> <https://groups.google.com/d/msgid/behaviordrivendevelopment/074a9f5d-fe77-44b1-aa70-d58bc3112705n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> *
> Konstantin Kudryashov*
> — stakeholder whisperer
>
> [a] _http://about.me/everzet_
> [b] _http://everzet.com_ <http://everzet.com/>
> [c] _https://github.com/everzet_

>
> --
> 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 behaviordrivendeve...@googlegroups.com

> <mailto:behaviordrivendeve...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/behaviordrivendevelopment/a6c533e4-21e8-4336-979f-b15e68c71936n%40googlegroups.com
> <https://groups.google.com/d/msgid/behaviordrivendevelopment/a6c533e4-21e8-4336-979f-b15e68c71936n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[David Shavit]

Hello 

I`m very appreciate  yours responses

this matter bother me for a long time

I`ll try to answer on the questions above, and I have more few  questions from myself

about the new thin scenario - yes it`s look good and more understandable but from the the other hand... where all the details vanished?

yes, now we have shorter scenario and after i rewrite necessary background things it`s more conciseness and coherence like mentioned above, but we thought back days that these are relevant details, aren't they?

about what is so specific about these “necessary entry settings" - I don't think I understand the question - I thought that  all the point with bdd approach is giving examples, and therefor we need to be  specific, in this case we simulate the user login with necessary  entry settings like which data is we want to reply of some specific project and so on.

about the login phase - yes it  necessary   because each user could save other recordings 

I think it good advice to separate the Last entry scenario, and add more scenario of the "bad path". about the agreed point this is the starting part of any scenario maybe we need to add the opposite scenario when something goes wrong

main goal of the user is to investigate the recorded data for some reason: validating that data recorded in the right manner,  search for anomalies but this is out of the scope of these scenario which intend only to describe the login process and that data is running. 

thanks a lot, these conversation is full with insights for me

David

[George Dinwiddie]

David,

On 11/5/20 12:25 PM, David Shavit wrote:
> Hello
> I`m very appreciate  yours responses
> this matter bother me for a long time
> I`ll try to answer on the questions above, and I have more few
> questions from myself
> about the new thin scenario - yes it`s look good and more understandable
> but from the the other hand... where all the details vanished?
> yes, now we have shorter scenario and after i rewrite necessary
> background things it`s more conciseness and coherence like mentioned
> above, but we thought back days that these are relevant details, aren't
> they?

Different details are relevant for different scenarios. I try to specify
only the details that matter for a particular scenario. I often make the
assumption (and make that assumption true in the test code), that all
other details are set to values that won't affect the scenario as written.

To use a simpler business domain, consider an online store. The price of
a line item depends on the quantity of items for that line.

Background: common setup
Given a widget sells for $10

Scenario: pricing a single widget
When a customer puts a widget in their empty shopping cart
Then the cart cost shows $10

Scenario: pricing multiple widgets
When a customer puts a widget in their empty shopping cart
And they increase the quantity to 3
Then the cart cost shows $30

Scenario: quantity discount
Given a quantities greater than 10 qualify for a 10% discount
When a customer puts a widget in their empty shopping cart
And they increase the quantity to 10
Then the cart cost shows $90

Notice that none of these scenarios car which customer it is, or where
they live. Scenarios to calculate shipping cost might need to know their
address, or how heavy a widget is.

>
> about what is so specific about these “necessary entry settings" - I
> don't think I understand the question - I thought that  all the point
> with bdd approach is giving examples, and therefor we need to be
> specific, in this case we simulate the user login with necessary  entry
> settings like which data is we want to reply of some specific project
> and so on.

Login, itself, is not the point of the system. Login lets you know who
the user is. In my examples above, I called them "a customer." That's
enough to imply that they are logged in. If they weren't, I would likely
specify "an unknown user." If they were a special customer, I would call
out the category of customer--"a wholesale customer." This allows my
scenarios to specify enough to make the scenario clear, with obscuring
the important parts with a lot of irrelevant details.

>
> about the login phase - yes it necessary   because each user could save
> other recordings

So the login allows you to identify which recordings belong to this
user. That's the important part, not the login, itself. You might update
the system so that the user is identified using an encrypted key on
their system, so they can bypass the login process. You wouldn't want to
have to edit every scenario because your method of identifying the user
has changed.

> I think it good advice to separate the Last entry scenario, and add more
> scenario of the "bad path". about the agreed point this is the starting
> part of any scenario maybe we need to add the opposite scenario when
> something goes wrong
> main goal of the user is to investigate the recorded data for some
> reason: validating that data recorded in the right manner,  search for
> anomalies but this is out of the scope of these scenario which intend
> only to describe the login process and that data is running.

How does the user know that the data recorded in the right manner. That
sounds key to this scenario.

As for login, I would just add a scenario that an unknown user cannot
see any data.

>
> thanks a lot, these conversation is full with insights for me
> David

I'm glad to help.

- George

[Andrew Premdas]

I like to divide things between the WHAT and the HOW. The WHAT is the overall thing you are trying to achieve, generally the WHAT should be most clearly stated by the scenario's When statement. Iff we are writing a scenario about signing in this statement will be 'When I sign in'.  As soon as we start talking about user id's and passwords and filling in fields we have moved onto HOW we are signing in. Features and scenarios are the wrong place to talk about HOW we do anything. BDD stands for Behaviour Driven Development. Cucumber is a tool for describing behaviour (at a high level of abstraction) and driving the development of that behaviour. When you write a cuke you should not be thinking about HOW you do anything because you just don't know enough at that point. When you write a cuke all you should be thinking about is WHAT you are doing and WHY its important.

The question you asked is 'What about the detail, where does that go? The answer is anywhere but the feature. The best place for the detail is the application itself. Have you come across the phrase 'the map is not the territory' ? Your cukes are a map. They should be a high level map like the London Tube Map. They should not be a low level map like a street map (e.g. an A-Z). When it comes down to it any sort of specification is only going to be a map, its never going to be the territory. Its pointless trying to define every detail of how something should be done before its done, because:

1. You don't have sufficient knowledge until you've actually done it, and 

2. Its just not possible to define everything even after its been done. Any definition you make will always be a map, it will never be the territory

Once you really understand this it becomes clear that you have to look at the territory (interact with your application) to ensure its what you want. Having a useful easy to read map can help with this, but thats all it can do. You still have to review and iterate and user test etc. etc.

So your cukes should be a useful map guiding the business and developers around the application. They explain, at a high level of abstraction, WHAT the something does and WHY it is important. When you implement a cuke you write code to exercise the functionality (your step defs and helper methods) and this drives the development of the application code (your territory). Because the map is embedded in the codebase and actively drives the codebase, it can remain current. Like any map it acts as a starting point to access the detail which helps us explore and understand the territory.

The process George and Konstantin have illustrated can be thought of as creating a more useful map. The maps you currently have very little utility. They are very difficult to maintain and cannot be easily read. Hopefully you can see the improvements.

The happy path of any piece of behaviour no matter how complex can be written usefully in a 3 line cuke. So

Given I am registered

When I sign in

Then I should be signed in

You can apply that to something really complex. Lets take an ecommerce application as an example and deal with re-ordering you favourite order. Now clearly for this to work you have to able to do alot of things including

- registering

- signing in

- making some orders

- choosing a favourite order

and for these to happen you need alot of setup. But all that behaviour will have been covered by previous cukes which will have steps like

When I register

When I sign in

When I make an order

When I view my orders

etc.

So you have alot to build on. Realising this you can write

Scenario: Re-order favourite order

  Given I have a favourite order

  When I re-order my favourite order

  Then my favourite order should be re-ordered

and you can use this to drive the development of this new piece of behavior and explore interesting things around this behaviour like substituting an out of stock product in your order etc. etc.

One of the most important things about Cuking is finding and defining simple words and phrases that describe succinctly something that is complex. What you need to do with your scenario in your original post is find these words, so you can write your 3 line cuke. Finding these words is immensely useful for developing your behaviour. Its almost impossible to imagine talking about ecommerce without the concept of an order. But thats exactly what you are doing in your  scenario in your original post.

All best

Andrew

--

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 behaviordrivendeve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/e05b4b2a-90ce-4eb5-a5c2-467ab8249936n%40googlegroups.com.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Liz Keogh]

Hi David,

Everything that everyone else has said stands, but I wanted to just look at your scenario and see if, without changing any of the actual steps involved, we could make it a bit more readable.

One of the things I like to do is to try and make scenarios more like the conversations. Sometimes that means a bit of work at the back-end; for instance, getting steps to match with clever regex, or parsing longer lines of text, etc.. But that's just a coding problem. Putting the complexity where it belongs (in the code) can make the scenarios read more clearly.

I gave it a go and came up with these snippets:

Given a drive X with projects A and B
Given A has A/C: 88, 89
And other projects and A/C also exist

Given Format 'PCM1' has a file dated 20032015
And that file contains Sample rate options "60", "300", "10"
And Audio options "None", "Combine", "Audio only"
And Exercises "300-A", "300-B", "310-A"
When the FTE selects mode "Playback", drive "X" and project "A"
And also selects A/C "88", field "TSN/FLT" and value "FL002/TSN009"
And also selects...

I'm not sure how closely these match the way that you think of or talk about the domain; just wanted to give you some ideas about how you might format these differently. Cucumber etc often use quotes to make it easy to pull out arguments, but you don't have to do that; the regex can be more clever if you need it to be.

It's also OK to use scenario background and tables for default data, too.

Sometimes I find it useful to get a few scenarios and look at what changes between them. That gives me a clue as to what needs to be called out and made apparent in the steps. The examples you choose should illustrate the system behaviour. What causes different fields to appear? Does it actually matter what else is present - can you make it just "sensible defaults exist" like I did in the first snippet (" And other projects and A/C also exist")? Shortcuts like that can help to remove crud and draw attention to the things which matter.

It's also OK, if you're deliberately talking about the behaviour of the GUI, to make the outcomes reflect that:

Given the FTE has selected "Playback" mode (etc.)

When they login

Then the Audio, Exercises, A/C and Wibble fields should be visible and enabled

Another principle I use is that if there's only one state and no behaviour, it doesn't need to be described as part of the scenario. So if the Audio fields, for instance, will always be "None", "Combine", "Audio Only" then you can just say something like

And the fields should have appropriate values

And again, move the complexity of that step into the code and out of the way of the reader; unless there's a situation which causes the fields to be different in some way, then make sure the context which causes that difference is apparent.

Note that describing the GUI this way is unusual. It's more common that people are just using GUIs to get things done, so you'll hear people talk about declarative vs. imperative and how you shouldn't mention GUI elements. If you're actually in the world of producing GUIs regardless of their use, then mentioning GUI elements is OK. If you're in the world of playback of recordings, though, don't check the GUI; nobody cares about it. They care that they can use the GUI to do something, so describe that scenario and don't mix domains.

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 behaviordrivendeve...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/074a9f5d-fe77-44b1-aa70-d58bc3112705n%40googlegroups.com.

--

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

[c...@canvaspixels.com]

Hi David

I'd agree that it's bad practice to mix them and good to have an abstraction into the WHAT as Andrew says. This is something i've explored with Courgette https://courgette-testing.com/bdd. 

You spend more time reading your scenarios than writing them so it's important to understand what things have been covered off as a project grows and nice to socialise what is being tested with automation to less technical people and manual testers. I find if you don't translate to the WHAT from imperative HOW steps you start to glaze over when you step back from the tests and it's difficult to have a good overview if that makes sense.

The steps in Courgette are templatable so you can use outlines / backgrounds and tables nicely.

In future Liz i'm considering moving to a fusion of playback of recordings and it's current hand-crafted approach as an experiment. For now the hand-crafted approach works very well with the teams that I work with though. Anything to speed up anything mundane though and focus on stuff that requires real thought! :)

Regards

Alex

[Liz Keogh]

Hi Alex,

> In future Liz i'm considering moving to a fusion of playback of recordings and it's current hand-crafted approach as an experiment.

Re playback of recordings - I've found myself revisiting, more positively than I used to, the idea of test-after as an approach, especially with things like approvals testing.

I think that as long as you're having the conversations which lead to a really sharp focus and clear prioritization, great MVPs, understanding of scope and behaviour, etc.; and as long as those are recorded somewhere (like the blurb in the test file or a story / example map for instance), and can stay alive, then how you actually make things testable is a separate concern.

Having said that, they do still need to be testable. I think one of the downsides of the record-and-playback approach is that testability concerns often get left out.

So for instance, I'm seeing people do things like change the date & time on their server - with all the associated licence, security certificate and treading-on-other-people's-tests problems that result - instead of injecting a configurable clock as a parameter. I see many recorded journeys, instead of great design and unit testing, leading to very slow tests that end up having to be run overnight (and of course the feedback loop on those is slow enough that the first set of problems never really go away). Someone on Stack Overflow is asking now how to tell if steps are going to clash in Cucumber without running them, and I couldn't imagine the scenario which led them to need that, until I realized that yes, they're probably running them overnight so looking for quicker feedback on test failures, rather than fixing the tests to give quicker feedback on their code.

So while I think test-after, recording, etc. has its place - especially for getting a legacy system quickly under test and starting the road to stability - I don't think it can be a viable strategy long-term; or, if it is, you're going to need to be clever about it; having widgets which do the time injection etc.. that can also be part of the recording. (I have actually done that; sometimes having a test UI can be just what you need, and helps the testers out too.)

But you need to get the team talking to their testers regardless. And this:

> nice to socialise what is being tested with automation to less technical people and manual testers

That's really, really important for getting this stuff working at scale; also sharing how you do it, not in terms of step detail, but in how you solve environment issues. The skills to do this well are still in short supply IMO.

Cheers,

Liz.

To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/dd85d6aa-0224-4f22-a3a8-b399f9a69b5dn%40googlegroups.com.

[David Shavit]

BSD

 Hello everyone

 First I want to say that this is my first topic here in the forum, I have to admit that I a bit surprise from the high level responses 

It seem that beside the fact that the authors here are highly professional there is noticeable unique spirit for sharing how to do things right and more accurate and that should be admired,  So Thanks a lot!

I just want to summarize what i have learned on this topic. I got a lot of insights. Some  of them focused on the BDD`s philosophy and other important general ideas other were more specific about how to write  more readable specs and how to do the distinguish between details and the major route, so these most of the insights:

1.      Use the language and terms used by the domain experts

2.      sniff around them when they are alone to find their exact business terms

3.      when neglecting the domain language the specs disconnect each other

4.      Inevitably the spec should focus on the gui when it`s the current domain 

5.      it is necessary to understand what is the purposes and goals we want to achieve which the scenarios will describe

6.      the main goals of bdd is to communicate within the whole disciplines , document in story manner, and validate it against the system developed

7.      indication that the scenario is not in  correct story manner it cannot be repeated by one of the team mates

8.      bad practice is when scenario look more like test script and less like a well-documented and interesting story to tell some team mate

9.      unreadable scenarios led to lose the motivation to read and maintain the scenarios.

10.  indication of well written scenario is when it cause questions to pop-up

11.  Login window isn`t system function unless it determine who can get authorize to data and what kind of data to access.

12.  Scenario should split thus handling one issue each time

13.  mention only must-have details on your scenario, those that influence the expected outcome

14.  Login window should have sad path either

15.  scenario should describe the WHAT instead of the HOW aspect. The WHAT part usually expressed in the WHEN gherkin's phase

16.  considering login window then entering user name and password belongs to the HOW aspect

17.  BDD scenarios main purpose is dealing with the WHAT from high level view, drive the dev team toward desired behavior.

18.  specs aren't the right place for details. The details lays in the application itself, like Map which describe the territory.

19.  Like as a map the scenarios are only entry point for digging the territory.

20.  Scenario like continue to be updated because it coupled with the current code.

21.  Scenario happy path should be written using three line`s spec

22.  One of the challenges to write the scenario is to find the accurate words which making complex matter to light heavy one

23.  Good practice is to hide the over details into the code

24.  Use background to avoid duplicating

25.  Comparing scenario helps to identify the details they don`t matter to specific behavior

26.  Constant conditions should be mentioned shortly i.e.  this matter is in "appropriate manner"

27.  There should be thinking about what is the correct domain. GUI itself sometimes is the correct domain.

28.  Record and playback testing pros and cons

Thank you all, this conversation has tremendous value for my retrospective and I'm sure it`s will be for future readers

I`ll we be happy to read your opinions on the next retrospective issues

David

ב-יום שלישי, 10 בנובמבר 2020 בשעה 14:09:53 UTC+2, Liz Keogh כתב/ה: