What is that supposed to be ? Test Policy, Test Plan and now Test Strategy ? Why all these terms ? Why not just pick up the build and try to find as many bugs as we possibly can within the time we've been allotted ? These are questions that you'll hear if you talk to enough folks in the industry. Testing, they say - is a simple task that anyone can do with little need for process or practice. Sure, as long as i'm not your customer. With that interesting insight, lets get back to taking a quick look at our topic for today – Test Strategy!
The test strategy addresses the “how” of testing in an organization at a high level and is not specific to a particular project or product. It covers the methods of testing, the risks – quality and project risks, relation of risks to test goals, risk management, types of testing across different phases, common entry and exit criteria for the different test types, state at a high level the activities performed in each type of testing, aligns with the test policy, common test requirements (such as what to look for while testing – dependent on the test approach chosen) for each type of testing, discuss testing types and groups responsible for each type, the general approach to testing, any standards to be followed (mandatory vs recommended), automation types, test environment for each test type, methods for test control and reporting, metrics and measurement details and frequency of reporting these, defect tracking and management mechanisms, test configuration management process, cross-functional interactions and sharing of deliverables across functional groups (such as Testing and Development), etc. 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.
When working with products that fit in to a suite and share common characteristics or projects of a similar nature, such a strategy document helps reduce the need for project specific documentation. Although, the Test Strategy is supposed to be generic and spans across projects, it can be further tailored to meet special requirements of individual projects / products.
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 mismatch.
Quoting from published material on the subject, here are some of the types of Test Strategy – analytical strategies, model based strategies, methodical strategies, process or standards compliant strategies, dynamic or heuristic strategies, consultative strategies and regression test strategies – in real world use, rather than stick to any one type of strategy, strategies are generally combined to suit the requirements of the organization.
An obvious attribute of a Test strategy is that its not etched in stone, meaning it can and most likely will undergo changes. 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.
The test strategy addresses the “how” of testing in an organization at a high level and is not specific to a particular project or product. It covers the methods of testing, the risks – quality and project risks, relation of risks to test goals, risk management, types of testing across different phases, common entry and exit criteria for the different test types, state at a high level the activities performed in each type of testing, aligns with the test policy, common test requirements (such as what to look for while testing – dependent on the test approach chosen) for each type of testing, discuss testing types and groups responsible for each type, the general approach to testing, any standards to be followed (mandatory vs recommended), automation types, test environment for each test type, methods for test control and reporting, metrics and measurement details and frequency of reporting these, defect tracking and management mechanisms, test configuration management process, cross-functional interactions and sharing of deliverables across functional groups (such as Testing and Development), etc. 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.
When working with products that fit in to a suite and share common characteristics or projects of a similar nature, such a strategy document helps reduce the need for project specific documentation. Although, the Test Strategy is supposed to be generic and spans across projects, it can be further tailored to meet special requirements of individual projects / products.
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 mismatch.
Quoting from published material on the subject, here are some of the types of Test Strategy – analytical strategies, model based strategies, methodical strategies, process or standards compliant strategies, dynamic or heuristic strategies, consultative strategies and regression test strategies – in real world use, rather than stick to any one type of strategy, strategies are generally combined to suit the requirements of the organization.
An obvious attribute of a Test strategy is that its not etched in stone, meaning it can and most likely will undergo changes. 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.
