During a coffee break in at a class the other week, I overheard the following comment from one student to another:
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.
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.
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:
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 w...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
as 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.
