Adding terminology for QA to create manual test cases with cucumber #329
Conversation
In order to write test case's that can be understood by testers and automation engineers and will not be read by the business. As a Manual Test Engineer I want to be able to write tests in QA centric language that can has potential to be automated. As well as executed manually
Changed scenario outline to DataDriven examples to Tests
Added space to Data Driven added Data keyword back
|
Hi. I too see misuses of Gherkin every day by the nature of my job and even treat it as a part of the learning process (half coping, half coaching mechanism) :) That said, I do personally believe that using Gherkin purely for testing without establishing communication part of BDD is very inefficient and painful way of doing automation. I fear officially supporting such usage would only cost us more hatred and horror stories from people burnt by the tool. |
|
Yes I agree with you about the communication part wholeheartedly. I struggled with the idea whether to even submit this pull request. My reaction, had someone else posted this request probably would have been exactly the same as yours. However I am forced to misuse cucumber on a daily basis and part of me, would rather have a language that reflects their use of the tool, than to continue to read reams of "and then and then and then" and be disheartened at how my team is failing to understand how to use the tool, and my inability to change that understanding due to culture, time constraints, the business simply unwilling to change or spend money for training, and I do not have the ability to veto the decision to use cucumber in favor of another tool. I wouldn't expect this to be an advertised feature. It could sit there quietly and only be known to a few people who find it useful. Like texan or lolcat. |
|
I welcome this addition, and I agree it could be kept as a option for those of us in situations where we require it. Gherkin works great for QA teams who do not have a standards for authoring their test cases. This could become a gateway syntax, which would ultimately help bring a larger audience to Cucumber and Gherkin. I especially like the fact that the enhancement can be implemented transparently using the existing language feature. |
|
I'm torn with this one. I understand the purpose and I like the idea of making the "type of use" explicit, in theory. However, I can see how in practice it will be interpreted as if we're endorsing the use of Cucumber (and gherkin friends) as a pure testing tool (something I and others are advocating against). Should the |
I see cucumber misused by QA teams so much in the wild that I feel like there should be some bridge behind the behavior driven development with behavior driven automation. Also some way of transitioning manual test cases to automated tests. I think over time that an organization should choose BDD over BDA .
Since the real benefits of cucumber lie there. My hope with formalizing a QA domain in Gherkin is that perhaps being able to show the difference between BDD and BDA will un-muddy the waters and address the two different types of approaches that exist in the wild.