One more note:
When I say ‘Obviously my job is harder’, I mean that only in the sense that creating an unbreakable thing is harder than breaking something. That is not to say that QA is a lesser job or that the pay should be less… on the contrary, QA is a difficult job. A skilled QA analyst must think outside the box and think of all the things a developer didn’t think of. After creating a viable, repeatable test plan, a QA analyst must perform the rather monotonous task of acting out that test plan. At a 3-1 Dev-QA ratio, I think a Senior QA analyst is worth the same price as a Senior Developer.
the trouble is… nobody likes someone saying their app is shit. even when it is.
It is tough when a dream meets reality. As another commentor said I’ve had good relationship with testers and actually started looking at writing stuff with minimal bugs as a challenge…wish I could win
I’ve been testing for nearly 6 years. For equivalent seniority, pay is somewhat less, but I’m pulling in over 80k. Respect is always an issue, and timelines are always a problem. I will fight like a wild cat if a PM tries to compress my timeline, because inevitably I will be blamed, whether implicitly or directly, for defects in production. On the other hand, I do my best to befriend developers. Still, sometimes their egos get the best of them, and I’ll show my pimp hand so they dont think they can roll me over. The job can actually require quite a lot of creativity and latitude, but it has so many drawbacks that I just can’t seem to learn to enjoy it. There is endemic disrespect for someone who doesn’t produce anything tangible besides what is perceived as friction in the project plan. What’s that saying, credit the developer, debit the tester? It’s true. I have worked my NUTS off to get a build out that had virtually zero defects, and barely got a “thanks”, but I’ve missed monster bugs before and been fried on a pan for it. It just doesn’t add up. That’s why I make a point to thank my junior testers every chance I get. Most PMs and execs are slaves to the timeline, and most of the ones I’ve worked for a clueless about the value QA brings. Just today I had a spat with a developer over my desire to delay our release by 5 days so I could finish my job correctly. I’ve warned my PM a dozen times about the risks - but it just doesn’t seem to sink in. Basically, I have to show up and pretend to be a team player, but I’ve grown to absolutely detest my job. I can write circles in SQL around most of the people I work with, but the future feels bleak right now - QA entombed, I fear. I need another job, I’m burnt out and getting too uppity.
Garret, when you say ‘Obviously my job is harder,’ I don’t know whether to laugh or to cry. Can you see that from a macro view it’s a sad state of affairs that something “a developer worked so hard on” can be “broken with such ease” by a tester (your assertion; my quotes)?
Having been a developer in a previous life (deadLanguage=COBOL), I have developed a sense that the real issue is what I call “Happy-path Development™” wherein all elements conspire to allow time only to program/unit-test the ‘here’s what it does’ requirements with no time left for anticipating ‘stupid user tricks’ and other lethal corner cases. Obviously we need to all hang together on this or we’re likely to all hang separately.
At any rate, should the opportunity present itself you should consider taking a ‘walk on the wild (tester) side;’ you’ll learn the joy of trying to prove to upper management that, “there are no needles in this haystack.”
Early in my career I had the pleasure of working with two dynamite testers. These ladies could break a rock-solid application in a matter of minutes, and as a result forced me to become a much better (and slightly more humble) coder.
Professional testers rock, but they are very hard to find!
Whilst I generally agree, there are some cases where developers make excellent testers, and those cases tend to be related to security issues.
For instance, lets take a web-application. A non-technical tester is probably not going to try XSS, SQL injection attacks or hack around with the query string or edit hidden fields. As a developer you often have a good idea what the weak spots of an application are - the buttons that can be pushed to crash it. Whenever I see a query string I just can’t help hacking it! “Ummm, so there are ten pages of search results - what happens if I change ?page=10 to ?page=11 or ?page=ABC?”.
You might say this is the job of a specialised security consultant, but many small firms can’t afford that luxury. That is where developers knowledge comes in handy to compliment other test paths.
Maybe I’m an unusual case, but I am a developer that does quite well at testing. Now to be fair, I am not the best developer out there, but I can develop my way out of a wet paper bag.
As a developer, when I was testing a bug fix I had just implemented, I would typically find 2 to 3 more bugs. That happened pretty much ever bug fix. My managers saw this and decided I would be better off in the QA department and I felt the same way.
Maybe the statement: “Great developers make bad testers” is better. I suspect that even great developers could make great testers too, they just don’t feel it’s worth their time to do both. That may be a true statement, but in the age of TDD, developers (good or bad) need to become great testers too.
