imran

• Oct 7th, 2005

 

test plan is high level document that describes the objective, approach, scope & focus of software testing effort.

Akash Dolas

• Dec 16th, 2005

 

Contents of Test Plan

Test Plan Content:   1.        Experience Notes:          To fail to plan is to plan to fail.         A good plan today is better than a perfect plan tomorrow.-Wag the Dog, movie dialog          No plan survives the departure point; keep the plan current. 2.        Introduction: testing policies; testing standards & conventions; purpose of project tests; scope; project testing objectives; system description; references; definitions/terms; assumptions; constraints; testing documentation approach.     3.        Project Testing Communication Approach: Communication mechanisms e.g., formal and informal meetings; working sessions; processes (such as defect tracking); tools (issue and defect tracking, electronic bulletin boards, notes databases, Intranet sites); bulletin boards; email; status reports; in-progress review meetings. 4.        Testability: Is necessary and sufficient documentation available to plan testing; is the documentation available/provided written with sufficient clarity, accuracy, and detail to allow the system/product/software to be unambiguously tested. 5.        Identification of Configuration Item(s) Under Test: e.g., Hardware (e.g., Specialty/Test Equipment, Communication Server, Terminal, Applications Server, Computer, etc. - nomenclature, version, date); Software (e.g., modules, units, systems, sub-systems, CSCI, CSCs, CSUs, data structures  - name, version/revision, and date); User Operational Procedures (document name, version/revision, and date)   6.        Risks & Contingency Planning*: Identify both project-oriented testing activity risks as well an application-oriented risks.  Both types of risks may potentially affect the success of the testing. (*if not already included in project management planning documentation.) 7.        Functions/Features/Design to be Tested 8.        Functions/Features/Design Not to be Tested 9.        Traceability: all requirements/features should be traceable to at least one test procedure; conversely, are all test procedures should be traceable to at least one requirement/feature; this traceability is best documented in a traceability matrix. 10.     Test Technical Approach: project test strategy (e.g., risk reduction); testing levels; test design methods/techniques; test tools; test metrics; test automation strategy. 11.     Test Data: creation, verification, and use. 12.     Test Results Recording, Data Collection, Log, & Reports: e.g., instructions for performing tests, documenting results, reporting and resolving deviations, documentation/log of errors discovered, error corrections, re-testing, sign-off/approval provisions. 13.     Test Execution: e.g., important factors that affect test execution; test cycles; test resources 14.     General Pass/Fail Criteria 15.     Acceptance Criteria 16.     Suspension / Resumption Requirements/Criteria: e.g., corrective action taken when problems or errors are encountered may include correct documentation, re-run test, re-code, re-design, regression testing. 17.      Pre-Test Needs/Test Environment: e.g., hardware/test equipment & documentation; test support software & documentation; test data files; test tools & documentation (Test driver software may need to be developed or procured to test some applications; test design documentation should address this situation.); description of the test data design/validation; installation instructions; multiple environment migrations (e.g.,  development->  test-> live). 18.       Organizational Roles and responsibilities: e.g., groups and individuals executing test tasks, groups and individuals providing test support functions. (*If not already included in project management planning documentation.) 19.        Miscellaneous: Test Deliverables*(e.g., plans, design, cases, procedures, reports, logs); Tasks*; Schedule*; Milestones*; Staffing Needs*; Training Needs*; Pre-requisites Tasks* (e.g., completion of interfacing systems) (*if not already included in project management planning documentation.)

rajanee

 Profile Answers by rajanee 

• Jan 6th, 2006

 

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.

sunilkumarnanda

 Profile Answers by sunilkumarnanda Questions by sunilkumarnanda

• Sep 15th, 2006

 

A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. for more information Refer IEEE Std 829.

nirmmal

 Profile 

• Feb 11th, 2007

 

A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.