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 8: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 10: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 5: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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC