TL;DR
In this post I will explain how not to engage in twitter war, but with simple politeness, provoke useful feedback about important topic.
Twitter war is very serious thing. Neil Studd talked about this problem at CAST 2016 lightning talk sessions. During his talk, simple idea popped up in my head. It was time for the experiment.
In my post I constructively object to Gherkin language I expressed my opinion on Gherkin language (which is first part on objection on using UI automation as regression purpose thing).
I always tweet my blog post, and this time I mentioned mr. George Dinwiddie, because he asked my opinion, also via Twitter.
Here was his first reaction:
He used word strawman, and as I did not know that word, i looked it up:
A straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent’s argument, while actually refuting an argument that was not advanced by that opponent.[1][Wikipedia]
So I learned new english word, and he objected that I am using gherkin for wrong purpose.
Here was my response:
So I did not engage in twitter war, I politely asked for a blog post. And we have thoughtful response about gherkin language: Using a good tool for the wrong thing. And that was experiment about idea during the Neil lighting talk.
And Ben Simo also responded:
So now we know true purpose of Gherkin language.
And in my original post I forgot to mention how I get information from business people, what product should do so I can create my testing mission. I get them at the beginning of github issues, as several issue comments, written in plain english language, with references to google docs and pictures about the design of the feature.
Using that feedback, here is my follow up on gherkin objection.
We have product examples that could be automate and run so we have immediate evidence that product actually behaves as this example documents. Which is reasonable purpose.
The problem is:
- when only those examples are used in testing the product.
- they are used for regression testing.
- they are used for UI regression testing (end to end testing) as only automated tests on project
Here is what I suggest:
- do not stop testing using “manual” (highly intellectual activity)
- create test mission “using tools at our disposal, lets find out what exactly changed in product from previous release” and do “manual” testing in that part of product. There is no need for automated regression testing on UI level.
As I find this matter highly important for testing community altogether, I would really appreciate your feedback on this matter.
