An interesting question popped up on Slack recently that I thought should be continued here to preserve the replies 
how does this channel see cucumber / feature tests in the big-picture of testing?
Another member of the channel replied with
I think the biggest mistake is people see it as a means of accomplishing testing and the better question is how does it fit into the big picture of an organisation and how it can help an org be successful. If you stop at just cucumber as a means of having feature files and underlying automation then the full power of it isn’t really being utilised.
I see BDD as a whole as a mindset an engineering organisation needs to plug into - from business all the way through to acceptance (even beyond into support/beta trials etc). If it’s used in that regard then it can be a very powerful tool indeed for making sure an org knows about its own products but more importantly udnerstands the values that are being delivered (or…not delivered as it may be). It can really help shape a company culture in this regards. Traditionally if a value isn’t met, I’ve seen horrible finger pointing. Properly executed BDD takes that away and forces a multi-disciplined post-mortem of “How did we miss that value” or “Hey, we weren’t monitoring for the right success points”.
Sure, purely from a testing perspsective, I intend to use the artefacts produced from BDD (feature files) as a starting point for execution - and not just automation. The org I’m in is not yet mature enough to start banging out automated tests every feature they work on but at least with feature files they have an agreed upon set of test cases to run. We can then easily build automation into that.
What about you? What do you think?