Gerkhin - how do you write an unambiguous test in English?

Question

English can be ambiguous, and it seems to me that in the methodologies that Gerkin use, there is an assumption that anyone who speaks English to some extent can write and understand test cases, even before any any code.

So, how the technique gives you the right to work, given the following simple test scenario that requires automation:

In the Library application, to add a book to the library, the user clicks Add, the Book Information dialog box appears, and the user is expected to fill out the title of the book, etc. "and click OK.

Suppose a QA person writes the following:

Scenario: clicking the Add button Given a user who is already logged in to the application When the user clicks the Add button Then the Book Info dialog is displayed 

Simple enough? Is this a good test? I think I speak English, but I don’t understand this.

The fields in the dialog box should be empty, perhaps some fields should have a default value or an initial value. Perhaps the tester expects that the dialog “Then displays information about the book” will be implemented to ensure all this, but does the developer know this? how is this reported?

Perhaps the test should have been written as

 Scenario: clicking the Add button Given a user who is already logged in to the application When the user clicks the Add button Then the Book Info dialog is displayed and all the fields are empty 

This may take a couple of seconds between clicking the Add button and the dialog box. Thus, the test may fail because the implementation is checked too quickly if the dialog is raised, or did not wait long enough until the dialog appears and the test fails.

The person conducting the manual testing should not be involved in this problem unless too much time appears behind the dialogue. Thus, the above is exactly how this person writes the test (so here it must be said that the tester must be smart enough to take this into account, or some developer should explain it, or just fix it after how the test failed).

Be that as it may, this simple action requires additional information ... when is it transferred between the person who writes the test and the one who performs the test?

Perhaps the test should have been written as

 Scenario: clicking the Add button Given a user who is already logged in to the application When the user clicks the Add button Then the Book Info dialog is displayed within a couple of seconds and all the fields are empty 

or perhaps it should have been written as:

 Scenario: clicking the Add button Given a user who is already logged in to the application When the user clicks the Add button And the user waits a couple of seconds Then the Book Info dialog is displayed and all the fields are empty 

Is the person who wrote the test in English expected

• write all the expectations in a test action, for example. "Then the Book Information dialog box is displayed for a few seconds and all fields are empty" or
• write a short instruction, as in the Book Information dialog box, but then write an additional document that describes (in English) what is meant by this statement and what are all the expectations?

Answer 1

In general, I would argue (closer) the second.

If you pollute your scripts with repeated “noise,” adding assumptions, you have lost the concise, targeted ideal that BDD seeks. It also becomes difficult to find out where to stay.

However, if your plot / script has special requirements for them, or even if you expect this to affect them, there will be nothing to stop adding additional sentences, such as And all input fields are empty .

Remember that if you use a flexible methodology , such as Scrum , you will have a separate definition of "Finish", which, although more business processes or processes, may contain "global" requirements for the adoption of the story. These may include test coverage levels or performance requirements ... perhaps close enough to what you are discussing here.

Answer 2

I would say that your problem starts with your poorly written (and poorly thought out) description of the script, and this error cascades into your scripts. "Clicking the add button" is not a script, it is a step. And you even implicitly admit it by making it your step .: D

If I don’t know what your user’s goal is in this scenario, and what you are trying to prove to the user using this test, then I can’t tell you how specifically you need to include or not include in your actions.

And, without any explanations and assumptions that you offer in the question, there is no way to extract it from your script text.

So, here is a crack with the correct description of the scenario:

  Scenario: An authenticated user invokes the add book dialog 

But the problem with this scenario remains. Namely, this is still not a scenario. This is an action taken under certain conditions. All this. I still don't know what the user is trying to execute.

 Scenario: An authenticated user adds a new book to the library database 

Now I know for sure who the user is, what the user wants, and what we promise this user: he will be able to add a new book to the library database.

And now I know that my test must prove: that the book I (as an authenticated user) tried to add is actually being added to the database. And now I can build the full script as follows:

 Scenario: An authenticated user adds a new book to the library via the add book dialog Given I am an authenticated user And I have a new book to add to the database When I add the new book via the add book dialog Then the book info is displayed in the book list 

You can use step definitions to create a reuse code that "adds a new book through the book add dialog" or verifies that "I am an authenticated user", or ensures that "book information" is displayed. And in this step-by-step code, you can be as explicit as you like.

But if you use Gherkin to validate the input field, then you are testing the wrong things. If you want to check that the input fields are correctly empty when the dialog box is displayed, you should write javascript unit tests (or php, or python, or ruby). If you want to verify the validation of input fields, you must write unit tests. If you want to check the correct behavior of a dialog box or light cell, you must write functional tests. If you want to check whether the data in these fields is stored correctly in the database, you must write functional integration tests.

But if you want to verify that the promises that you make for users are saved, then you should write Gherkin. Rather, your Product Manager and your Test Automator should write it. If your test machine is trying to write unit tests with Gherkin, tell him that it does it wrong.: D