Test Plan Preparation
Printed From: One Stop Testing
Category: Types Of Software Testing @ OneStopTesting
Forum Name: Functional Testing @ OneStopTesting
Forum Discription: Discuss All that is need to be known about Functional Software Testing and its Tools.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=833
Printed Date: 09Jan2025 at 2:45am
Topic: Test Plan Preparation
Posted By: sapna
Subject: Test Plan Preparation
Date Posted: 23Apr2007 at 11:23pm
What materials are used in preparation of the test plan?
I
know that the requirements are one such document. Which documents does
the test plan preparer derive the specifications from? For example,
where the preparer finds how many times to click on a link, where the
preparer finds the number of characters that are allowed in a given
text box, or which alpha-numeric characters are allowed in a given text
box?
If the test plan preparer only has the requirements, is this enough to prepare a test plan?
|
Replies:
Posted By: Abhijit
Date Posted: 24Apr2007 at 4:13am
Test Plan
The
test strategy identifies multiple test levels, which are going to be
performed for the project. Activities at each level must be planned
well in advance and it has to be formally documented. Based on the
individual plans only, the individual test levels are carried out.
Entry
means the entry point to that phase. For example, for unit testing, the
coding must be complete and then only one can start unit testing. Task
is the activity that is performed. Validation is the way in which the
progress and correctness and compliance are verified for that phase.
Exit tells the completion criteria of that phase, after the validation
is done. For example, the exit criterion for unit testing is all unit
test cases must pass.
Unit Test Plan {UTP}
The unit test plan
is the overall plan to carry out the unit test activities. The lead
tester prepares it and it will be distributed to the individual
testers, which contains the following sections.
What is to be tested?
The
unit test plan must clearly specify the scope of unit testing. In this,
normally the basic input/output of the units along with their basic
functionality will be tested. In this case mostly the input units will
be tested for the format, alignment, accuracy and the totals. The UTP
will clearly give the rules of what data types are present in the
system, their format and their boundary conditions. This list may not
be exhaustive; but it is better to have a complete list of these
details.
Sequence of Testing
The sequences of test activities
that are to be carried out in this phase are to be listed in this
section. This includes, whether to execute positive test cases first or
negative test cases first, to execute test cases based on the priority,
to execute test cases based on test groups etc. Positive test cases
prove that the system performs what is supposed to do; negative test
cases prove that the system does not perform what is not supposed to
do. Testing the screens, files, database etc., are to be given in
proper sequence.
Basic Functionality of Units
How the
independent functionalities of the units are tested which excludes any
communication between the unit and other units. The interface part is
out of scope of this test level. Apart from the above sections, the
following sections are addressed, very specific to unit testing.
* Unit Testing Tools
* Priority of Program units
* Naming convention for test cases
* Status reporting mechanism
* Regression test approach
* ETVX criteria
Integration Test Plan
The
integration test plan is the overall plan for carrying out the
activities in the integration test level, which contains the following
sections.
What is to be tested?
This section clearly
specifies the kinds of interfaces fall under the scope of testing
internal, external interfaces, with request and response is to be
explained. This need not go deep in terms of technical details but the
general approach how the interfaces are triggered is explained.
Sequence of Integration
When
there are multiple modules present in an application, the sequence in
which they are to be integrated will be specified in this section. In
this, the dependencies between the modules play a vital role. If a unit
B has to be executed, it may need the data that is fed by unit A and
unit X. In this case, the units A and X have to be integrated and then
using that data, the unit B has to be tested. This has to be stated to
the whole set of units in the program. Given this correctly, the
testing activities will lead to the product, slowly building the
product, unit by unit and then integrating them.
System Test Plan {STP}
The
system test plan is the overall plan carrying out the system test level
activities. In the system test, apart from testing the functional
aspects of the system, there are some special testing activities
carried out, such as stress testing etc. The following are the sections
normally present in system test plan.
What is to be tested?
This
section defines the scope of system testing, very specific to the
project. Normally, the system testing is based on the requirements. All
requirements are to be verified in the scope of system testing. This
covers the functionality of the product. Apart from this what special
testing is performed are also stated here.
Functional Groups and the Sequence
The
requirements can be grouped in terms of the functionality. Based on
this, there may be priorities also among the functional groups. For
example, in a banking application, anything related to customer
accounts can be grouped into one area, anything related to inter-branch
transactions may be grouped into one area etc. Same way for the product
being tested, these areas are to be mentioned here and the suggested
sequences of testing of these areas, based on the priorities are to be
described.
Acceptance Test Plan {ATP}
The client at their
place performs the acceptance testing. It will be very similar to the
system test performed by the Software Development Unit. Since the
client is the one who decides the format and testing methods as part of
acceptance testing, there is no specific clue on the way they will
carry out the testing. But it will not differ much from the system
testing. Assume that all the rules, which are applicable to system
test, can be implemented to acceptance testing also.
Since this
is just one level of testing done by the client for the overall
product, it may include test cases including the unit and integration
test level details.
A sample Test Plan Outline along with their description is as shown below:
Test Plan Outline
1. BACKGROUND – This item summarizes the functions of the application system and the tests to be performed.
2. INTRODUCTION
3. ASSUMPTIONS – Indicates any anticipated assumptions which will be made while testing the application.
4. TEST ITEMS - List each of the items (programs) to be tested.
5.
FEATURES TO BE TESTED - List each of the features (functions or
requirements) which will be tested or demonstrated by the test.
6.
FEATURES NOT TO BE TESTED - Explicitly lists each feature, function, or
requirement which won't be tested and why not. 7. APPROACH - Describe
the data flows and test philosophy.
Simulation or Live execution,
Etc. This section also mentions all the approaches which will be
followed at the various stages of the test execution.
8. ITEM PASS/FAIL CRITERIA Blanket statement - Itemized list of expected output and tolerances
9. SUSPENSION/RESUMPTION CRITERIA - Must the test run from start to completion?
Under what circumstances it may be resumed in the middle?
Establish check-points in long tests.
10. TEST DELIVERABLES - What, besides software, will be delivered?
Test report
Test software
11. TESTING TASKS Functional tasks (e.g., equipment set up)
Administrative tasks
12. ENVIRONMENTAL NEEDS
Security clearance
Office space & equipment
Hardware/software requirements
13. RESPONSIBILITIES
Who does the tasks in Section 10?
What does the user do?
14. STAFFING & TRAINING
15. SCHEDULE
16. RESOURCES
17. RISKS & CONTINGENCIES
18. APPROVALS
The
schedule details of the various test pass such as Unit tests,
Integration tests, System Tests should be clearly mentioned along with
the estimated efforts.
|
|