Instead of a Project Charter, we’ll be looking to identify a Test Management Charter. A charter establishes a partnership between the test manager and project manager; the formal way to establish this agreement for a test manager will be the acceptance of the test manager role following interviews and negotiations. During that process we therefore want to identify the various inputs that enable us to take on the test management role with defined boundaries and the formal record of the test project.
Initial contact in a project role can be varied depending on the circumstances of the test manager. For a manager coming from an internal role the initial contact may be from a line manager or from the project manager directly. For a test manager coming in externally, the initial contact may be from a consultancy manager, or via a recruitment agency, or as a response to a job ad. Regardless of the initial method of contact, the first hint of the test project boundary may be as simple as a job spec outlining the skill requirements. Initial meetings will usually take place between yourself and the project manager(s), at which point there will be an opportunity to go into the statement of work and test project boundaries in more detail.
The initial statement of work for a test project is, on the face of it, self-explanatory – we have a system that needs some testing completed. The business case for a test project is usually (but not always) evident; in very rare instances of smaller implementations the testing could be incorporated into the overall project and managed by the workstreams themselves, but that’s not why we’re here – for our purposes, the project needs a separate test management plan. During the course of discovery, agreements between project management and system integrator can hold detailed information of who is responsible for which phase of testing and so can provide (inter alia) boundaries for your test project. The business implementing the ERP system may have certain enterprise environment factors (for example, quality regulations) that influence a proposed test strategy. And the organizational process assets may include factors such as lessons identified from previous implementations that influence the boundaries of your test charter.
During the discovery phase and interview process for a new test project, you would be looking to confirm:
- the scope of testing that you will be responsible for. Unit, system integration, user acceptance, production validation? Just user acceptance? Any other split, in accordance with any existing agreements? Manual vs automation?
- the technical scope of testing required. Modules being implemented, geographical scope of implementation, high-level view of interfaces and third parties, etc.
- stakeholders, including system integrator(s), reporting lines into project and business, project structure (architect, development, data, business analysts, workstreams), etc.
- the length of time provided in the project plans for planning, preparation, execution, and closure? Deployment timelines? Key milestones?
- any known assumptions, constraints, and risks? What regulatory constraints are there, and what is the business appetite to risk? How supportive of the overall project is the business, and how receptive are end users (and their managers) to approaches from the project to spend time on business analysis and test preparation/execution?
- budget availability for external testers and test preparation, or alternative arrangements for testers, test support, test logistics.
The outcome of the discovery and interview process should provide you with clear evidence of what you are being contracted to deliver.