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:
Per Scott Ambler, Agile, while being about minimal documentation, is also about quality documentation. Quality minimalist documentation is, to be more specific, about documenting the essentials - and only the essentials.
So what are these essentials? They are essential (i.e., unchanging, business oriented, solution independent) behavior and - most importantly - the interrelationships between these behaviors. Think input, process, outputs. And think higher levels of abstraction. These are logically business analysis activites (irregardless of job titles).
Per Agile; let the lower level be handled by developer - and tester - discussions.
Input, essential process, output, to the correct level of abstraction is what your QA folks need (I have significant QA experience). They intuitively know that if they get such, they will not have to sweat the details. What they are really afraid of is not getting the essentials. That is why the want the extensive documentation - hoping upon hope that at least some of it will be what they need for test case development.
Tony
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
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: