The Intimidation Factor in Software Testing

Intimidation is something that everyone has experienced or given at some time or other, sometimes as the intimidator and other times as the object of the intimidation. Although intimidation is part of most project cultures, software testing is an activity that seems especially prone to experience the effects of intimidation as the giver, the receiver, or both.

I often tell beginning testers that everyone can be their friend throughout the test planning process, and even into the test execution process. When the first defect is reported, then the picture often changes. The task of defect resolution is often when defensive posturing emerges and can be seen as discounting defects as "features", "user errors", "anomalies", or even hallucinations on the part of the tester. Many times the defensive behavior degrades into blaming others. Testers are even blamed for the defects they find, which is like blaming the fruit inspector for bad fruit.

However, intimidation can go both ways in the software development process. Testers can feel intimidated by the knowledge and power of developers, while developers can feel intimidated by the critical review and power of testers.

While we will never be totally free of intimidation and its effects, I believe it is possible to be aware of the intimidation factor and work to minimize its negative impact on the project. In this article, we will explore the nature of intimidation, how it impacts software testing, and some definite ways to deal with intimidation.

What is Intimidation?

Intimidation is the exerting of power or force over someone to make them behave in a certain way. Police officers were certain types of uniforms to project an image of power. Think about it. Which is more intimidating - the "Smokey bear" hat clad state trooper or the bicycle cop wearing a helmet and shorts?

In the martial arts, sparring opponents will often come out with a loud yell, which is primarily intended to intimidate and distract their opponent. In baseball, the catcher will say all kinds of things about the batter's wife and mother to intimidate and distract the hitter.

From these examples we can see that intimidation is often an adversarial position between two or more people. Sometimes, the motivation to intimidate may be to achieve a common goal, such as a football coach intimidating the players in order to win a game. However, even in the context of a common goal, intimidation is a weak method to motivate using power plays.

When you take the idea of intimidation and adversarial stances into a project situation, it is no wonder that so many projects have difficulties. Instead of bringing focus and cooperation in the context of agreements and well-defined working agreements, people resort to the first technique they ever learned ? intimidation. That explains why some projects resemble public school cultures. You can pick the grade level.

It is interesting that each of us has the ultimate control over intimidation in our lives. We feel intimidated when we give people power to make us feel a certain way. As long as we feel fear from an intimidator, he or she will continue to have a level of control over us. Once we decide that the intimidator has no control over us except to manipulate emotions, we can move past the fear and go on with out job.

An intimidator can change by learning how to deal with people in a disarming way. Many times people do not even know they are intimidating others until someone calls it to their attention. After coming to the awareness that one is an intimidator, then it is possible to change. However, change is one of those things that requires continual attention and often the help and understanding of family and co-workers.

In other cases, the person feeling intimidation might be feeling that way because of self-imposed fears. This is especially true of people who create things and are reluctant to reveal their work to others. This explains why software developers might feel intimidated when releasing their work to an independent tester. If the feedback from the tester is constructive and focused on the product in a positive way, the perceived intimidation level can be reduced and even eliminated. However, if the feedback is critical, then the software developer will likely build a series of emotional defense mechanisms, which can range from disengaging emotionally from the project to anger.

How Intimidation Can Impact a Project

While the focus of this article is on dealing with the intimidation factor in software testing, most people with experience on software projects could relate plenty of situations where intimidation was used between customers, users, senior management, development staffs, documentation staffs, and groups other than QA and testing. The impact of intimidation exerted by a customer or user on the development staff can certainly cause major project problems.

For example, the customer that insists on a software release in three weeks "or else" has single-handedly introduced perhaps the most significant project risk -  an accelerated deadline. In this example, the intimidation often ripples through the development team, testers, documentation writers, trainers, customer support staff and everyone else in the software release process, including users.

Realizing that intimidation can be seen anywhere and anytime on a project, including software testing, for this discussion I will suggest the following major points of impact from intimidation:

Creating an Adversarial Culture

One of the first things that intimidation does is to build walls between people. These walls divide people into camps that seek to protect their respective territories and interests. This kind of division leads to the "us vs. them" mentality. These walls are perhaps seen most often between software developers and testers. One example of this is when a development group seeks to impose its way through intimidation to a user group, especially user acceptance testers. The user acceptance testers may feel that a particular issue needs to be resolved before going live with a system or release. However, the developers in an effort to meet the deadline may try to intimidate the users into living with the problem until the next release.

Regardless of how valid the arguments on each side of the issue are, the fact that there are two opinions means that people will join a side. Some people will hold fast to their positions, even at the expense of the project success. The problem then becomes larger than just the resolution of the particular issue at hand. People are now pulling different directions on the project and the overall goal of delivering a quality system tends to get lost in the discussions.

Getting One's Way at the Expense of the Project or the Customer

This type of negative impact is seen often in testing. An example is when one person wants the application or system to go live regardless of the information from testing. I am very much a proponent of management making the implementation decision based on information from many sources, including testing. The problem is when one person forces a bad project decision through intimidation. Unfortunately, in these kinds of situations many people suffer innocently at the preferences of the intimidator.

Dividing Loyalties

People should be heading toward a common goal on a project. However, when sides start to emerge and intimidation is used as a means to "win" a disagreement, people will naturally gravitate toward the leaders they agree with. Even more significant is that people will reject or at least minimize their support for the leaders they feel are exerting pressure. Many times, these loyalties follow functional lines, such as developers, testers, users, etc.  However, divided loyalties are also seen within groups, as opposed to teams. I make this distinction because divided teams are dysfunctional and typically don't last too long in a divided condition.

The nature of a team is to be unified. In a divided group, such as a test organization, people may be loyal to the intimidating leader or to the people in the group who are being intimidated. One example of this is when the test leader resorts to intimidation to get people to work on Saturday. The testers may give in to the intimidation, but if they don't want to be there the leader has just lost some influence. It won't take too many Saturdays at work before the leader's influence has been spent and test group starts to explore other work options.

Cutting Off Communication

Effective communication is essential for all aspects of a project, and trust is the basis for good communication. If people can't trust that their information is safe with the receiver, then they aren't going to share it. When intimidation is used as a means to get one's way, trust is one of the first things that is lost. When someone starts to intimidate, it means that they prefer to use force over other more positive forms of influence to get the job done.

Force is easier to use because the intimidator doesn't have to spend time understanding the other person's perspective - "Just do what I say."  Communication between developers and testers is essential for the smooth flow of information and work products. When the developer to tester communication bridge goes down, so does project productivity.

Removing Focus from the Project Objectives

When intimidation comes into the project, people become so upset over being forced to do something, they spend more time and emotional energy brooding over the intimidation rather than the project or even the issue itself. People start to dwell on interpersonal problems rather than getting the job done. This can be seen in any number of ways, but break times and lunch are especially revealing of the interpersonal aspect of a project.

Creating a Culture Where Things are Hidden (or Things are Revealed to Manipulate the Intimidator)

In organizations where intimidation is seen often, a culture develops where it is a virtue to hide information. This goes back to the issue of trust discussed earlier. However, intimidating cultures have trampled out trust so long ago that lack of trust has turned into fear. Hiding Information is a common occurrence between developers and testers when levels of trust erode. The lines of communication in these kinds of situations can become very complex and start to resemble a soap opera more than a project.

In fearful and closed cultures, people learn the nuances of who they can trust with which level of information and how likely it is that the information will be used by someone for intimidation in the future. To make things even more complex and bizarre, information is sometimes revealed to a known intimidator for the sole purpose of seeing that person intimidate someone else. This takes the culture down to the high school level.

Creating an Over-Emphasis on One Person's or One Groups' Perspective

Intimidation can also give a false impression of a situation just by the force of the person giving the information. I encountered this once in a week-long session to identify the functional responsibilities at a company that was making their second attempt at developing a new company-wide application. There were over a dozen functional areas that needed to be addressed, such as accounting, order processing, human resources, customer service, etc. Each functional area listed the activities it performed. As the meeting progressed, it started to appear that the customer service area did more activities than any other group. However, as I took a second look at the lists, I realized that this was largely due to the fact that the head of the customer service department was a very forceful person and dominated a lot of the discussions. The other people in the group from other departments were not able to contribute their activities. So, we had to address the functions in smaller groups to get a more accurate idea of what each department actually did.

How Intimidation Can Impact Software Testing?

Most people will agree that intimidation is detrimental not only to the project but to people on the project. Software testers often seem to feel the impact of intimidation in a variety of ways.

Convincing Testers that a Defect is Really not a Defect

When I first started performing independent testing many years ago, this was one of the first occurrences that became a shocking reality to me. I would report problems, but people wouldn't believe me. It's not that they were accusing me of lying, it was that they believed that I must be doing something wrong. I learned that I had to carefully trace my steps and be able to show someone else what I saw. The intimidation really came into play when someone in the development group would try to convince me that, "yes, we see that the situation really happened, but it's really not a problem."  If I went along with the "no problem" assessment, then it was my reputation on the line if the problem occurred in the real world use of the software. If I stood my ground and insisted that, "no, it really is a problem" that's when the intimidation started, especially if the deadline was near.

Overriding or Minimizing the Results of Software Testing

Sometimes a manager, project leader or customer wants so badly to see a project implemented at a certain time for a reason that they choose to take a risk and implement the project even in the face of negative test results. The implementation decision should be a team decision based on information from testing, customer support, technical support, operations and any other area that will be involved after the project is implemented. The intimidation factor comes in when one person or a group of people try to control the implementation decision, although others see the downside risks.

In projects where the implementation decision is not team-based and is between the project manager and the QA manager, intimidation can be seen in very quiet, yet powerful ways. When the project fails, people may wonder why the implementation decision was made, but few will understand the intimidation that occurred behind closed doors.

Convincing the Testers that the Deadline is the Most Important Project Milestone

Many times on projects the deadline looms as such an immovable object that people can't see anything else. People are afraid to even suggest the possibility of missing the deadline to deliver a higher quality system. The reason the deadline looms so large and immovable is because someone has communicated it that way. Certainly, there is a need to manage to timelines and milestones. Otherwise, a project would go off track quickly. However, to make the deadline the only target is to miss other important goals, such as quality and scope.

Intimidation is seen when customers, uses, or project managers keep exerting the force of the deadline to continue the project death march - "We've go to make the deadline or else" becomes the project slogan. Some managers set aggressive deadlines for the sole purpose of seeing how much work the people can do in a period of time. Another motivation for aggressive deadlines is to motivate a team that may have started to perform slowly.

Blaming the Testers for Poor Software Quality

Some people in organizations have a misunderstanding about testing that results in blaming testers for excessive levels of defects they might find during testing. These people fail to understand that the testers are inspectors and are not responsible for the initial quality of the product. If testing is performed as an end-project activity, the defects found will be higher than if a life-cycle approach to testing is performed. Performing most tests at the end of a project also results in many fixes being applied just before implementation.

The nature of most systems is that one change can have a ripple effect throughout the entire system, possibly impacting other systems as well. The more defects found at the end of the project, the more chaotic things become and the most natural solution that occurs to many management groups is to simply "stop reporting so many problems!" Of course, this is not a solution at all, just delaying the discovery of defects until the customer starts to use the system.

There may be people on the project that see the folly in reducing the intensity level of testing and seek to press on to continue finding problems. It is at this point that the pressure of intimidation can be seen in an effort to get those people who want to persist in testing to "lighten up."  If the testers relax the effort, they will also probably be blamed later for not finding defects that the users encounter. If the testers persist in testing and reporting problems, they risk being ignored, replaced, or worked around for the goal of delivering something by the deadline.

How to Deal with the Intimidation Factor

Although we have seen in the above discussion how intimidation can negatively impact a project, especially in software testing, the good news is that there are things you can do to deal with intimidation.

1.   Understand that intimidation is a natural occurrence on a project and prepare yourself mentally for it. People tend to use intimidation when they run out of other ideas. Just understanding that intimidation will likely occur is a step forward. Having a mental strategy of how you will respond to intimidation is a helpful way to diffuse it. Remember the illustration at the beginning of this article about how a martial artist may yell loudly at the start of a match to intimidate their opponent. What if the opponent expects the yell and responds in their mind "OK, I was expecting that. I think I'll try a kick to the head."  By anticipating the intimidation, you have taken away the surprise and therefore, the power of the intimidation.

2.   Understand that you may not be able to change the intimidator, but you can control how you react to them. The intimidator deals mainly in fear of future events, for example the "or else" threats. You can take away the intimidator's leverage if you don't care want happens. Remember the bully from grade school that threatened to beat you up if you didn't do something? You had a choice - either give in to the bully and live to be intimidated again, or to stand firm and see what they will actually do.  Standing firm has a price. You have to be prepared to live with the consequences of not being intimidated ? such as losing a job or the loss of a working relationship with someone you thought was a friend. The thing to remember is that you have control over who and what intimidates you, and that is a freeing realization! Another positive outcome is that standing up to the intimidator often makes them think twice before intimidating you in the future.

3.    Understand that intimidation is an emotional response, based on feelings that you allow the intimidator to manipulate. Once you can feel empowered to do your job regardless of what the intimidator thinks or does, then you can be free of their negative influence. Sometimes you can be intimidated by what you think someone else is thinking. This kind of intimidation may be unintentional on the part of the other person and can be a totally irrational response on your part. As humans, we are emotional, some more than others. Regardless of how much we let our emotions show, we still live with feelings whether good or bad. The problem is not with our feelings, it's how much power we give to our feelings.

4.   Educate the organization on effective interpersonal skills, including communication on projects. Conduct workshops on intimidation and make sure known intimidators attend. These workshops are very valuable to both the intimidator and the people who are often vulnerable to intimidations. You will need a skilled facilitator and instructor to lead small groups of 12 or less through interactive role-playing exercises.

5.    Educate the organization about what testing can and cannot do. Also, educate people about the advantages of life-cycle testing vs. testing projects at the very end.

6.    Reduce the emotion-based problems by using process-driven methods. The decisions and actions that intimidators often try to impose are instead dictated by process criteria, not emotional-based decisions. Processes can do a lot to take the politics out of routine project activities, such as test reporting and giving the bad news. I like the example of what happened to a friend of mine when someone tried to intimidate their way into getting an "emergency" change placed into production. My friend, as the configuration manager, asked the requester, "Is the problem your change is addressing: 1)  a safety problem to our employees or customers, 2) a legal or regulatory problem, 3) a cause for loss of business?"  The requester could not justify any of the criteria had been met, so to adhere to the release process, the emergency change wasn't granted. The decision was made by the process. Had the process been violated, a precedence would have been set as to weaken the entire release process.

Conclusion

Intimidation is a part of just about every project and it seems that testers are in a position to deal with intimidation more than any other group in a project. The good news is that there are ways to deal with intimidation and keep the project on track, even in the area of software testing. The key is to understand that each person has the ability to control how much power they give to the intimidator.