Testing Planning & Strategy – The Do’s and The Don'ts

Neatly document the test plan and test strategy for the application under test. Test Plan serves as the basis for all testing activities throughout the testing life cycle. Being an umbrella activity this should reflect the customers needs in terms of milestones to be met, the test approach (test strategy), resources required etc. The plan and strategy should give a clear visibility of the testing process to the customer at any point of time.

Functional and Performance test plans if developed separately will give lot more lucidity for functional and performance testing. Performance test plan is optional if the application does not entail any performance requirements.

Below are some useful Do’s and Don'ts:

The Do’s:

* Develop test plan based on a approved Project Plan
* Document test plan with major testing milestones
* Identify and document all deliverables at the end of these milestones
* Identify the resources (Both Hardware/Software and Human) required
* Identify all other external systems, which is going to interact with the application. For example the application can get the data from any other mainframe server. Identification of such systems will help one plan for integration testing as well
* If performance testing is under the scope of testing then clearly identify the application performance requirements like number of hits/second, response time, number of concurrent user etc. Details about different testing methodologies (Spike testing, Endurance testing, stress testing, capacity testing) during the performance testing phase can also be documented.
* Get the test plan approved.
* Include Features to be tested to communicate to customer what all will be tested during the testing life cycle
* Include Features not tested to communicate to customer what all will not be tested during the testing life cycle. (As part of risk management)

The Don'ts:

* Do not use draft (unapproved) test plans for reference
* Do not ignore the test strategies identified in the test plan during testing.
* Do not make changes to any approved test plan without official change request
* Do not mix the stages of testing (Unit testing, Integration testing, System testing, Functional testing etc) with the types of testing (Regression testing, Sanity testing, User Interface testing, Smoke testing etc) in the test plan. Identify them uniquely with their respective input and exit criteria.