I facilitated a management problem-solving session at the STARWest conference yesterday. When I was debriefing the activities, one participant said he’s met a bunch of testers and test managers who had a “siege” mentality. He was surprised by that.
I’m still surprised when I meet people like that. I sometimes see developers who feel that they are at the mercy of marketing or management or the BAs. But much more often I see testers or test managers who feel as if they have no control over their schedules or the content of the release, or anything in their working lives.
For a long time, part of me (the nasty cynical part) wondered why they continue to work in a field in which they have no perceived control. But I realized over the years that these are good people who don’t know enough to change their responses to the system.
Too many people who feel as if they are the ones who need to make accommodation for others share these characteristics:
- They don’t know how to understand the insides of the system. Frequently, this means reading code, but not always.
- They don’t know how to work with evolving requirements. I met some people this week who told me with completely straight faces that they don’t test anything they can’t get fully defined requirements for. They were not testing regulated systems, where because of traceability requirements on the process, I might have understood their starting point.
- They don’t know how to use any risk analysis techniques to determine where to start testing and when to stop. All parts of the system are equal in their eyes for test time.
- They are focused on the goodness of the system, instead of reporting state. So a defect is a personal affront to them, not information about the system.
- They don’t realize that development is testing and that testing is development.
When I say that testing is development and development is testing, I mean that faster, high quality development does not occur without testing. Developers have to test. And faster, high quality testing does not occur without development. Testers have to develop. (How did it ever become the norm that testers don’t have to be developers? How else can they know how to create good test systems?)
Using iterative and risk-based approaches to planning and executing testing makes sense to me. Waiting for requirements to be perfect seems like a waste of time. But if these are well-meaning people, what would have to be true to make them act that way?
Part of the answer (and I don’t think I have the whole answer) is that these people have a limited knowledge of how to develop systems (especially not understanding that customers need to see the system to provide feedback about what they want it to do), limited testing technique expertise (so they can’t take advantage of early work products), and limited project management knowledge (so they don’t know about how to iterate or use risk analysis). I met some people who rejected all possible options except for how they knew to develop and test systems. (And in the spirit of fairness, I’ve met some development managers who fit this list, too.) To be honest, I was surprised people like this were at a conference.
But, in my experience, I’m seeing fewer of these people at conferences. I’m seeing many more people who have a deep understanding of the development process, who are conversant in a variety of development and testing techniques, who like to work in iterations of some variety, and are much more flexible in how and when to start testing pieces of the system.
I don’t know how to make the siege mentality go away. Expanding a person’s knowledge can help. Limited knowledge is fixable with reading, discussion, practice–learning in some way. But a closed mind is not fixable.