Test Strategy

I recently received a query from a friend about Test Strategy and asking to shed some light on this topic. Whilst there is no dearth of information on this subject, sometimes you can end up with too much information and my good friend was keen to have a brief summary of the topic. Well, considering that its been a while since i've posted anything in the QA & Testing section, I thought, this reply to my friend could serve as fodder for a blog entry (what was that about two birds and a stone ...). Without much ado, here's what i intend to tell my friend.

The Test Strategy :

Is also referred to as Test Approach and is basically a plan of action. You could also call it a road map or blueprint that seeks to provide direction to your test efforts and tries to clarify how Testing will be performed; put another way, the Test Strategy communicates how you will go about achieving your Testing goals.

Some of the areas that the Test Strategy clarifies may include, the types of Testing to be performed, the resources needed, characteristics of resources required (e.g. in case of human resources, the skills needed, experience, etc.), dependencies and environmental needs for testing, the configurations / scenarios / matrix to be tested, the when of Testing (time lines & schedules), criteria for measuring success of testing, other prerequisites for testing, scope / extent / boundaries of testing, any tools needed, defect tracking / management, any risks perceived / analysis,  any  other items as may be  needed / apt for your specific product / project.

Developing a Test Strategy involves asking a lot of questions and communicating with various stakeholders as you piece together the elements of your specific plan. One of the positive outcomes of this exercise is gaining a better understanding of stakeholder expectations from Testing and helping avoid expectation mis-match.

An obvious attribute of a Test strategy is that its not etched in stone, meaning it can and most likely will undergo changes / updates. You start developing your strategy with the best information available at a given point of time. Of course you can wait until you have all the information you need but it just might be too late to be planning. Start with what you have and try to get at least the high level pieces  together. You can add the details as you move ahead and gain more information.

As Charles de Gaulle said, “You have to be fast on your feet and adaptive or else a strategy is useless."

Add to Technorati Favorites | Slashdot   Slashdot It! | Submit to del.icio.us


To add, the test strategy is an explanation of different aspects of testing. It is different from a test plan, which is more specific. I suppose a test plan will be dealing with specifics like the sequence of specific test activities and time frames.

A test strategy will answer questions like what, why and how. Where as a test plan is more based on when.

Posted by Muhammad Rizwan on February 12, 2009 at 09:23 PM IST #

Lets just clarify a few things here because there is a lot of misunderstanding in the industry as to the purpose of a Test Strategy or Generic Framework as its often now called.

Both the text provided above and the comment are right in some aspects and wrong in others.

Lets start at the top. Ideally and organisation has a test policy which sets out certain goals and objectives of the organisation. These can be as high level as " Product quality must increase by 25 % by 2012" or "The functional test teams must utilise Test Techniques to improve the quality of testing". Im not sugesting these are the ideal goals but they are examples of what you do see in a test policy.

The purpose of the Test Strategy is to provide a organisation wide approach to testing which is commonly applies to all projects, while seeking to address the goals set out in the Organisational Test Policy.

So in other words the Test Strategy is a generic framework document which describes and mandates orgaisation wide the test processes which must be adhered to. The Test Strategy is NOT project specific. The Test Approach or Test Plans are project specific and describes how the processes mandated in the Strategy are to be applied to the project. The Test strategy will often contain an exception process to enable the project to apply for a dispensation or exception to a process if they feel its necessary, for example it might be that a project is too small and the risk too low to justify Performance testing. The justification is made and exception managed and authorised.

There is so much confusion in the industry over the structure of these documents and its very common to see things like: The purpose of system testing, roles and responsiblities and defect mansgement process etc duplicated throughout Strategies/Approaches/Master test Plans and detailed test plans. If your origanisation cleary understands the the purpose of each of these documents then it will realise if it has been said once(i.e. the strategy)so it doesnt need to be said again. I often see people writting Test Stratgies and approaches over and over again explainning the test process and its purpose....you shoudl never have to do this


Posted by Mike on February 10, 2010 at 09:20 PM IST #

Post a Comment:
  • HTML Syntax: NOT allowed

John Morrison


« July 2016