What is test plan in software testing?

Software testing is a planned, organized and systematic software quality assurance steps, rather than casual, loosely and messy implementation of QA activities.
As per IEEE Standard 829-1982 definition a software test plan is a document which describes the scope of the testing activities, approach, resources, schedule, test features, test tasks and any risk associated with the testing. Test planning in software testing helps the QA members, especially test manager to have a clear mission and testing methods to maintain smooth communication and progress tracking during various testing phases.

A good software test plan is not an easy thing, comprehensive consideration of various factors are needed for that. In order to make a good software QA test plan, you need to pay attention to the following aspects:

1.    Clear test objectives enhances the usefulness of the QA test plan

Any of today's commercial software contains a wealth of features. So first thing you need to consider while developing a test plan is to extract the test objectives from the requirements. Test objectives must be clear, quantifiable and measurable, not vague description of the macro. Go through the user requirements documents and technical design specifications to determine the kind of test required to achieve the desired software quality.

2.    Adhere to "5W" rules to have correct contents of test plan in software testing

"5W" rule refers to the "What (do)", "Why (Why do)", "When (when done)", "Where (where)", "How (how)." The use of "5W" rules in the creation of a software test plan, helps the test team to understand the purpose of testing (Why), a clear visibility of the scope and requirements (What), to determine the test start and end dates (When), also pointed out the testing methods and tools (How) and lastly the test documentation and software storage location (Where).

3.    Apply proper test plan review and update mechanism to meet the actual testing needs

A test plan contains many sections and the quality of the test plan may be affected by the experience of the author and his knowledge on the application. Also because of changes in the requirement may change the scope or approach in the testing. Moreover software development is a gradual process so many times the test plan created in the initial phase of the design development may not be that accurate. So it is absolutely critical that we follow a multiple level of review mechanism of test plan to check its completeness, accuracy, and feasibility. For example after creation of QA test plan submit it to the project manager, development manager, test manager and marketing manager for comments and suggestions. Based on the review feedbacks we need to make proper amendments and updates to the plan. Also if any major change request comes to the project we need to revisit the project plan and update it based on the new requirement. In this process we again need to resubmit the test plan to the right stakeholders and get them on the same page.

4.    Do not make the test plan very lengthy

Keep the test plan simple, short and focused. Do not put a details test specification in a test plan. The best way is to write a separate document for test case writing/test execution guidance for the testers. Defect management is another example which should a separate document and should be only referred in the test plan. That way you still have one single document where you can go and grab the necessary information. Atleast the test plan document will tell you what would be the correct document to get the information you needed.

In next article I will discuss each section of a test plan in details.

< Prev		Next >