The
Intimidation Factor in Software Testing
by Randall W. Rice
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.
All materials on this site
copyright 1996 - 2008, Rice Consulting Services, Inc.
Rice
Consulting Services, Inc.
P.O. Box 892003
Oklahoma City, OK 73189
405-691-8075
"Leaders
are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that is
worthwhile." -- Vince Lombardi
This site best
viewed with the Mozilla Firefox
browser!
|
