My team is about to embark on a rare (for us) greenfield project and -- as such -- we have the opportunity to also introduce some 'next-generation' documentation strategies.  Our Product Dev unit is currently more "incremental waterfall with a nod to RUP terminology" but many of us have bought into the Agile principles and crave the chance to play with some of them on the upcoming project.

My BA team currently documents requirements in terms of use cases and business rules, and we're aiming to start giving more favor to working software over documentation.  The challenge is that our QA buddies would rather we move in the opposite direction and go back to writing the super-ginormous "functional design docs" that we delivered about 8 years ago.

Do you have any real-world suggestions for how we might influence our QA folks in this regard?  The truth of the matter is that the lighter doc proposition *will* require more effort on their part -- to uphold their part of the social contract and to participate actively rather than just listen until we deliver something that will enable them to 'start.'  That is a hard pill for them to swallow, and it's a difficult pitch to make to them.

Thanks in advance for sharing your advice and experience!

Christy,

I have been in your shoes and Tony is completely right. I do however want to elaborate and share a real-life solution that has worked for me. I also appreciate the ability to focus on the software over documentation, but you cannot rule out the necessity for documentation. As Tony said, QA needs the essentials. Have you considered meeting QA in the middle with documentation that provides the essentials, but is driven by the software development? Rather than creating a detailed use case or complex functional specifications document, create a user story with a series of annotated screen shots. Each screen shot will give the QA team a visual of what they need and your annotations can fill in the pieces that cannot be seen.

There are many other suggestions such as this, espeically when a team is working toward rapid prototyping and Agile development. I like to call it being commonsensical. QA shouldn't have to assume or guess; they need what they need. This does not mean that they need a million words when a picture can be worth at least 1,000 of them.

Just pull out your negotiation skills, meet with them and elicite their requirements, then put on your creative thinking hat and come up with a solution that fits both your team and QA's needs.

Hope this helps.

Deena Chadwick