Lots of times when it comes to QAing it's hard to remember every aspect of the product/feature to test.

Does anyone out there document features as they're designing them to use as reference for design, engineering, etc. when building and when QAing?

This might be hard to fit in this space. I will need to link to my example.

Right now as the UX and UI/Visual designers, when we are doing our mockups for the programmers, we include Cucumber files with each that detail every aspect of every interaction and UI. We have a requirements document as well, but it is not this detailed.

The developer (and QA) now have a documented source of how things were intended to work, and something to test against. The devs can use the files cucumber .feature in their automated unit testing when they run a build. That way once the build is done, you can be sure the cucumber unit tests pass, and QA also has them for reference.

Here is a fictional feature file: gist.github.com
And cukes.info

Also - you don't have to do it in Ruby, there are ports to other languages, like javascript/coffee: github.com

At any rate... BDD is just essential for modern UX in my opinion. Tying in the UX logic into the unit testing and development is the way of the future.

en.wikipedia.org

interesting... thanks for that

at branch, the front end devs ARE the designers so we never do mockups to pass, so this type of documentation is extremely nitty gritty and probably not worth the time until we do have dedicated front end devs.

If you're doing the hardcore JS and front end work, then maybe a requirements document is more appropriate. QA still does look at our .feature files and scenarios though.

I work on extreme enterprise browser-based software though and haven't used these methods on things that aren't of this nature. Seems like the scenario portions only of the .features though would be a whole lot easier and not as nitty-gritty as going through the steps (the "given, then, then, and, but, then..."). For a given "feature", 4-6 scenarios might be enough.

Scenario: If the user has no notifications, they will see the notificaton box as grayed out with a zero in it

And that's it. I guess I don't know the context of your question.

Yea sorry - right now at 7 employees we do all QA ourselves and find it hard to remember everything to treat, and we don't have resources to do something as detailed as that cucumber. Just looking for examples of less technical documentation (or maybe it's not even documentation) that keeps everyone on same page and helps QA

Well we also use a PRD which is very generalized. en.wikipedia.org

If it were me, I'd take the basics of that and trim it down to like, a quarter-page per feature of just plain-speak descriptions. Maybe when you start a discrete feature you just write like 300 words (two twitter posts) of requirement?

Maybe from a black-box QA slant, you do like 150 words on what this feature is trying to do, and then another 150 how you expect this feature to work?

Like for this comment box url parser: "The comment box url parser should allow the user to paste a link without html. It should go fetch the title, favicon, first few words, and then put it as a url attachment below the text entry."

This is a rad problem. I've never thought about it.

BDD/Cucumber is absolutely fantastic for documenting product features/scope; we often use it in meetings when discussing interactions etc.

For QA - we just make sure the tickets on our kanban board are granular enough that when they get to the QA column they're self explanatory.

@jon could i see a photo of your kanban? really intriguing

Yes, I would like to see it too. I am thinking of starting a Kanban system for my UX team. I have always had these notions of building a webapp where you had infinite recursion layers of kanban, where you can zoom in our out through levels of detail through each item.

c.jon.gd

Freelancing at the moment; best one I've come across (and the one I was talking about) was at @evently. Annoyingly this is the only photo I have of it.

Columns (left to right):
Icebox (roughly prioritised), Business Analysis, Design, Tech Analysis, Backlog, In Development, PM Sign Off, Pull Request, QA, Ready to Deploy, Beta, Live

Rows (top to bottom):
Rapid Response, Marketing, Product

The columns weren't perfect (I think PM Sign Off, Pull Request & QA are in the wrong order - why PR before it's working?), but it was good having a real physical board to stand around every morning.

It was totally low-tech; the point is that by the time a card had made its way across to QA it was pretty well-known what it was. If there was any serious description needed then that could be added to the corresponding Redmine ticket.

this is awesome. we use pivotal here, but i think the lack of a physical presence really decreases the effectiveness of having an organized list of things to do

We use Pivotal too. When people look at it.

i think we've quite gotten off topic, but whatevz

The point is, documenting features for QA seems like it belongs to the ticket (in whatever form you have that ticket) rather than in a wiki or something.

For QAing, we can immediately create a Wiki doc explaining each and every detail of what we functionally and visually expect the devs to refer and execute. Same applies for QA.
After the development process, we can do a UX/ UI review and log bugs assigning it to respective dev to look at and then confirm its fix. After that, QA can get involved and keep logging bugs as they point out more functional/ UI bugs/ breaks/ Smoke and so on and so forth. Fogbugz is a really helpful utility for this.

Pivotal seems to work for us, once we accepted the fact that we had to use it. All stories are accepted and then moved over to the QA group to use as a jumping off point for testing. Pivotal is not a perfect tool, but I have yet to see one that exists.

In addition to user stories, if there are new features, or complex interactions, mid/high-fidelity prototypes should come in handy here. Obviously you need the resources to create them, but this is only one of many instances where they are useful (throughout the process from user testing / discussion / scoping / stakeholders, etc.) - This becomes the spec, which certainly makes it easy for QA to compare against.