How best to 'leanify' test case documentation?

Question

I'm currently reviewing some test case artifacts for various project teams as standardized by our organization. However, I'm a bit appalled to find that a lot of content is being captured in documents and is leading to wasted effort.

What are some lean ways to capture/document test-case descriptions that you have seen being applied successfully keeping 'everyone happy' (i.e., no one complains about this & that missing).

Currently here's an outline of what we capture just for a single test case:

1. Test Case ID
2. Test Item
3. Test Priority
4. Pre-conditions
5. Post-conditions
6. Input Specifications
7. Expected Output Specifications
8. Pass/Fail Criteria
9. Assumptions and Constraints Dependencies
10. Traceability

Of course test-case ID/item are autogenerated for the most part. But that is still a lot to capture. We capture our requirements as user-stories but we still need some detail for our test cases. I'm just worried that the detail may be just too much. There are other details too, like type of test case, time/effort estimate etc.,

So what are some suggestions of making test-case documentation 'lean' to eliminate/reduce this documentation overhead? (Just capturing the test cases on the back of story cards is not acceptable for our organization. Tools/format suggestions are both welcome. Basically ideas to help reduce the burden of documenting test cases.)

Answer 1

First, a modern testing tool could greatly improve productivity. Microsoft Test Manager, when fully integrated into a Team Foundation Server installation, is my personal favorite. There are others however that will probably give you much similar results.

That being said items 1-9 on your list appear to be a fancy way of saying "things you have to do to run this test". If that is the case, then if you plan to do regression testing with any measure of repeatability you probably need to capture all of these.

10 however should only be captured on failing tests, as it is a waste of effort for passing tests.

"So what are some suggestions of making test-case documentation 'lean' to eliminate/reduce this documentation overhead?"

Based on this quotation, I believe you may be missing the point of lean software development. Is the test case documentation you currently capture a bottleneck in the flow of value through your system? Have you optimized your batch sizes to meet your existing process? Do you have WIP constraints that you can alter to adjust the flow?

Also, "keeping everyone happy" should never be a goal. You need to worry about your economics.