When I meet testers, I often hear a specific word, “Why?” I thought that might be a great word to use in this article.
Testers often ask, “Why does this feature work that way?” Or “Is this feature supposed to work that way?” I certainly asked that question often when I was a tester. There were plenty of times when it was clear that no, the feature was not supposed to work that way. If I couldn’t log in, if the system crashed, if the hash table was corrupted, I knew the feature was broken. I didn’t have to ask.
But sometimes, I wasn’t sure if the feature was supposed to work that way, and I did ask. That’s what testers do. We ask about the system under test. We provide information about that system, sometimes from our questions, and sometimes from our data.
We are curious souls. We are critical thinkers. We have to worry—are we being too critical of the people and not of the product?
I bet all of you have a story like mine. I was testing, finding problems in a product, reporting them. The developer finally burst into my office, yelling, “If you don’t like me, just say so!”
“Dave, I like you a lot. What’s the problem?”
“You keep reporting bugs against my code! You don’t like me anymore.”
Ah, I saw the problem. “Dave, it’s not you. It’s your code.”
“Well, of course it’s me. I wrote that code.”
“Maybe you were having a bad code-day?” I paused. “You know, normally you have people review your code. I never asked. I just kept filing bug reports. Sorry. Did anyone ever review your code?”
Dave shook his head. “No. No one could make any time for me. They were all ‘too busy.’ And now you hate me.”
“Okay, hold on. I don’t hate you. Maybe instead of testing with tests, I should do a code review with you. Would that be better?”
Dave thought for a few seconds, and said, “Well, you know me. If I’ve got problems in one area, I probably have more. When I’m smart, I’m really smart. When I’m dumb, I’m a real dodo.”
“Dave, this is not about smart or dumb. This is really intricate code. I had to think really hard to write the tests. I’m not sure the tests are right.”
“No, the tests are right.” He used his Eeyore voice.
Dave and I code-reviewed his code. We found a few more problems in the code, and we found a number of places he was able to improve his code and fix some technical debt before it came back to bite him.
“Normal” testers don’t do this—or do they?
What do normal testers do?
I was a developer before I was a tester, so that colors my approach to testing. It never occurred to me to do manual testing first. I automated testing because I was a developer. Why do something manual when a machine could do it for me?
I used version control because machines did that for me. And, yes, I used exploratory testing in an automated way— okay, a brute force, automated way—because the machines could do it faster than I could. Was that smart? Maybe, maybe not. It was a reasonable use of my limited time.
I have found that there are as many reasonable approaches to testing as there are testers.
But here’s what I don’t find reasonable:
· People who claim they have the one right way to test
· People who claim they never ask why
· People who never vary their test approach
· People who never automate their testing
· …
I could continue, but I bet you see the pattern. I don’t believe in absolutes.
What is a tester’s role?
For many years, my mission as a tester was this: Provide information about the system under test and report on it.
Anything that allowed me to do that was fine with me. That mission is broad, and allows for a wide variety of activities.
Does a developer need code review? I can do that. Do I think that’s wise on a regular basis? Maybe not. Will it move the features across the board, especially for an agile project? Yes.
During a retrospective will I suggest that maybe I am not the right person to be providing code review? Yes. Not because I become too close to the code, but because I need the time to develop tests. Do you see the difference?
Now, do you think you should provide code review? That’s a question only you can answer. If you think the answer is yes, but you don’t have the technical skills, that’s something you can fix. If you think the answer is no, why not?
Maybe you’re not interested in developing more technical skills. That’s fair. I know some terrific testers who would not be caught dead reading code.
However, I know many manual black box testers who don’t know how to read code. They don’t know any scripting languages. All they know how to do is execute test plans
someone else has written. They don’t have great critical thinking skills. They don’t vary their test approach. They don’t automate their testing.
Those people have a very limited career path. Why would they want to be testers? I don’t know. Maybe you can tell me.
Why Women?
This edition highlights the contributions of many women testers and managers. I have the honor of being one of the contributors for this edition. I just saw a statistic that says the number of female software developers is up 87% since 2001 (http://www.evansdata.com/press/viewRelease.php?pressID=209) to almost 20% of all US software developers. That’s a relief. Why? Because when you have diverse teams, you can create great products. Women and men, together, can create great products. Even better, when you have diverse backgrounds, both of experience and culture, you can create great teams to do wonderful things. People on teams solve problems together. We can’t only have the women on teams be the testers. You might be a different kind of a tester than I was. You might be a different kind of a manager than I was. But, I bet you are a curious, open-minded, critical thinker, who enjoys exploring the product under test in various ways.
I invite you to read the rest of this edition and consider, ponder, and explore. See what our colleagues, these wonderful women have to say. I know that I will.
About the Author
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice to your tough problems. She helps organizational leaders recognize potential risks, seize opportunities, and remove impediments. Johanna is the author of seven books and more than 300 articles. She writes two blogs on her web site, jrothman.com, as well as a blog on createadaptablelife.com Please do read more of her writing including her newsletter there.