I’ve been asked to create a test team definition document which can be rolled out across the department so that people understand the test team do, what to come to us for, how to approach us etc. What I’m not sure about is whether this would be better to include in a Test Policy to reduce the number of documents there are. I’m already trying to reduce the number of pages in a test plan and have these as one-pagers so would really like to keep this simple and not too old school. Any suggestions?
Option 1 is to make a separate team definition document first.
- If it is useful, then you can include in the test policy. In this case there is support.
- If the document did not have the desired effect, then there is still time to adjust it to your company.
- This approach will only affect a single team on the short term.
Option 2 is to include the team definition document in the test policy immediately.
- If it is useful, then you solved the problem for the whole company in one go.
- If the team definition in the test policy has not the desired effect, then team definition can be experienced as an annoying thing in the whole company.
- This will affect all the teams in the company on short term.
Some other things to consider are:
- talk with stakeholders like developers, managers, and customers while wriing the team definition.
- create feedback loops to take care of the most harmful effects of the team definition.
- be aware that some people have problems with a team definition. Listen to their concerns.
- take the company culture into account. Sometimes people will do things when a manager supports your team definition document.
Improve Quality Services made a one pager for a test policy. See page 6 of the following presentation:
A similar approach could be used for the team definition document.
Probably will depend most on if your company has a QA division that is separate or not. Almost everyone with the exception of highly regulated Orgs or subcontractors has gone the route of agile, where the whole team owns quality, in which case a document makes less sense. If you are a subcontractor, it’s going to be a separate document anyway.
But if this does not apply, then a wiki page paragraph outlining why testers do test is still needed. Every team i have been on struggles for example with sprint planning and the “definition of done”. Until everyone meets and writes it down, your feature delivery is always uncertain, and in the same way a testers manifesto is needed. It needs to say something short, like:
- “The whole team owns quality. The test engineer on the team keeps account, and will perform many of the rituals that inform us at the earliest possible time when the product has deviated from the specification. The test engineer will automate or use tools for some of these checks, and will gather information about possible risks yet unknown by, for example, exploring customer experiences.”