Abstract: The Testing Manifesto is an encapsulation of a what some of us, context-driven testers, believe the role of “Tester” to be. The skill-craft of testing can be too blurred in many environments, such that we thought this was necessary to put out there. While we’ve used this internally for a while now, we were prompted to share this after seeing a recent tweet gain multiple likes and retweets, which on the surface seems noble, but is actually part of the misinformation out there on what the role of testing actually entails. Testing is not Product Management; Testing is not Programming. At my company, this is used as a guideline, in conjunction with the Agile Manifesto that drives the higher level team processes.
A while back, we all got a good look at the Agile Manifesto, along with the twelve principles (or combined into one PDF here) which puts the focus on coming together to collaborate and solve problems. Now, while collaboration is an excellent way to generate solutions, as leveraging the wisdom of the crowd is a valuable practice, this can sometimes become a driving forces that puts too much emphasis on cross-functionality and push craftsmanship to the back burner. The Agile shops we’ve witnessed fall into two main categories, collaboration vs craftsmanship. Don’t be confused, these are not completely opposed camps, and the latter is not devoid of the former. A good Agile shop that centers around craftsmanship will of course also leverage collaboration as a part of that, but the implementations that make us wary are those that attempt to push everyone to do everything, when a team of specialists with some overlap may actually be a much healthier approach to solving engineering problems.
The Testing Manifesto
Long story short, in order to put some emphasis back on the craft of testing, and be sure that the role testers fill is clear and does not get pushed to the edges, we have put together this Testing Manifesto (PDF).
This is meant to compliment the Agile Manifesto as the two are to be used in parallel; one is not meant to replace the other. We hope that you find value in this and can use it to help discussions with some people who could be considered more Agilistas, and need help finding that balance between the focus on collaboration and craftsmanship. You can have both, but there’s a healthy balance that many do not attain. We hope that putting this out there publicly, will help teams move the needle more toward a balanced perspective. If we’re truly context-driven, then we must admit that craftsmanship can’t always be a low priority; it matters, thus a mix of generalists and specialists may be needed to effectively solve many of the modern engineering problems we face in the industry.