Every software tester has a story about how they have been misunderstood or mistreated by co-workers or colleagues, or managers that don’t understand the work they do or its importance. Those things sometimes happen, but it’s a two-way street. There are times as testers when we can be our own worst enemy.
Recently the RatPack put their heads together on this subject and came up with a list of things that testers do when they’re behaving badly. Here’s what we came up with.
Testers it is Time to Grow Up!
Rat Pack Author: Franky
Too few of us are taking our profession seriously and responsibly. What I mean by this is that way too often I come across testers who are not taking pride in their work. Testers who just do what they are told to do without thinking or questioning if this is a good and efficient way to do the task.
Are you curious and devoted to sharpening your skills in testing? Are you reading books, articles, blogs about testing or contributing to the testing community? Many of the testers I meet would answer no to those questions. That is a comfortable and easy approach isn’t it? But what does that do to your skills, career or the testing profession at large. On the other hand, the testers who do are the ones who often impress me and are a joy to work with.
Who is more qualified to decide how you practically should do your work? Your manager? Someone in a process department? Most likely it is YOU and your peers who have the most skills and knowledge to perform your tasks. What I’m saying is that you as a tester have to put yourself in the driver’s seat and take charge of the way you do your testing and also be able to defend and justify why you did what you did. Not hiding behind processes or managers.
If you do not want to do this you might ask yourself why you are a tester. We testers are expected to question the product. Why do we not question our way of performing our testing?
There are several ways to step up your game. One way is to start sharing how you do your testing with others and ask how they are doing their testing. This is a great way to learn and to get inspiration from others. There is so much information available on the Internet and many forums where you can comment or post questions. Start questioning yourself and your workplace; how testing is done. Are there changes that you can do yourself to improve your way of working? Most importantly start caring about your work; what you do will reflect on how others perceive you.
Stop doing things just because you are told so. Show some integrity and do things in a way you are proud of. Are you one of those who are doing your testing the same way as you did it two years ago, just because you do not care or your company’ process says so? Why is that?
The Glass is Half-full
Rat Pack Author: Marilyn
I’m a passionate tester. I love testing. Most of all, I love finding problems. I like to look at things from a critical point of view. The problem with me – and some other testers I have come across, is the way that this manifests when it comes to managing people.
When I first started managing a large team, all I could see were the problems. People weren’t passionate enough, they weren’t being observant enough, bugs weren’t being logged properly, they weren’t coming up with the right test ideas, they weren’t managing their time effectively, they weren’t looking after their data or managing it correctly and the list went on.
I felt the only way to solve the problem was of course to first point it out. I accentuated the problems because it was really mostly what I saw. Naturally (or so I see now), this did not have the desired result of making the problem go away. I just ended up making people feel like nothing they did was ever good enough. That part of me that made me a good tester, also made me terrible at managing.
It wasn’t something that I managed to change overnight; I didn’t even realize I was doing it for a long time. When I first started experimenting with Session Based Testing though, and debriefing with the team every day I realized that by seeking out and focusing on the positive, the rest almost fell into place by itself. Focusing on the glass being half-full altered the perspective. I actually started to see people doing great things that I wasn’t even noticing before.
Turns out as testers, being able to see the good is just as important as spotting all the problems.
Guarding the Quality
Rat Pack Author: Joey
In one project I was on, a new guy entered as tester for one group of developers. He began complaining the minute he arrived that though he liked it, he wasn’t good at this “testing stuff”. This was only a taste of things to come; he complained throughout the project.
First he needed help in setting up the test project from scratch, which resulted in “not enough time”. Then developer’s handed him code too late and it was so buggy that he almost couldn’t test it. After this came the lack of specifications. Or more correctly – fully described and updated specifications. Consequently virtually nothing ever came out of the group, and what did was tagged: “you’re on your own!”
As I saw it, the tester claimed that he was the last stance for securing quality, mostly with quality defined as “bug free software delivered on time”. That is a magnificent definition of quality, but it’s more than difficult to achieve. A better definition is Jerry Weinberg’s: quality is value to some person. In this particular case, part of the value (to me and a lot of others) was a delivery. We could live with a number of bugs, as long as it didn’t howl and die upon our first touch.
Instead of standing guard over the software, withholding it endlessly, the tester could have asked about the tolerance for software bugs and used that as a guide for his work. Testers should help, not be a hindrance.
Lots of people I’ve told this story to tell me that this is really a description of another bad behaviour: “don’t be a whiner”. I agree somewhat, but I cannot break away from my initial gut feeling, that this was really a matter of standing guard.
Territorial Pissing
Rat Pack Author: Peter
Ever try to give someone helpful advice and been met with a frosty response? You probably trod on someone’s toes. It’s a situation that I like to call “territorial pissing”.
No one likes to be on the receiving end of such a response, especially when your comments were well intentioned. As testers, sometimes we’re guilty of this too, at least I have been.
One project manager told me, “if you write out all of your test cases, then we can have other members of the project team do some testing too.” He didn’t get why I felt insulted.
What he thought he was saying was, “I know you are short staffed and have a lot of work. Let me help.” What I heard was, “Since your team does monkey work, just write down your monkey recipes and I’ll have other people do it when they’ve finished doing the more important stuff.”
I felt that the skill required to be a good tester was being summarily dismissed. He was taken aback when I told him that I wouldn’t trust anyone else to do the job well enough. I also said that anyone who equated testing with following test cases didn’t understand testing and might like to join the rest of us in the 21st century.
In hindsight, I could have handled this better. I got this guy offside because I was too defensive.
What I should have done was swallowed my bile and taken a moment to explain that actually there’s a little bit more to testing than being a robot and that if someone wanted to volunteer to help I would gladly give them work to do, but people who are forced to test generally do not do as good a job as people who are passionate about testing. The way to express that was not to cast aspersions on the intellectual ability of this guy.
I was able to explain myself more rationally and cogently later, which is fortunate as I not only worked with him frequently, I ended up reporting directly to this guy after he was promoted.
In my experience, it is generally not the case that encroachment on your territory is a calculated assault. More likely it is a difference in understanding and/or miscommunication. Before you get your hackles up, try and see how they are trying to help and use that to formulate your response.
Holier than Thou
Rat Pack Author: Dean
“This software is the biggest piece of garbage I’ve ever seen.”
“This can’t possibly be what you meant to give us. It doesn’t work at all.”
“This is just wrong. You need to fix it.”
I’ve heard all of the above said by otherwise good testers. What is wrong with these phrases? They are all signs that as a tester you are acting badly. Worse, saying any of these things even once, can cast you in the eyes of the rest of the team as the prototypical “bad tester”. Being a bad tester means you would rather make a scene in meetings than provide useful information to the team.
What could you say instead?
“I’m having trouble getting end-to-end use cases working. Maybe I have the work flow wrong. Can we talk about how data moves through the system?”
“I was doing some testing on the query engine and I didn’t get the results back I was expecting. Do you have a tool I could use to look at the index and see what terms are in it?”
The idea behind all of these is that behind the complaining you probably have a request. For whatever reason you are blocked and you need help to make progress. If you can think about the request behind the complaining, your team will thank you for it.
The Quality Crusade
Rat Pack Author: Sammy
When I started at my most recent job, I immediately started talking testing and trying to find ways to fix their problems. To my surprise, this had the totally opposite effect than I expected. In a few words, the lead developer thought I hated unit testing.
But that was just the tip of the iceberg. In trying to understand my role and how I fit in with the company, I started making recommendations – sometimes in ways that they approved, and others in ways that they didn’t. When I was more adamant about my recommendations (because I felt strongly about my job), it only made things worse: I came off as closed-minded and not open to their ideas. In thinking I had “the answer”, I burnt bridges that I have since come to rely on.
This is the quality crusade. Instead of completely taking my new position by storm, I should have backed off a bit, learned the culture, and took more time in assessing what may actually be a competent solution to their quality problem. And that’s just it – it’s not their problem. It’s our problem, and a solution takes buy-in from everybody. When you build the bridges first, the solutions will build themselves.
Oh, and don’t go after the cute receptionist.
So there you have it. You may recognize some of these situations from experience. You may even be guilty of some of them. Testing is difficult enough without us making life harder for ourselves. The next time you find yourself in a difficult situation, ask yourself if it’s one of your own making and if so, what you can do to change it for the better.
About the Author
Author “Rat Pack”:
The Rat Pack is a group of experienced, passionate software testers from around the world. The group formed at the Conference of the Association for Software Testing in Toronto, 2008. We continue to share our experiences and challenge each other about what it is to be a software tester today. You can follow The Rat Pack on their blog www.testingratpack.com