Sharath recently wrote a blog post to which I decided to write my own post in response.
Sharath's post is here.
Sharath mentioned being slightly confused by BDD and ATDD which I see a lot, however the confusion I see is based on my ideas of what is what, make your own up and decided.
I've included some stuff from Liz as she writes better than me do write as well as my own 2 cents.
ATDD vs. BDD, and a potted history of some related stuff
Acceptance Criteria vs. Scenarios
What is interesting to me though is that as far as I've seen, ATDD doesn't include the business as much as BDD does. I see a lot of Testers and Devs getting together for ATDD and for BDD alot of everybody getting together like PO's, BA's, business people, etc. That is where I personally see a difference. I prefer BDD and getting as many people as I can involved.
On the other hand, call it whatever name works for you.
Back to Sharath's blog.
One of the things that can (and in my opinion should) be done is that every time a bug/issue is reported automation is written that would find that issue before the issue is fixed - essentially creating a regression/consistency suite/pack/whatever.
As well as automating any useful information gained from the ET.
I've also tried to use a test points reference (idea from paper by James Lyndsay and Niel van Eeden) with little success, mainly as I didn't push it hard enough.
What I have done is similar to what Sharath has done and created a mind map with areas for further investigation/automation. Had slightly more success with that.
If you don't have people to automate you can essentially use your regression doc (mind map, doc, whatever it may be) to cover off areas, splitting it between the whole team.
I also try and push the idea of a demo before check in, together we can spot anything obvious before it gets checked in (and therefore a bug/issue).
There is really no one answer, is a case of finding what works for you with the people you have.