Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

The Perversity of Testing – I Lorve It

September 22nd, 2009 · 7 Comments

Exploring my Way to a New Career
I started getting into exploratory testing as a way of making my releases go better. I was a project manager in a big IT department and I wanted a cost-effective way of finding the bugs that mattered most as quickly as possible (I call these the “best bugs”). I learned testing so that I could teach my teams how to do it well, and I found that I could get business analysts reasonably decent at testing with about an hour of instruction and periodic coaching.

Later on I became even more disenchanted with corporate IT and project management and testing took on a different role in my career. It became my escape path. I could do it, and I could teach it, and I started to do both on the side. In my head, at least at first, I saw testing as my bridge back to development. Exploratory testing work would lead to automated testing work using Ruby/RSpec/Selenium, giving me credibility as a ruby dev, and eventually allowing me to convince some software company that I would make do as a ruby on rails developer.

Oddly enough, things didn’t really work out that way. Testing did get me out of corporate IT as I now work for a software company, but the majority of my responsibility still revolves around testing. And yet, the work I’ve done on the side with TroopTrack.com, for example, and even some on TriSano, makes me confident that I am at least respectable as a Rails developer.

So… why am I still testing? Why haven’t I moved on to my intended “final” destination?

The Perversity of the Testing Challenge
Testing is, in some ways, a perverse challenge. The job of a tester is to find and expose weaknesses in a product before they impact a user. This is a good thing, and it has an overall healthy effect for the product and it’s maker. At many levels, however, it’s a bit perverse.

Testing’s perversity is especially evident in the relationships between testers and others who work on the product. Take devs as an example – they often hate testers. Why? Because the tester’s spend all their time trying to find the ways the devs screwed up, publicize those mistakes (bug reports), and force them to fix the mistake. Imagine if your spouse did this with some aspect of your life – it wouldn’t make for a happy marriage and it doesn’t do much for relationships at work either.

Another perversity of testing is the happiness I feel when I find a bug. I get a bit excited as I try to isolate it to it’s simplest path of consistent repeatability. But… shouldn’t I be sad that a dev messed up? Shouldn’t I be a tad bit disappointed at the additional cost this mistake adds to our organization? Naturally, it’s good that the problem was found in time, but wouldn’t it be better if it never occurred at all? Of course it would, but… I’m still happy it happened.

Yet another perversity of testing is that I don’t really do anything about it. I’m not a bug hunter – I don’t find them, stalk them, and kill them (generally). I just find and stalk them. Someone else kills them, and then I check their pulse. This is a bit perverse in the sense that it’s kind of hypocritical, especially for a guy who can code. I’m more than happy to point out all the problems around me and then do nothing about them.

The last perversity of testing I’ll mention is the personal nature of my battle with devs (the fact that I call it a battle is perverse in itself – we’re on the same team). Testing software with the same devs for an extended period of time is kind of like playing chess, basketball, etc. against the same people. You learn their weaknesses and you try to exploit them. You know the types of mistakes they make and you adjust your test plan for them. When it works, there is a sense of glee at having bested them that is wholly unjustifiable. I gloat. I sit back in my $250,000 chair, stare at the screen, and gloat when I find a bug this way.

All this stuff is a bit sick and wrong, but I love it. I loooorrrrve it. It makes testing FUN. It turns it into a game full of intrigue, strategy, and execution. It motivates me to constantly improve, not so much for the good of the product and our company, but for the sheer perverse joy I find in finding bugs.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Uncategorized

7 responses so far ↓

  • 1 Alex // Sep 22, 2009 at 2:04 pm

    While I appreciate the sentiment and shared it on occasion, I prefer to test with the developers, as they code, so that their particular weaknesses are exposed immediately, and addressed, rather than introducing code with bugs in it. It will make the devs stronger coders, and will exercise your capabilities as well.

  • 2 davidray // Sep 22, 2009 at 2:11 pm

    Cool Alex. Do you mean pair programming or ? Can you tell me a little bit about the mechanics of this? How do you go about testing \”with the developers\”? What is it you actually do? I'm very interested in how you are doing this and would like to know more.

  • 3 Jim Hazen // Sep 22, 2009 at 3:19 pm

    In my opinion Testing is not done to make a developer look bad, but rather to help keep them from looking bad. Testing is the other side of the coin from development and we are working 'together' to produce a product. My job is to act as the 'second set of eyes' during the project. By starting to work with Development from day one you work in parallel and collaborate (communicate), thus you get better feedback loops going on and can reduce the rework costs during the project.
    Software is fluid and as such you will always have 'defects' in it. By working together in a collaborative and positive manner both sides of the team can minimize the impacts and get a good win.
    I wouldn't call this a perverse view of the work, but one that is reality of the situation. Developers may be the quarterback on the team, but Testing is the offensive line that protects them.

  • 4 Dennis Gorelik // Sep 22, 2009 at 3:32 pm

    David,

    1) It's very good that you love what you do.
    Are you sure that developers are offended in any way when you find bugs in their code?
    They should be thankful.

    2) Still, wouldn't you like development more than testing?

    3) Yes, some pair programming with developer would help you to find bugs better.
    Another way to find bugs is code review of the changes your developers made.
    Just go into your source control, get history of code changes, and view the diffs. That's very insightful. Sometimes you would find bugs by simply looking into code.
    And don't be ashamed to ask developers what they meant by the code they introduce.

  • 5 davidray // Sep 22, 2009 at 8:03 pm

    1) The devs I work with are not offended when I find bugs. They sometimes feel stupid about the bugs I find, but that's not the same thing. Other devs I've know in the past are a different story.
    2) I like them both. It's fun to balance them out a bit. I do a lot of hobby-coding (trooptrack.com) and I like it too. But it doesn't have the guilty pleasures of attacking someone else's work product the way testing does.
    3) Yup.

  • 6 Geordie Keitt // Sep 30, 2009 at 7:21 pm

    Right on, Jim. We are the holder to their kicker, the long snapper to their punter. The catcher to their pitcher. The Rodman to their Jordan. We are the mayonnaise on their BLT.

  • 7 davidray // Sep 30, 2009 at 8:20 pm

    C'mon Jim. Don't you ever find a bug in the work of someone who is a friend of yours and think "Hah – this is such a stupid bug I can't _wait_ to tease Mac about it"?

    I agree with your assertion that testing is good for the team, but I'm also acknowledging that finding bugs is fun, partly because sometimes the bugs you find embarrass your buddies.

Leave a Comment