Identifying the right Software QA Models to meet your product QA and Testing needs can be a challenge at times. In the coming days we will review various aspects of how Software Models and tools can improve test coverage. Today we wish to introduce an interesting model QQA (Quantify, Qualify, Automate). QQA is a QA process methodology that addresses all complexities of contemporary fast-paced software product delivery. QQA stands for the three facets of QA namely -

QUANTIFY of QQA is the ‘granular Sizing’ of an application so as to consolidate all aspects of application behavior in its Testable totality. QUANTIFY involves technology as well as persistent best practices to ensure that the Test bench is persistently comprehensive, resolved and structured to trap all possible facets of changing application functionality. QUANTIFY distinguishes the QQA Model from other Software QA models by the ‘Application Discovery & Profiling’ exercise that documents the product’s entire gamut of Testable behavior in both the Black-Box and White Box contexts.

Read more »

The best answer is definitely the traditional one. Requirements are frozen upfront. Test case development happens parallel to scripting at White-Box & Black-Box levels. Testing is launched at pre-defined milestones and defects identified which are resolved on a prioritized basis by Development. Integration & Acceptance Testing are launched when the Product is announced for Delivery by Development.

A final debugging session, final regression and Release notes…
Bingo!! The Product is released to the market.

If the world was indeed so smoothly theoretical, you would not need a testing model after-all. The complexity of a testing model involves in addressing the perpetual instability in requirements co-parallel to or fast in the heels of Product Development. Thus testing has to address turbulence of fast-changing functionality and mapping this turbulence to visible & near-comprehensive Test artifacts. In such a case there has to be a high level consensus on a testing model or QA discipline. This is the practical ground in which a testing model is honed and implemented.

However one question that needs to be addressed is how do you map changing requirements to automated script maintenance?
Remember, Changing requirements by themselves or Test script maintenance by itself does not demand a testing model; BUT synchronizing ONE to the OTHER definitely does.

All in all, a Testing model is essentially the ALM (Application Lifecycle Management) constituency with its component-interplays that are the best suited for any specific Product development & Delivery situation. And a testing model is an evolving paradigm that hinges on some priority cornerstone and gradually scopes more and more areas in the SDLC with a streamlined workflow.