We need plan Identifier for,
Revision numbers are also used as plan identifier.
Example: RS-MTP01.3
Plans for major types of testing like Functional Test Plan, Performance Test Plan and Security Test Plan.
All risks associated with the software and its testing need to be identified in this section.
Why: Plan for risks and contingencies
Test planners should be aware of:
Example: Backup and Recovery of the EDI transmission files, local databases and restart of the translation process, must be carefully checked.
Below mentioned are some of the objectives behind running the test cases.
A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document.
Plans for each level of testing like
Example: Access to a nightly backup/recovery system.
The test ware is:
Test ware is special because it has:
This section identifies the strategy for this test plan, differing depending on the level of test plan (Unit, Integration, Acceptance).
A Test Plan is 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 and who will do each task (roles and responsibilities) and any risks and its solutions.
Components of the test plan document include:
This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to-company.
Identifying the test items is a section that basically specifies the things that are to be tested within the scope of this test plan:
The Test Plan should ensure correct names and versions as listed.
Software and hardware needed for testing will also be listed here, along with other test materials and participating organizations.
Example: EXTOL EDI package, Version 3.0
The test strategy includes introduction, resource, scope and schedule for test activities, test tools, test priorities, test planning and the types of test that has to be performed.
The different test plan types are
A single high-level test plan for a project/product that unifies all other test plans.
Example: Staff will require training on new equipment.
Test Plan covers – What needs to be tested, how testing is going to be performed? Resources needed for testing, Timelines and Risk associated.
For efficient and effective test planning we don’t really need IEEE-829 template for test plan. Planning can be done without test plan document also. Identify your test Approach (strategy) and go with your testing. Many test plans are being created just for the sake of processes.
Note – We are not against Test Plan documents. Use test plan documents if they really contains some useful information.
A test plan document will commence with a unique test plan identifier
This section is used to specify what is to be delivered as part of this test plan
The Level of Test Plan defines what the test plan is being created for e.g. subsections of testing:
A test describes the input to a test. This can include the data, the screen that will be used and the parameters that may drive the test. It will describe the steps necessary to execute the test case. It will describe the output and the results that are to be expected. It may include manipulation of the input data to test the particular case. A Test Case Walkthrough is a review of the test case by Testing Peers. It can highlight steps that may have been missed or test cases that may have been missed.
A test case is a documentation which specifies input values, expected output and the preconditions for executing the test.
IEEE Standard 610 (1990) defines test case as follows:
A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.