In this article, we are going to look at creating software system test plans that really make a difference, in an easy, step-by-step way. We will cover the three main aspects you need to consider as part of software test planning, also a 12 point checklist that should be addressed in all software test plans.
1. What Kind of information we should put in the software test plan.
2. Where we can find the right information for your software test plan.
3. How to get people to act based on your software test plan
What information should I include in the test plan?
Key 1 describe a clear objective:
The main aim of writing a test plan is so you and your team can achieve a specific objective (or goals). The aim is clearly to convey the information necessary to get all of your teams bringing in the same direction to achieve that goal quickly and efficiently. Whenever you cannot identify your goals clearly, or if you’re not clear on your goals in the first place, then you should not waste your time writing a test plan yet. Once you’ve outlined your goals, then tell them clearly at the start of the test plan document.
Key 2 Follow the IEEE Test Plan Recommended format:
The IEEE Standard 829 is a standard that specifies a set of Software Test Documentation. The IEEE 829 standard designs to depict a set of basic software test documents that can be used to convey a test approach. Within that you will find a standard template that provides a suggested list of items your test plan should include. You will find a lot of valuable
articles on the Internet that cover the details of an IEEE 829 test plan, but two of the most valuable are:
1) http://en.wikipedia.org/wiki/IEEE_829
2) http://online.gerrardconsulting.com/iseb/otherdocs/ieee829mtp.pdf
Briefly, the items that should be covered in an IEEE 829 compliant test plan are as follows:
1. TEST PLAN IDENTIFIER This is some kind of unique, company-generated number that will identify your test plan, its level, and the version of
software that it is related to.
2. REFERENCES List all documents that support your test plan. Documents that can be referenced to include: the Project Plan, Requirements
Specifications, High Level Design Document, etc...
3. INTRODUCTION State the purpose of the plan, and possibly identify the level of the plan (master, system, etc...).
4. TEST ITEMS (Functions) These are the things you intend to test within the scope of your test plan.
5. SOFTWARE RISK ISSUES Identify what software is to be tested and what critical areas might present some inherent software risks. One example is the
complexity of a particular module in the application under test.
6. FEATURES TO BE TESTED This is a listing of what is to be tested from the user point of view.
7. FEATURES NOT TO BE TESTED This is a listing of what is NOT to be tested from both the User viewpoint and a configuration management / version control
view.
8. Approach (STRATEGY) This is your overall testing strategy for the test plan, and should detail the rules and processes that will be followed
(e.g. What kind of testing metrics would be collected?).
9. ITEM PASS / FAIL CRITERIA What are the completion/exit criteria for this plan/system testing? This can be based on the number of test cases completed, the functional/non functional test coverage provided and / or the level of open bugs identified in the application.
10. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS It should be stated clearly “that, in certain scenarios, testing will be suspended. You must list down what criteria must be met for the testing to resume.
11. TEST DELIVERABLES What is to be delivered as part of this plan? This consists of the test plan document, test cases, test design specifications, etc...
12. TEST TASKS This section may contain descriptions of test. Those tasks that need to be completed by internal and external groups.
13. ENVIRONMENTAL NEEDS Are there any special requirements for this test plan, such as special hardware or static generators?
14. STAFFING AND TRAINING NEEDS How much time is required to complete the test effort, and what kind of training on the application / system is required?
15. RESPONSIBILITIES Who is in responsible for completing each section of this test project?
16. SCHEDULE This will consist of a detailed list of resources who will work on this project and the total testing effort needed. 17. PLANNING AND RISKS Contingencies What are the overall risks to the project? Put an emphasis on the testing processed here.
18. APPROVALS Who can, and will, approve the process as complete and allow the project to proceed to the next level?
19. GLOSSARY The Glossary is used to define terms and acronyms used in the document, and testing in general, To eliminate confusion and Promote more consistent communications.
Key 3 What a test plan is not:
A significant number of people in software development, product development, testing and the arena itself seem to think that a test plan is a series of test scripts or test cases.
So, let’s start by saying categorically that a test plan is NOT a collection of tests scripts or test cases.
Generally, a test plan is a written document utilized to describe the course of action to help Achieve a testing goal. A test plan is unquestionably NOT just a list of test cases/scripts. This confusion is one reason why the IEEE defined the IEEE 829 standard.
1. What Kind of information we should put in the software test plan.
2. Where we can find the right information for your software test plan.
3. How to get people to act based on your software test plan
What information should I include in the test plan?
Key 1 describe a clear objective:
The main aim of writing a test plan is so you and your team can achieve a specific objective (or goals). The aim is clearly to convey the information necessary to get all of your teams bringing in the same direction to achieve that goal quickly and efficiently. Whenever you cannot identify your goals clearly, or if you’re not clear on your goals in the first place, then you should not waste your time writing a test plan yet. Once you’ve outlined your goals, then tell them clearly at the start of the test plan document.
Key 2 Follow the IEEE Test Plan Recommended format:
The IEEE Standard 829 is a standard that specifies a set of Software Test Documentation. The IEEE 829 standard designs to depict a set of basic software test documents that can be used to convey a test approach. Within that you will find a standard template that provides a suggested list of items your test plan should include. You will find a lot of valuable
articles on the Internet that cover the details of an IEEE 829 test plan, but two of the most valuable are:
1) http://en.wikipedia.org/wiki/IEEE_829
2) http://online.gerrardconsulting.com/iseb/otherdocs/ieee829mtp.pdf
Briefly, the items that should be covered in an IEEE 829 compliant test plan are as follows:
1. TEST PLAN IDENTIFIER This is some kind of unique, company-generated number that will identify your test plan, its level, and the version of
software that it is related to.
2. REFERENCES List all documents that support your test plan. Documents that can be referenced to include: the Project Plan, Requirements
Specifications, High Level Design Document, etc...
3. INTRODUCTION State the purpose of the plan, and possibly identify the level of the plan (master, system, etc...).
4. TEST ITEMS (Functions) These are the things you intend to test within the scope of your test plan.
5. SOFTWARE RISK ISSUES Identify what software is to be tested and what critical areas might present some inherent software risks. One example is the
complexity of a particular module in the application under test.
6. FEATURES TO BE TESTED This is a listing of what is to be tested from the user point of view.
7. FEATURES NOT TO BE TESTED This is a listing of what is NOT to be tested from both the User viewpoint and a configuration management / version control
view.
8. Approach (STRATEGY) This is your overall testing strategy for the test plan, and should detail the rules and processes that will be followed
(e.g. What kind of testing metrics would be collected?).
9. ITEM PASS / FAIL CRITERIA What are the completion/exit criteria for this plan/system testing? This can be based on the number of test cases completed, the functional/non functional test coverage provided and / or the level of open bugs identified in the application.
10. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS It should be stated clearly “that, in certain scenarios, testing will be suspended. You must list down what criteria must be met for the testing to resume.
11. TEST DELIVERABLES What is to be delivered as part of this plan? This consists of the test plan document, test cases, test design specifications, etc...
12. TEST TASKS This section may contain descriptions of test. Those tasks that need to be completed by internal and external groups.
13. ENVIRONMENTAL NEEDS Are there any special requirements for this test plan, such as special hardware or static generators?
14. STAFFING AND TRAINING NEEDS How much time is required to complete the test effort, and what kind of training on the application / system is required?
15. RESPONSIBILITIES Who is in responsible for completing each section of this test project?
16. SCHEDULE This will consist of a detailed list of resources who will work on this project and the total testing effort needed. 17. PLANNING AND RISKS Contingencies What are the overall risks to the project? Put an emphasis on the testing processed here.
18. APPROVALS Who can, and will, approve the process as complete and allow the project to proceed to the next level?
19. GLOSSARY The Glossary is used to define terms and acronyms used in the document, and testing in general, To eliminate confusion and Promote more consistent communications.
Key 3 What a test plan is not:
A significant number of people in software development, product development, testing and the arena itself seem to think that a test plan is a series of test scripts or test cases.
So, let’s start by saying categorically that a test plan is NOT a collection of tests scripts or test cases.
Generally, a test plan is a written document utilized to describe the course of action to help Achieve a testing goal. A test plan is unquestionably NOT just a list of test cases/scripts. This confusion is one reason why the IEEE defined the IEEE 829 standard.
No comments:
Post a Comment