I’ve been working as a test consultant for a year at my current client and I constantly wonder what problem next I can help fixing.
The IT department has grown immensely since last year. Not just in numbers, but in maturity as well. I’m very proud of how much progression these guys have made.
Yet, the laws of consulting state that there always is a problem and that it is quite certain to be a people problem. And so we identified our current number one problem to be: “Still many people don’t know what to expect of us, testers, or don’t know what we actually do.”
We’ve had managers asking us to do gatekeeping, exhaustive testing,… Programmers asking us to test systems that don’t have an interface, do implementation level testing,…
We decided to create some kind of manifesto. A clear set of rules and statements that best describe our core business. This is what came of it:
This is a first version and hasn’t been put up yet, but we feel we’re getting close.
The testers felt the need to create a concise, to-the-point document which we’d print in large and raise on our wall as a flag. They want to be understood and grow from having to hear “just test this” to “I need information about feature X regarding Y and Z”.
I, as a consultant, wanted to unite testers, programmers, analysts and managers under a common understanding of what testers do, don’t do and can’t do.
Knowing that my days at the client are numbered, I want to leave behind tools for the testers to fight their own battles, when the time comes.
I have seen us become a team that supports the IT department in diverse and effective ways. Yet recently, powers that wish to fit us back into a process box have been at play as well. I’d hate to see the team become reduced to a checkbox on a definition of done again.
Isle of IT 
Great stuff. You inspired trying something similar in my company. I do also have some feedback on your manifesto: I will not use “we do this on behalf of” term, it sounds to me like avoiding responsibility for what we do (though … if it is not important to you, it is not important to us is brilliant). I will not assume user’s advocacy, will rather talk about user’s perspective. And I would say I can’t do gate keeping and low level testing: I can but I don’t think it’s the right thing to do. And your #1 “can do” isn’t really a “can do” I but the best i was able to rephrase it was “Integrate: we will seek to minimize impact on development progress while maximizing quality” don’t like it any better.
LikeLike
Hi Ainars,
Thanks for the feedback! I’m always looking forward to having meaningful discussions.
You’re right about the first thing not really being an activity. The explanation next to the “Quality is a Team Responsibility” probably does a better job at describing what we do.
We can indeed do gatekeeping and implementation level testing, true. It is more that we see less value in it from our perspective. By expressing that we are not going to do this, we put pressure on the programmers to do unit tests, peer reviews,…
This way, coders and testers become a united front to convince management to give the coders more time to focus on quality. This should benefit the whole team, we hope.
You make an interesting remark about responsibility. I believe “Quality of Testing” is our responsibility, not the “Quality of the Product”. We do testing on behalf of our stakeholders, and it’s our responsibility to do a good job. However, the quality of the product can not be our sole responsibility to bear.
LikeLike
I’m not native English, so I may be misinterpreting the on behalf of part.
So let me just ask you this: would you do an experiment/learning/exploration no stakeholder thinks to be important even if you as a tester believe it have a chance to discover information important to the stakeholder.
I feel like your #1 have a hidden answer to this question.
LikeLike
We would definitely also test things that we think might be important to a stakeholder, but might not be apparent to them at first.
It’s (should) also part of our testing mission to seek out assumptions and disprove them. In this sense, “on behalf of” doesn’t really mean “The stakeholders tell us what to do”, but takes the form of “We provide a service FOR our stakeholders, but still control what that service is.”
LikeLike