|
The problem is there are three to 4 veins of QA. SDET (largely automators, tend to scale and manage the automation), analysts, who go over test results and pull out trends, manual testers/non-automators, because nothing brings out the bugs/bad assumptions like putting a non-techie in front of something, and then... well, I'd lump software maintainers/DevOps into it too. I'm not impressed at all by Gherkin, BDD, or Cucumber. Never once has any business person gone "oooh, let me read the tests!", And in the rare circumstance they do, what you'll find is a secondary grammar develops where particular step implementations gain loaded significance, far and above the natural language implementation of a step, making things complicated. At this point, I just tell people to keep notes, make checklists, get familiar with the data model for test data authoring, then go eith God, and always put the User first. Mileage varies greatly, but there's a culture problrm in a lot of places where "the fiture must go out" always takes precedence over "the spec must be right". And no one ever wants to rip apart testing tools to figure out how they work. |