Zaphod Beeblebrox
Sometimes your employer is a company with a well-documented process. Sometimes this is not the case. And if you are reading this, you are probably facing one or both of these problems (or have had a similar experience ealier) :
1. Your manager doesn't understand what process is and what it is for.
2. There is no project documentation available that you can re-use to setup or streamline your test share of whatever you are participating in.
As it is out of scope for this article to fix the whole world, and as it is unlikely that you'll be able to quickly change your manager's point of view (things like that are normally connected with person's life values and are extremely hard to adjust), I suggest we concentrate on #2 as a more realistic option.
Standards
As a first step you will need to do some googling and find something that will look like this (that's a table of contents of a test plan according to the standards):
1) Test Plan Identifier
2) References
3) Introduction
4) Test Items
5) Software Risk Issues
6) Features to be Tested
7) Features not to be Tested
8) Approach
9) Item Pass/Fail Criteria
10) Suspension Criteria and Resumption Requirements
11) Test Deliverables
12) Remaining Test Tasks
13) Environmental Needs
14) Staffing and Training Needs
15) Responsibilities
16) Schedule
17) Planning Risks and Contingencies
18) Approvals
19) Glossary
No useless paper
It is absolutely up to you to use it as is or to do some adaptation. Sometimes the latter is necessary to improve readability and make it easy to use, because (and in my opinion this is the most important part) Test Plan is never just a formal document, but something you need for your work.
In brief, the answer is IEEE 829. And you do not have to spend your salary to get access, as Internet contains enough information for you to start with. Also you do not have to follow every single word there, but rather use it as a guideline or a checklist.
Systems
Personally, I don't like working with a Test Plan as something isolated. Instead, I prefer to see it as a part of documentation that describes a project as a system. And being such a part, Test Plan has strong dependencies on other documents and decisions. So, it is best to gain access to this information in order to refer to it properly.
If project documentation is not available or doesn't exist I usually create a separate document containing most important statements. Important for the Test Plan that is, because we are not doing work for the lazy project managers. I wouldn't include these into the Test Plan, as it will certainly lead to its growing too much in size and loosing focus. I did this mistake a couple of times and now I learned my lesson. Another reason for not including these statements into the Test Plan is potential conflict and overlapping with the project documentation, if it gets created at some point.
Systems
Personally, I don't like working with a Test Plan as something isolated. Instead, I prefer to see it as a part of documentation that describes a project as a system. And being such a part, Test Plan has strong dependencies on other documents and decisions. So, it is best to gain access to this information in order to refer to it properly.
If project documentation is not available or doesn't exist I usually create a separate document containing most important statements. Important for the Test Plan that is, because we are not doing work for the lazy project managers. I wouldn't include these into the Test Plan, as it will certainly lead to its growing too much in size and loosing focus. I did this mistake a couple of times and now I learned my lesson. Another reason for not including these statements into the Test Plan is potential conflict and overlapping with the project documentation, if it gets created at some point.
Steps and parts
As a first step you will need to do some googling and find something that will look like this (that's a table of contents of a test plan according to the standards):
1) Test Plan Identifier
2) References
3) Introduction
4) Test Items
5) Software Risk Issues
6) Features to be Tested
7) Features not to be Tested
8) Approach
9) Item Pass/Fail Criteria
10) Suspension Criteria and Resumption Requirements
11) Test Deliverables
12) Remaining Test Tasks
13) Environmental Needs
14) Staffing and Training Needs
15) Responsibilities
16) Schedule
17) Planning Risks and Contingencies
18) Approvals
19) Glossary
No useless paper
It is absolutely up to you to use it as is or to do some adaptation. Sometimes the latter is necessary to improve readability and make it easy to use, because (and in my opinion this is the most important part) Test Plan is never just a formal document, but something you need for your work.
If you don't need it for your work don't waste your time on it. Personally, I believe that Test Plan is always necessary, because it arranges your brain in a proper order and saves a lot of time for inventing a wheel. It is especially effective when you are dealing with a version 1.0 and need to build everything from scratch.
I have my favorites:
- Risks (#5,17 from the list above).
- Scope: In/Out (#6-7).
- Phases: In/Out/Suspension/Resumption criteria (#9-10).
- People: Stuffing/Training/Responsibilities (#14-15).
- Environment and tools (#13).
- Communications management (ideally a part of a project plan).
- Stakeholder management (ideally a part of a project plan).
This list is a summary of my professional experience. And I wonder what your favorites are.
I have my favorites:
- Risks (#5,17 from the list above).
- Scope: In/Out (#6-7).
- Phases: In/Out/Suspension/Resumption criteria (#9-10).
- People: Stuffing/Training/Responsibilities (#14-15).
- Environment and tools (#13).
- Communications management (ideally a part of a project plan).
- Stakeholder management (ideally a part of a project plan).
This list is a summary of my professional experience. And I wonder what your favorites are.
No comments:
Post a Comment