As part of the larger project plan, the test plan describes the activities taken to assure the quality of the deliverables. In the first part of this series, I described the types of testing commonly performed during IT projects. I’ll continue with a description of some common roles in planning, conducting, and assessing tests, and address issues involving the scope of testing. Actual titles may vary considerably, but these roles are found in most non-trivial IT projects. In many organizations, a dedicated Quality Assurance (QA) group may be involved in some or all aspects of planning and conducting testing. But whether the roles are filled by staff from the QA department or other project team members, they need to be accounted for in your project plan.
- Project Test Lead – This is the person responsible for oversight of testing on the project. This person is also accountable for the processes used to ensure the quality of the deliverable. It might be the project manager, or someone from QA, or someone else altogether, but this person is responsible for quality control of quality assurance. Read that again, and let it sink in.
- Testing Manager – This is the person accountable for conducting quality assurance testing and executing on the test plan. There may be different test managers assigned for different types of testing, or on different parts of the project, but the role is needed whenever some type of testing will take place.
- Test Designer – This is the person responsible for creating the test scripts, scenarios, test lives, and so on that make up the tests to be performed. Obviously, a part of these products is the pass / fail criteria, also known as “the right answer.” There may be different test designers for different types of testing, or even several designers working on the same type of testing. Remember that the developer is (usually) the test designer for unit testing.
- Test Approver – This is the person responsible for reviewing, validating, and approving the test materials created by the Test Designer.
- Tester – This is the person responsible for executing the test scripts, and reporting the results. There may be many Testers on a project, at various times, or working at the same time. Some of them might even be automated.
- Reviewer – This is the person responsible for reviewing reports from the testers and determining what subsequent actions will be taken. This might be the development manager, project manager, developer, DBA, or any number of other team members, but this role in testing gives them the opportunity to receive feedback on the quality of the product. Note: the Reviewer is not necessarily the person who will “fix” whatever was determined to be a defect.
Note that each of these roles, aside from the Project Test Lead, may have a scope of responsibilities that is limited to certain types of testing, or certain aspects of the overall project. For example, the development manager may have the Testing Manager role for unit testing, but the Reviewer role for other types of testing. Also, the developer might have both the Test Designer role and the Tester or Reviewer role for unit testing. Thus, it is important to articulate the scope of each planned test effort in the test plan. Here are some examples:
- “Unit testing shall be limited to testing those components actually funded for development for this project.”
- “Smoke testing shall be conducted on every build.”
- “Integration testing shall include two distinct and separate efforts. [Name] shall manage testing of integrations where both endpoints are within our firewall, and [Name] shall manage testing of integrations where at least one end point lies outside our firewall.”
- “Conversion validation of payroll data shall include payroll balances, payment instructions, tax elections, worked time records, benefit elections, and voluntary deductions.”
As you can see, these statements identify the type of testing to be performed, the specifics of what to test, and where useful, name a specific person to perform a specific role. In our final installment, I’ll address some considerations for integrating testing efforts into the critical path.