Thread: Contents and general idea of a project plan

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. A test plan states what the items to be tested are, at what level they will be tested, what sequence they are to be tested in, how the test strategy will be applied to the testing of each item, and describes the test environment. A test plan should ideally be organisation wide, being applicable to all of an organisations software developments. The objective of each test plan is to provide a plan for verification, by testing the software, the software produced fulfils the functional or design statements of the appropriate software specification. In the case of acceptance testing and system testing, this generally means the functional specification. The first consideration when preparing the test plan is who the intended audience is – i.e. The audience for a unit test plan would be different, and thus the content would have to be adjusted accordingly. You should begin the test plan as soon as possible. Generally it is desirable to begin the master test plan as the same time the requirements documents and the project plan are being developed. Test planning can (and should) have an impact on the project plan. Even though plans that are written early will have to be changed during the course of the development and testing, but that is important, because it records the progress of the testing and helps planners become more proficient. What to consider for the test plan:
1. Test plan identifier
2. References
3. Introduction
4. Test items
5. Software risk issues
6. Features to be tested
7. Features not to be tested
8. Approach
9. Item pass/fail criteria
10. Suspension criteria and resumption requirements
11. Test deliverables
12. Remaining test tasks
13. Environmental needs
14. Staffing and training needs
15. Responsibilities
16. Schedule
17. Planning risks and contingencies
18. Approvals
19. Glossary

The software development project plan describes the plan for working on a software development project. It includes information on deliverables, schedules, and responsibilities.



Typical sections of the Software Development Project Plan are:


A. Introduction the introduction describes the purpose of the software development project plan, and outlines structure and contents of the document that follows.


B. Software project description explains what the project is, why it is being done, and who the intended users are. It summarizes and updates the principal business needs, functional requirements, software attributes, and user interface requirements that were originally documented in the software requirements document.


C. Deliverables this section lists and briefly describes all project deliverables. The development contract is referenced here.


D. Project assumptions and potential risks assumptions: describes important assumptions that exist at the time of starting the project. Potential risks: lists and describes the top risks to the project, along with plans for mitigating each risk.


E. Project organization performing organizations and their responsibilities. Technical management and control. Describes the management approach that will be used to guide the project and ensure that cost, delivery, and schedule are met.


F. Delivery, installation, and acceptance describes how the software product and associated deliverables will be accepted by specific end-users, and how the software will be placed into full operation. For example, describes any customization, installation assistance, or training required or recommended after acceptance testing and distribution.


G. Schedule tasks: schedule of tasks for developing each deliverable item.


H. Quality plan software development organizations should have well-defined and documented procedures in this area that can be referenced.


Change control: describes how changes to the project scope are controlled, and who approves these.

Configuration management: describes how multiple development builds of the software are tracked to avoid confusion.

Release control: describes pass/fail criteria for releasing software. Includes a description of how the developer ensures that the software works properly (verification), and that the product meets the requirements (validation).

Testing description: describes how the developer plans for and executes testing, both incrementally during development and for the entire product before delivery. Test objectives and responsibilities are given for all testing levels, such as testing of modules, unit testing, and integration testing. Also included are the scope and guiding principles for the testing effort, and the policy for resolving conflicts that arise during the testing process.

Defect tracking: describes how the developer tracks and resolves software defects.

I. Test plan description: if the developer's approach to testing is already documented in the quality plan, that description is referenced here.

Testing approach: a general overview of the plan for testing the entire system is given here. Included are how each major group of software features will be tested, major testing activities, techniques, and testing tools to be used.

Testing tasks to be performed: this list enables management to make decisions on the resources and time needed for testing. Examples here are test equipment procurement and setup, unit tests, test script creation, integration testing. Also includes the responsible individuals or organizations.

Testing schedule: includes tasks and major milestones. Milestone examples are start and end of module or system tests, system builds, test script creation, and regression testing. These dates are integrated into the master project schedule.

J. Documentation plan planned documentation: list and description of items such as user manual (including installation instructions and solved example problems), on-line help, programmer's manual, administrator's manual, specifications, and design documents. For each document, the plan provides an outline or table of contents with enough detail to support an accurate estimate of the effort required to produce it.

Documentation schedule: milestones for developing and testing the documentation, including the names of people and resources to be used. These are integrated into the master project schedule.

K. Beta testing approach description: this section presents the approach that will be used for beta testing, including an estimate of the number of beta testers, participating organizations, main aspects of the software that will be tested, and the pass/fail criteria to be used. An in-depth beta test implementation plan is prepared during the implementation step. The primary goal of beta testing is to have intended users exercise the software in their actual environments, utilizing their real data. Instructions for beta testers describing the functions and features to be tested are part of the beta tester package developed just prior to beta testing. Schedule for beta testing with major milestones. These dates are integrated into the master project schedule.

L. Technical reviews, audits, and walk-throughs schedule for all review meetings: the review schedule is integrated into the master project schedule.

Description of reviews: includes how and when the developer conducts design reviews, code reviews, walk throughs, reviews of test scripts, reviews of test results. For example, is 100% of all code checked, or only the most complex parts? pass/fail criteria: definitions, methods, and criteria used to determine whether the software has passed each review.

M. Standards, procedures, and processes used in this project for software with commercial potential, this section is important. For other software, it may be omitted. This section includes documentation procedures, software coding standards or practices to be used, reports, and review standards.

N. Technical information where relevant, describes the software-related tools, methods, and techniques to be used for the project. Examples here include the development environment, programming language, database technology, or internet technology to be used.