Topic: What to include in the Testing Strategy

Message

   What to include in the Testing Strategy

During
the analysis phase, you gather and validate the business requirements
for the solution. It makes sense that the Testing Strategy is completed
during this phase as well. In a sense, you are defining the overall
testing requirements.

The purpose of the Testing Strategy is to
define the overall context for the entire testing process. The process
is different depending on the specific characteristics of your
solution. In many respects, this is the most important part of the
testing process, since all future testing decisions will be made within
the context of the strategy. Here are the basic parts of the testing
strategy:

•Project Overview: You can copy this from the Project Definition. 

•Business Risks: These
are high-level risks of the project that will affect the overall
testing strategy. For instance, the risk of doing business on the
Internet may drive the need for rigorous system tests of firewalls,
technical architecture, and security. The risks can be classified as
high, medium, and low, depending on the nature and impact of the
problem. For each high and medium risk, identify what elements in the
overall testing approach will help ensure that the potential problem
does not occur.

•Testing Milestones:
This section gives the reader a preliminary overview of the testing
timelines. Obviously, since this document is created in the analysis
phase, these dates are subject to later revision.

•Testing Approach:
This describes the testing process at a high level, including how you
will conduct unit testing, integration testing, system testing, and
acceptance testing. (If your project is large enough, each of these
might be its own section.) This is where you make fundamental decisions
regarding the type of testing that makes sense for your project. For
instance, if you are implementing a packaged solution, the approach may
start in system testing, with the vendor providing close support. If
you are doing iterative development cycles, the testing approach will
reflect this overall development life cycle. For system testing, define
the major testing events, such as stress testing, security testing,
disaster recovery testing, usability testing, and response time testing.

•Testing Environment:
Think through the technologies and facilities needed for the testing
process. If the overall testing environment needs are understood up
front, it will be easier to break out the specific activities required
to put the environment in place. In addition, you may need to plan for
and acquire some parts of the environment well in advance.

Depending
on your project, there may be other high-level sections to include,
such as testing objectives, testing assumptions, testing organization,
and testing tools, along with effort and cost estimates.

Author	Message
tanushree Senior Member Joined: 04Apr2007 Online Status: Offline Posts: 2160	Topic: What to include in the Testing Strategy Posted: 15Oct2007 at 4:06am
	What to include in the Testing Strategy During the analysis phase, you gather and validate the business requirements for the solution. It makes sense that the Testing Strategy is completed during this phase as well. In a sense, you are defining the overall testing requirements. The purpose of the Testing Strategy is to define the overall context for the entire testing process. The process is different depending on the specific characteristics of your solution. In many respects, this is the most important part of the testing process, since all future testing decisions will be made within the context of the strategy. Here are the basic parts of the testing strategy: •Project Overview: You can copy this from the Project Definition. •Business Risks: These are high-level risks of the project that will affect the overall testing strategy. For instance, the risk of doing business on the Internet may drive the need for rigorous system tests of firewalls, technical architecture, and security. The risks can be classified as high, medium, and low, depending on the nature and impact of the problem. For each high and medium risk, identify what elements in the overall testing approach will help ensure that the potential problem does not occur. •Testing Milestones: This section gives the reader a preliminary overview of the testing timelines. Obviously, since this document is created in the analysis phase, these dates are subject to later revision. •Testing Approach: This describes the testing process at a high level, including how you will conduct unit testing, integration testing, system testing, and acceptance testing. (If your project is large enough, each of these might be its own section.) This is where you make fundamental decisions regarding the type of testing that makes sense for your project. For instance, if you are implementing a packaged solution, the approach may start in system testing, with the vendor providing close support. If you are doing iterative development cycles, the testing approach will reflect this overall development life cycle. For system testing, define the major testing events, such as stress testing, security testing, disaster recovery testing, usability testing, and response time testing. •Testing Environment: Think through the technologies and facilities needed for the testing process. If the overall testing environment needs are understood up front, it will be easier to break out the specific activities required to put the environment in place. In addition, you may need to plan for and acquire some parts of the environment well in advance. Depending on your project, there may be other high-level sections to include, such as testing objectives, testing assumptions, testing organization, and testing tools, along with effort and cost estimates. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Software Testing @ OneStopTesting : Test Plans @ OneStopTesting