Caveat: I've discussed and thought about testing playbooks a little - I'm not convinced that I necessarily have the same interpretation as others, partly because there hasn't been enough discussion of the idea (that I'm aware of, would love references if people have them) for a consensus to develop. This is my best attempt at this point in time, it will undoubtedly change.
I loved the idea of a testing playbook when I heard James Bach talking about it on Twitter last year:
- "a testing playbook is a tool for sapient testing"
- " I want something much less expensive to produce and maintain, while making my testing way better."
- "A set of lists, tables, flows, combos-- a compact reference that allows me to do thorough exploratory testing."
- "It is an aid to test design as well as test performance."
For me, this is essentially a way of gathering under my nose when I'm testing, everything that might feed into generating new testing ideas as I test, or help me to see alternate ways of structuring the tests I'm doing. When I'm in a test session on something complex, I need to hold an awful lot of information in my head - for me, getting some of that out of my head and onto paper or a wiki helps me to test more effectively. It also helps me ask for review of some of what I've gathered, and share it with my team.
As such, I think the content of your testing playbook is going to be highly project specific.
However, to give a few examples:
For me on one project, had we gone with the playbook idea from the start, that would have been data models, mappings, our sketches of business scenarios, SQL queries common to a number of tests, procedural descriptions of how to setup some of our complex test data, and so on.
- Context: data-warehousing/business intelligence, very complex test
data, legacy systems, need for close collaboration with developers/architects.
Here's someone else talking about his tester's playbook: lists, tester's models, scenarios, tech notes, notes on environment, and questions. Again, he uses this for collaboration purposes, so many of these are annotated as a result of discussions.
And here's a comparison of a scripted approach with a more exploratory approach using a playbook, with a good description of how compiling the playbook involves a lot of discussion with developers and architects about risk areas, oracles, testability deficits, dependencies and so on.
