How do you see Cucumber/feature tests in the big picture of testing?
I think the biggest mistake is for people to see it as a way to pass the test. The best question is how it fits into the organization’s larger image and how it can help org succeed. If you set up a cucumber just to have feature files and basic automation, its full power is not really used.
I see BDD as an engineering organization that needs to get inside - from business to acceptance (even beyond support/beta trials, etc.). When used in that way, it can be a potent tool to make sure org is aware of its products. More importantly, that price understands are delivered (or… can be delivered as it may be). It can really help to create a company culture in this regard. Traditionally if the number has not been met, I have seen horrible finger-pointing. A well-executed BDD removes that and compels the traditional carnage of “How we missed that number” or “Hey, we did not realize the right points of success.”
Indeed, based on exploratory testing, I intend to use art produced from BDD (feature files) as a starting point for execution - not just automation. The org I am in is not mature enough to start beating the default tests for all the features they are working on, but at least for feature files with agreed-upon sets, that will work. We can quickly build automation on that. (Inspired by real person)