10 Things I Hate About Testing - SD Times On The Web
10 Things I Hate About Testing By Edward J. Correia March 18, 2008 — Almost since I began as editor of Software Test & Performance magazine in Oct. 2006, I’ve been trying to find someone willing to contribute a feature article that might have a title similar to “X Things You Didn’t Know About.” The X would equal some number of the author’s choosing and could be their subject of choice, the only requirement being that it involve software testing. This is not that. But quality control specialist Prakash Sodhani has given me a pretty interesting list of gripes, grievances, nits and pet peeves that many of you probably share. Some of this overlaps with my May 4 newsletter “Testers Are Idiots,” which covered common misconceptions about testers and prompted some of you to write in. Let’s see if you also share some of the same dislikes.
1. The phrase: “Testing is easy and anyone can do it” “One of the most frustrating aspects of working as a tester is that most of the time you don’t get the respect you deserve,” says Sodhani, who works for a Texas-based IT services company. “I am surprised to look at what testing teams have been reduced to nowadays. And in so many teams, most of the people I see don’t have any career objectives and are only there for the paycheck.” Throughout his career, Sodhani says, many of his former coworkers chose testing because it’s the only work they could find. “I don’t have a problem with the career objectives of others. But the situation becomes so frustrating that even if you mention something worthwhile, everyone looks at you like, ‘What does this guy know?’ ” He sympathizes with qualified testers who are motivated and ambitious, but “find themselves in a situation where no one cares about their careers.”
2. Running around to gather requirements Sodhani’s next pet peeve came to exist in a company that defined agile development as a practice under which no requirements were documented. That’s right. No requirements documents. “Everything was verbal. I still remember always being so scared when my boss put out the testing assignment list.” The first thing he would look at was not the part of the app being tested, but the developer he was assigned to work with. “If I knew that the developer was one who would answer all my questions, I felt relieved. I didn’t care about the requirement, but how comfortable I was with that developer,” because the necessary testing can be done once that critical requirement information is known.
3. Developers dictating how to test This one is best illustrated with an example. “I was working on a project related to back-end testing and needed to verify things in some of the database tables.” But since he wasn’t aware of the table names and schema, he had to query the developer. “He immediately said, ‘Let me send you the queries I have, and you can run them. That’s all you’ll need.’ I stood there trying to understand what he just said.” It seemed that the developer was telling him to run the same queries for the testing as were being executed by the code. The developer confirmed this was the case. “He said that that’s how it’s been done until now. So I thought, ‘What am I testing?’ I’ll be looking at the same data the developer probably unit-tested and say, ‘It looks great.’ But that’s not what I want.” All he wanted was to know the table names and their relationships so he could write his own test queries. The developer had other ideas.
4. Salary disparity If you read the May 4 newsletter, you’ll recall that Cisco’s Jeff Feldstein characterized pay parity between testers and developers as critical for attracting and retaining talented testers. “Based on my experience, I have found that testers are not in the same category in the pay scale as developers.” And when he has inquired with bosses as to the reasons for this, “I’ve never gotten a convincing reply. Most of the answers indicated that testers don’t do as much as developers.” File that statement under statement no. 1. Sodhani compares salary disparity in IT departments with that of a professional sports team. “When any [sports] franchise hires a great talent, they offer him the best possible contract so that he doesn’t leave.” While that franchise may never win a championship, having talented players on the team gives it hope and keeps players motivated. “The same is the case with testing. If you have a tester who is very skilled and you put him on a same pay scale as some other tester and don’t provide opportunities to advance, you are asking for your star tester to leave.”
5. Too much focus on manual testing As if acknowledging some truth about statement no. 1, Sodhani says, “Manual testing doesn’t require too much technical skill. As long as you have willingness to break stuff, you will do fine.” But, as he explains with anecdotes from two former jobs, a little knowledge—in this case of test automation—can go a long way toward fulfillment. “In Job A, I was a load-test engineer with a manager knowledgeable about the [automation] tools I was using. He understood what I was talking about, we had great technical discussions and I learned a lot of things in the process. In Job B, the members of my team had hardly any automation background and were not interested in learning anything new. We were never able to focus on automation; it just kept being postponed.”
He was further frustrated by not being able to talk to anyone about technical issues. “No one talked about anything but family matters.” This high degree of repetitive, manual testing and stagnation “made me realize how important team members can be to job satisfaction.” Next week I’ll bring you Things I Hate About Testing numbers six through 10, starting with “Getting everything at the last moment.”
