|
In a software company you will be faced with challenging cases of testing a ERP, website or a web based application, database testing, data warehouse, Android applications, testing on the cloud, embedded software like for example software used in cars and planes each will follow a approach and a strategy which is unique in its own form. The basis of all test plans is the IEEE Standard 829 which gives us the outline on testing a application. The IEEE 829 Outline is as given below:
Test plan Identifier
It has to be kept in that test plans are dynamic in nature and and we need to keep a revision history.
References
List all the documents that support the test plan which include
ü Project plan
ü Requirements specifications
ü High level design document
ü Details design Document
ü Development and test process standards
ü Corporate Standards and guide lines
Introduction
In this section we have to state the purpose of the plan and identify the scope of the plan in relation to the software project plan.
Test items
These are things you intend to test within the scope of the test plan.
Software risk issues
ü New versions of interfacing software
ü Extremely complex functions
ü Modifications to components with a past history of failure
ü Poorly documented modules or change requests
ü Multiple interfaces
ü Impacts on clients
ü Government regulations and rules
Features to be tested
This is a listing of what is to be tested from the users view point
Features not to be tested
This is a listing of features which are not to be tested from the users view point.
Approach
In this section we give the overall test strategy for the plan which includes the following points
ü Are any special tools to be used and what are they
ü Will the tool require special training
ü What metrics will be collected.
ü Which level is each metric to be collected at
ü How is configuration management handled
ü What levels of regression testing would be done and how much at each test level
Item pass/fail Criteria
What are the completion criteria or this plan that is in this section whe have to describe the completion criteria of all the test cases.
Test deliverables
In this section we have to describe what are to be delivered as a part of this plan
ü Test Plan Document
ü Test Cases
ü Test Design specifications
ü Tools and their outputs
ü Error logs and execution logs
Staffing and Training needs
In this section we plot the resources required for testing the application and also if necessary training has to be given to the staff on the respective automation tool to be used in the project.
Responsibilities
In this section it basically gives importance on who is in charge
This issue include
ü Selecting features to be tested and not tested
ü Who will provide the required training
Schedule
Schedule should be based on realistic and validated estimates if the estimates are incorrect the entire project plan will slip as testing is part of the overall project plan.
Planning risks and Contingencies
In this section we discuss the overall risk to the project with a emphasis on testing
ü Lack of personnel resources when testing is to be done
ü Late delivery of software
ü Delays in training on the application or tools
ü Changes to the original requirements or designs
Approvals
Approvals of the test plan are ideally done by the stakeholder.
The above given points are the outline of the IEEE 829 standard used in software testing which is the universal standard used by the testing community to write test plans.
Automation Approach
In Automation approach we have to understand the product , identify automation opportunities, tool selection, Proof of concept (To find out whether the tool can design a framework based on the complexity of the application which has workflows and try to automate some scenarios to see whether the tool is giving the result correctly), Finalize automation scope.
Difference between Test plan and Test strategy
When writing the test strategy document we must keep in mind that you have little information available for the project as this is the initiation phase. You only have high level information about the requirements that is why the test strategy document is written by a senior test manager who has worked in a similar kind of project. Whereas a Test plan is written at a later stage of the project typically when the user cases are ready and design and requirement documents are almost frozen. The plan describes the tasks , resources and schedule to implement the strategy. Test Plan can be of different types for example for functional testing we write a functional test plan and for performance testing we write a performance test plan. For Automation testing we write a different test plan and so also for embedded systems testing.
About the Author
The Author is a Subject matter expert on ERP and has also worked in various capacities as Test Manager , Project Manager, Implementation Manager and ERP consultant and can be contacted at sureshmenonr1009@gmail.com.
