During a coffee break in at a class the other week, I overheard the following comment from one student to another:
Tester: This stinks! All of my automated test scripts are broken and I can't seem to get the tool to work now that the developers have enabled Secure Sockets Layer. I'm going to have to work through the weekend.
I know that it's generally considered rude to eavesdrop, and ruder still to comment on a conversation you weren't invited to, but I figured that since I was teaching the class I'd be forgiven. Besides, I simply couldn't help myself.
Me: Why don't you just turn off SSL until your scripts are done? They're functional test scripts, right? Besides, you can spot check by hand that turning on SSL didn't break functionality when the scripts have finished.
Tester: We can't do that.
Me: Can't do what?
Tester: Can't turn off SSL.
Me: Sure you can. It's easy. Depending on your Web server, probably just changing "yes" to "no" in a UI, or a 1 to a 0 in an .ini file.
Tester: No, we can't do that.
Me: (Confused look) Do you mean that you don't have access to the server?
Tester: No, I mean we can't do that.
 |
|
|
|
|
The testers who aren't busy making unreasonable (and sometimes inappropriate) demands of other members of their team are busy lamenting the fact that they feel helpless, stuck and useless.
|
|
|
|
|
|
|
|
|
|
By now I'm starting to understand what is going on, but I'm not ready to let the student off the hook quite yet.
Me: OK. Help me understand, though. Who is "we" and why can't SSL be turned off?
Tester: Well, I don't have access to the server.
Me: I'm sure someone does. Who can we call? I'm sure making a call is less distasteful than working all weekend.
Tester: Nah, I don't want to do that, I'm not even sure that SSL is the cause. Besides they'll just say "no" anyway.
At this point, one of the other students (who happens to be a business analyst, not a tester) looks at me, smirks, and grabs her cell phone:
BA: (Speaking into her phone) Hey Ian, are you in the server room? Yeah, you know that build you guys just promoted? Yeah. Do me a favor real quick, will you? Turn off SSL for an hour. We're trying to test something. Thanks!
BA: (Speaking to tester) Ian says he'll leave SSL off until 4 p.m.
Tester: Uh, ok, I guess I'll try my scripts in a little while then. (Walks out of the room -- presumably to get coffee or something.)
The tester finally did try the scripts and they worked, but I only know that because I had a short conversation with two students after class about the interaction. I wanted to know if there was some personal or organizational reason why the tester was obviously reluctant to make the request to have SSL disabled for a short period of time. What I was told was that this tester almost always behaves helplessly. All I could do was shake my head sadly.
Sadly, because sometimes it feels to me like the testers who aren't busy making unreasonable (and sometimes inappropriate) demands of other members of their team are busy lamenting the fact that they feel helpless, stuck and useless. Sadly, because helplessness is frequently a learned behavior. Sadly, because people who view themselves as victims tend to exhibit this behavior. Sadly, because it makes me think about all of the testers I've met over the years who tell me that they feel trapped, helpless, and under-valued.
I've tried many times to figure how and why people end up in that place. I realize that developers frequently get more praise (and more pay). I realize that we aren't the center of the software development project and thus our recommendations aren't implemented as often as we'd prefer. I realize that project members sometimes react to our bug reports as if they were blaming us for having caused the bug in the first place as opposed to thanking us for finding it before our clients do. Even so, none of this seems to me to be sufficient to trigger victim-like behavior among so many software testers.
Honestly, I don't know what the root cause of this behavior is. What I do know is that it is not healthy for the project, the team, and especially not healthy for the tester. If you find yourself feeling this way, maybe the first step is to take a deep breath and say to yourself, "I am not the victim!"
Because the truth is, at the end of the work day you go home and do whatever it is that you do. And if you really don't like the way your job or project is going, you might even go home and post your resumè to your favorite job board. The real victim when testers are disabled from doing their best work for one reason or the other is the application. The application has no recourse, no choice and no way out without help from someone. If nothing else, the odds are that whatever is making you feel helpless and hopeless is not actually about you at all. It's about the application. At the end of the project (if not before), you'll move on. The application might not be so lucky.
At the end of the day, you are not the victim -- the application is.
----------------------------------------
About the author: Scott Barber is the chief technologist of PerfTestPlus, vice president of operations and executive director of the Association for Software Testing and co-founder of the Workshop on Performance and Reliability.
