I saw this image on Forbes.com and have felt the same way as the seated crew...Presenter blissfully unaware while the audience drifts into oblivion.
QA365
Thoughts on Software Quality Assurance and IT
Sunday, June 2, 2013
Sunday, May 26, 2013
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
Sunday, May 12, 2013
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?
Saturday, May 11, 2013
Friday, May 10, 2013
Subscribe to:
Comments (Atom)


