{"id":880,"date":"2023-09-09T08:17:52","date_gmt":"2023-09-09T08:17:52","guid":{"rendered":"https:\/\/www.softwaretestingstuff.com\/?p=880"},"modified":"2023-09-10T10:37:59","modified_gmt":"2023-09-10T10:37:59","slug":"testing-bible-software-test-plan","status":"publish","type":"post","link":"https:\/\/www.softwaretestingstuff.com\/2008\/11\/testing-bible-software-test-plan.html","title":{"rendered":"Testing Bible – Software Test Plan"},"content":{"rendered":"\n

A test plan is a document describing the approach to be taken for intended testing activities and serves as a service level agreement between the quality assurance testing function and other interested parties, such as development. A test plan should be developed early in the development cycle and help improve the interactions of the analysis, design, and coding activities. A test plan defines the test objectives, scope, strategy and approach, test procedures, test environment, test completion criteria, test cases, items to be tested, the tests to be performed, the test schedules, personnel requirements, reporting procedures, assumptions, risks, and contingency planning.<\/p>\n\n\n\n

<\/a>
While developing a test plan, one should be sure that it is simple, complete, current, and accessible by the appropriate individuals for feedback and approval. A good test plan flows logically and minimizes redundant testing, demonstrates full functional coverage, provides workable procedures for monitoring, tracking, and reporting test status, contains a clear definition of the roles and responsibilities of the parties involved, target delivery dates, and clearly documents the test results.<\/p>\n\n\n\n

There are two ways of building a test plan. The first approach is a master test plan which provides an overview of each detailed test plan, i.e., a test plan of a test plan. A detailed test plan verifies a particular phase in the waterfall development life cycle. Test plan examples include unit, integration, system, acceptance. Other detailed test plans include application enhancements, regression testing, and package installation. Unit test plans are code orientated and very detailed but short because of their limited scope. System or acceptance test plans focus on the functional test or black-box view of the entire system, not just a software unit.<\/p>\n\n\n\n

The second approach is one test plan. This approach includes all the test types in one test plan, often called the acceptance\/system test plan, but covers unit, integration, system, and acceptance testing and all the planning considerations to complete the tests.<\/p>\n\n\n\n

A major component of a test plan, often in the Test Procedure section, is a test case. A test case defines the step-by-step process whereby a test is executed. It includes the objectives and conditions of the test, the steps needed to set up the test, the data inputs, the expected results, and the actual results. Other information such as the software, environment, version, test ID, screen, and test type are also provided.<\/p>\n\n\n\n

Major steps to develop a test plan<\/strong><\/h2>\n\n\n\n

A test plan is the basis for accomplishing testing and should be considered a living document, i.e., as the application changes, the test plan should change.<\/p>\n\n\n\n

A good test plan encourages the attitude of \u201cquality before design and coding.\u201d It is able to demonstrate that it contains full functional coverage, and the test cases trace back to the functions being tested. It also contains workable mechanisms for monitoring and tracking discovered defects and report status.<\/p>\n\n\n\n

The following are the major steps that need to be completed to build a good test plan:<\/p>\n\n\n\n