jj je pravda, že je tam nějaká práce navíc, ale řekl bych, že ve chvíli, kdy je testovaný "stavový prostor" velký, se už ta investice vyplatí. Příkladem může být, když se napíše testovací krok s 2-3 proměnnými; takový krok se klidně v testech může volat 10x-100x, a takovéto testy dokážou napsat i lidi, kteří to nemají v hlavním popisu práce.
U nás je tým rozdělen asi trošku netypicky - jedno QA na cca 15-20 vývojářů (pořád to trošku rotuje :-). A ti vývojáři píšou různé části aplikace: front end, back end, datové pumpy apod., je tam spousta API a celé je to dost složité. Takže role QA je udělat kostru pro BDD, tj. napsat ty jednotlivé kroky. A vývojáři sami jsou potom na základě change requestů schopni rozšířit .features bez nutnosti znát "střeva" kroků. Tady Gherkin udělá svoji práci, protože na .feature dokáže šáhnout jak skalní front-endista, tak i back-endista nebo člobrda se znalostí domény a již řekněme menší znalostí programování :-)