My starting point for this project was the "Why" that seems to missing or at least very strange when you encounter some PM's and others that thinks that brush test off with: "Oh, that's getting to be too much. We don't need you. We don't need that much, better do it ourselves", and other similar comments. I'm trying not to get stunned and speechless when I encounter such ignorance, and I do believe that's exactly what it is, about test. This is of course an educational issue and sometimes you need a clever approach to be able to get the point across and teach these people about test. It is probably not easy and it is challenging. This is a good thing. When it is difficult and challenging it forces you to think about your craft and it forces you to work on your arguments and teaching tactics. Even if it's difficult to embrace the chance to learn and become better at our craft in a situation where you most probably is pretty upset and down right steaming mad, try to cool off and use it to your advantage if you can.
This "Why" depends on the context just like the other "Why"'s that I'll try to cover.
These are some of the different "Why"s that come to (my) mind:
- Why do we test? - on a general and perhaps abstract level that's related to non-testers attitude towards test, as a craft and as a service.
- Why do we test? - on a personal level. Perhaps I test because I love to explore and enjoy discovering things, or I test because it's a nice job and it helps me pay my bills, or I'm not a tester I just do this because the PM told me I had to.
- Why do we test? - in this particular project. It may be regulatory demands that needs to be fulfilled or it may be a business critical production system that has high availability or high security demands. The reasons on this level are not always as clear as they perhaps should be. Being clear about why we test on this level will help when decisions need to be made about how much effort and work is needed when designing tests or when designing automated checks. Communicating the reasons is also
- Why do we test? - integrations. This is not as obvious when you think about it as it might look. Think about it.
- Why do we test? - performance, in this particular way or at all. This is also not as obvious as it first may seem.
- Why do we test at all? - Why not do automated checks and run those and be done with it? Why bother with testing? Do we need real human beings with brains and minds of their own testing this?
I am far from done with this, I have only started to write and I will try to make use of the community to gather stories and experiences. There will be more on the blog as I write and I guess there will be one or two posts about writers block and distractions. It's only human, I hope!
Ola,
ReplyDeleteThe subject of cutting costs and time by decreasing test activities turns up in far too many big and expensive projects. As you write it is an educational issue, but most of the time it is too late to change the views of PM's and sponsors.
As Test Lead or Test Manager you wish you had some proven arguments that strikes the right chord even with the most ignorant PM, and hopefully your coming bestseller will give us a clue.
One idea could be to try it using a "what's in it for me* approach, where we explain to the PM that he (mostly) personally has to gain by instantly pulling his head out of the sand.
Maybe: "A successful project delivered to satisfied customers will be good for your career and will promote you to lead even bigger and more important projects in the future." (... even if they get the system a wee bit later)
Or "You are main responsible for the quality. Do you actually dare to put your reputation as PM at risk by implementing this solution in Production without knowing anything at all regarding the software quality?".
Anyone having any better and more convincing mind-changing arguments, that can turn around a decision from one day to another?
Roland, I think cutting cost and saving time has cost a lot of money and time in many projects. I'm sure you've seen that result to :)
DeleteI think that your idea about going for "what's in it for me?" is perhaps cynical but could be a very powerful move, in the right circumstances. It's about recognizing when you have to hit that switch and I have seen PM's and other stakeholders with power that might have responded to such an argument. Basically what you suggest is a version of the contract between tester and developer that James Bach is using. It's on his blog and it's a very useful list of what a tester provides.
It's hard to convince people with one argument so I don't think that there's an easy answer or a silver bullet in this area either. My cynical side says that for some people you will be able to use the same argument every time. That's for the people that once they buy the argument they will never question it. Not my favorite kind og people :) but I know they exist.
I have already put you on my list of people to talk to about this in order to gather experiences and develop ideas!