Why Do Some Testers/Test Managers Have a Siege Mentality?


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.

4 Replies to “Why Do Some Testers/Test Managers Have a Siege Mentality?”

  1. Hi Johanna,
    There are several points I disagree with you.
    “Testers have to develop” is not true for black box testing, only for white box testing. Black box testing requires a proper understanding of the functional and non-functional requirements.
    “Waiting for requirements to be perfect” is presumptious. There is no point in testing if you cannot tell right from wrong, so it it legitimate to wait for requirements to be stabilized. Stabilized does not means it’s perfect, but it is “good enough”.
    “How else [than by developing] can they [testers] know how to create good test systems?” is also presumptious. If you take a test drive with a new car you plan to buy (to verify against your requirements), you don’t need to know how to build one.

  2. The siege mentality can be driven by a number of factors. A few of them:
    1. QA boss reports to a R&D boss. No separation of powers, hence, one ought to be sieged (guess who – the major developer or the major tester). Ensuing here stands lack of control, decision power, etc.
    2. QA positions are treated as less valuable in the company. Naturally QA positions require not as vast and not as deep experience as developer’s ones. Starting as a QA and advancing to a developer is a standard route. Although it’s natural it shouldn’t diminish the power of QA and the top management must impart the notion of importance of QA team and its criticality for the company success. Emphasizing its role makes finding right people for QA a very challenging task though.
    3. Working in a sequential (not parallel) mode makes two teams (Dev and QA) have a feeling of WE and THEY vs. just one WE. The two teams must work together from designing features and all the way to the fixing bugs (but still report to two different bosses).
    Sieged QA team makes overall efforts if not useless upfront but at least very inefficient and growing a productive QA team is a complex task for company management.

Leave a Reply