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.
The plans are to be prepared by experienced people only. In all test plans, the ETVX {Entry-Task-Validation-Exit} criteria are to be mentioned. 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.
ETVX is a modeling technique for developing worldly and atomic level models. It sands for Entry, Task, Verification and Exit. It is a task-based model where the details of each task are explicitly defined in a specification table against each phase i.e. Entry, Exit, Task, Feedback In, Feedback Out, and measures.
There are two types of cells, unit cells and implementation cells. The implementation cells are basically unit cells containing the further tasks.
For example if there is a task of size estimation, then there will be a unit cell of size estimation. Then since this task has further tasks namely, define measures, estimate size. The unit cell containing these further tasks will be referred to as the implementation cell and a separate table will be constructed for it.
A purpose is also stated and the viewer of the model may also be defined e.g. top management or customer.
18.2.1 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.
18.2.1.1 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.
18.2.1.2 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.
18.2.1.4 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
18.2.2 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.
2.2.1 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.
18.2.2.1Sequence 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.
18.2.2.2 List of Modules and Interface Functions
There may be N number of units in the application, but the units that are going to communicate with each other, alone are tested in this phase. If the units are designed in such a way that they are mutually independent, then the interfaces do not come into picture. This is almost impossible in any system, as the units have to communicate to other units, in order to get different types of functionalities executed. In this section, we need to list the units and for what purpose it talks to the others need to be mentioned. This will not go into technical aspects, but at a higher level, this has to be explained in plain English.
Apart from the above sections, the following sections are addressed, very specific to integration testing.
· Integration Testing Tools
· Priority of Program interfaces
· Naming convention for test cases
· Status reporting mechanism
· Regression test approach
· ETVX criteria
· Build/Refresh criteria {When multiple programs or objects are to be linked to arrived at single product, and one unit has some modifications, then it may need to rebuild the entire product and then load it into the integration test environment. When and how often, the product is rebuilt and refreshed is to be mentioned}.
18.2.3 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.
18.2.3.1 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.
18.2.3.2 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.
18.2.3.3 Special Testing Methods
This covers the different special tests like load/volume testing, stress testing, interoperability testing etc. These testing are to be done based on the nature of the product and it is not mandatory that every one of these special tests must be performed for every product.
Apart from the above sections, the following sections are addressed, very specific to system testing.
· System Testing Tools
· Priority of functional groups
· Naming convention for test cases
· Status reporting mechanism
· Regression test approach
· ETVX criteria
· Build/Refresh criteria
18.2.4 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
- BACKGROUND – This item summarizes the functions of the application system and the tests to be performed.
- INTRODUCTION
- ASSUMPTIONS – Indicates any anticipated assumptions which will be made while testing the application.
- TEST ITEMS - List each of the items (programs) to be tested.
- FEATURES TO BE TESTED - List each of the features (functions or requirements) which will be tested or demonstrated by the test.
- FEATURES NOT TO BE TESTED - Explicitly lists each feature, function, or requirement which won't be tested and why not.
- 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. - ITEM PASS/FAIL CRITERIA Blanket statement - Itemized list of expected output and tolerances
- 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. - TEST DELIVERABLES - What, besides software, will be delivered?
Test report
Test software - TESTING TASKS Functional tasks (e.g., equipment set up)
Administrative tasks - ENVIRONMENTAL NEEDS
Security clearance
Office space & equipment
Hardware/software requirements - RESPONSIBILITIES
Who does the tasks in Section 10?
What does the user do? - STAFFING & TRAINING
- SCHEDULE
- RESOURCES
- RISKS & CONTINGENCIES
- APPROVALS
No comments:
Post a Comment