Greetings!
First things first. Finding a clear trail from a functional test case back to the original business requirement from whence it came can be, at times, more difficult that finding a seat at the movies after the lights go dim. There ... I said it. It's an ugly truth, but one that is prevalent - even if test managers do not always wish to expose this gap.
Also, I am not saying that all industries have ambiguous compliancy models in this area. Certainly FDA compliancy standards wield a sharper edge than say ISO standards. Please don't misunderstand, the ISO is a fine organization and the standards they promote are ones that I have always attempted to follow as a QA Manager. However, the risk of non-compliance with ISO is not the same risk type as non-compliance with say - the FBI or FCC - which I have had the pleasure to partner with regarding compliance standards.
Why is it then that the test case audit trail can often be ambiguous or even disjointed? There can be any number of reasons or combination of reasons. Lack of tools and time-to-market pressures are two mentioned often. However, I have seen tools that many times are available but are not used effectively. And, there are always pressures to work quickly. So, what's a QA group to do?
The complexity of SDLC (choose your methodology) precludes a desire to come up with a one-size-fits all solution or have one root cause. I have found that listening to the folks developing the test plans/cases for clues is a great place to start. Some good questions during these conversations that come to mind would be: do they understand and are comfortable with the organizational mechanics of feature development, do they have a good handle on the feature they will be testing and do they know about point-of-origin and justification for the feature? Many times the test group for the release may not have been effectively integrated into the process .... regardless of what the Gant Chart states.
Managers would be wise to be actively involved in the release planning process to ensure that resources are scheduled in the requirements gathering phase - then make sure it happens. The QA folks hold much historical information on feature testing and can contribute greatly during the feature requirement and functional specification development phases.
Also, be sure to explore with the QA group available options to link your test cases directly back through the functional specification to the business requirement. If there is a in-house tool, champion its use. If not, and budgets are tight, champion an effort for using another method. I've seen Excel do a decent job - as long as cross functional groups have ID'd their respective requirements. Consider it a critical path activity.
The key point is that when QA understands the direct relationship between the tests they are executing and the origin of the business requirements, they will have more confidence to champion and chart product quality not only in terms of test pass/fail rates, but also to speak more broadly throughout the organization regarding overall product quality.
Early resource involvement and becoming a champion for a quality process that casts a wider communication net adds value to any organization. And, you'll make the compliance folks very happy!
Fran
Next weeks theme is 'Company Road Trip: To LEAN or not to LEAN .... that was the question'
0 comments:
Post a Comment