Simplicity in QA Test Planning: 3 Steps to a Simple Test Plan

Simplicity in Test Planning 

Its difficult to be everything for all audiences, especially when you are writing test plans (test approaches), test cases and runs.  Certain elements make up a simplistic design for planning software QA testing.   Under the the guise of a more Agile approach, you can achieve a simplistic test plan that will cover all the bases. Your customer will want to see your plan of attack for covering the maximum amount of code. There are a few tips that can lead you to create a simplistic yet elegant test plan that will keep the PMs at bay so you can do what you do best... TEST!

Step 1 : And your audience is.....

Many environments dictate very strict adherence to methodologies and are critical of all deliverables and put the emphasis on writing.  Too complex and you risk an ineffective document.  Decreasing complexity increases your chances of winning the audience over,  Find the right amount of complexity.  One of the redeeming qualities of the graph above does nicely show a bell of increasing your elegance to achieve simplicity.  If your audience is less technical, it works!  But for dev types elegance probably will not matter much and the points on the leading curve to the peak might do well.

Step 2 : Outline with elegance

1. Description
2. Business Benefits
3. Scope 
4. Assumptions
5. Security Concerns
6. Environments and configurations
6. Data Population and staged data
7. Unit Tests that have value
8. Automation Tasks
9. RTM's (make them easy if it takes longer than one hour, not worth it)
10. GO Live tasks
11. Metrics 

Step 3 : Present details in person

I find that presenting findings in a meeting or informal setting is far more convincing than emailing or posting a document or report.  Answering questions naturally should always decrease complexity.


Note:  I would suggest to check out William E Perry's Effective Methods for Software Testing.  It is a fantastic read and provides a reference for beginners and a good refresher for the pro:  http://www.goodreads.com/book/show/2653065-effective-methods-for-software-testing-with-cdrom

---DBR

Agility in IT/QA

Agile is new....hardly.
Agile is ineffective...no.
Can we switch to Agile?....yes.
Will all buy in?.....no


After spinning around in methodologies over the years, my thought is that Agile  can be a better sell than alternative methods. Here is a snippet from the Agile Alliance circa 2001:

We are uncovering better ways of developing software by doing it and helping others do it. 

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Seems simple, right?
.

People have ideas and mold Agile to their individual experiences and ideology......People over process.... check

Documentation needs to happen organically to enhance the software but not in spite of the app.  No need for test plans here.  But scripts can be helpful when done simply and perhaps only for automation... We all need to report up to our managers, true?  Do it through show and tell sessions.
Do not get trapped in novel writing.....check

Agile teams should have an engaged owners that is a customer, BA, reporter..... having the product owner involved and committed to the team keeps all in lock step ......check

Change.  When you embrace change the software scope tightens to mold and fits the beliefs of the people....check

Seems simple, right?

Views on Agile

Art is Agile

QA365 Launch!

Welcome to QA365!