I guess we're talking about two different approaches to solving the same problem (code-based tests can't be used by non-technical people). So we can:

1. Substitute writing code with a visual editor. This is, essentially, what Screenster does.

2. Make scripting abstract enough to a point where it starts to resemble plain English. That's, in a nutshell, the approach of Cucumber.

Each of the two has its pros and cons. In my opinion, the key strength of tools like Screenster in this context is how they address visual/css regression testing (specifically, things like text or image formatting issues, layout issues and other things that typically get broken by CSS updates): http://screenster.io/a-better-way-to-do-visual-regression-te...

Ehhh I don't agree that that's the case. Any time I've dealt with BDD I have to add more / rewrite the backing bits constantly.

For this reason, much prefer test-libraries that read more like BDD cases without actually trying to invent a new DSL for me to maintain on top.

This is hypothetically true but I think if you're expecting your manual testers/business to play mad libs with your defined statements they have to be so resilient that they become fairly inefficient.

If that's an acceptable tradeoff for having anyone be able to create new test cases though, it would probably be okay.