Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  struggling to break QA's addiction to our old Ginormous Functional Design Doc
Previous Previous
 
Next Next
New Post 4/19/2012 9:41 AM
Unresolved
User is offline christy
2 posts
No Ranking


struggling to break QA's addiction to our old Ginormous Functional Design Doc 

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!

 
New Post 4/19/2012 11:07 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: struggling to break QA's addiction to our old Ginormous Functional Design Doc 

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

 

 

 
New Post 4/23/2012 6:47 AM
User is offline JewlTone
2 posts
No Ranking


Re: struggling to break QA's addiction to our old Ginormous Functional Design Doc 
Modified By JewlTone  on 4/23/2012 7:59:15 AM)

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

 


Deena Chadwick Manager, Business Analyst http://www.becommonsensical.com
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  struggling to break QA's addiction to our old Ginormous Functional Design Doc

Community Blog - Latest Posts

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...

 






 

Copyright 2006-2023 by Modern Analyst Media LLC