Developers Aren’t Really Testing

In my fifteen plus years as a software tester, I’ve had the pleasure of working with some great and talented developers.  The large majority of them have sat down with me and gone over issues and code; searching for the root of the bugs that were preventing us from getting some crucial feature out the door.  There were, of course, some who simply deemed that sort of thing ‘a job for QA’ and wanted nothing to do with such mundane tasks.  “After all,” they would say, “it works fine on my machine.”

Those developers hold a special place in my heart.

Really.

It’s because of them and the attitude they had, I believe, that have made me into a better software tester.  I had to, on my own, figure things out and learn what the code was actually doing.  When I would approach them with my findings showing where their code was broken, you would think I had earned the right to be as condescending as they were to me.  But no, a war with a developer was not the best thing for my career or the project.  It was enough that I walked away with some new learned skill about software development.

Not to say that I haven’t been tempted one or two times.  Remember that scene with the Chocolate Pie in the movie, The Help?  I totally identified with Octavia Spencer’s character.

It was also good to know more about the developers.  Over time, I would become accustom to finding bugs quicker when I knew which developer coded which feature.  Programmer A, for example, always had issues with getting shell scripts to work properly while Programmer B would be notorious for using beta libraries in his code and therefore not deployable on production machines.

When it comes to actually testing the software, however, even the best developers aren’t really testing.

They’re checking.

Developers code software to perform specific tasks.  Once they’ve written the code, for the most part, they confirm that the code, on its own, performs said task.  They check it. Once they know that the code does what it’s supposed to, they move and code some other task.  Once they’ve completed all the tasks, they’ll check-in the code and somehow deliver the code to QA for testing; confident it does what it’s supposed to.

We (the software tester) may check the code as well, but we’re also testing it.  We make sure that it not only does what it’s supposed to do, but ensure that it doesn’t do anything else.  We test to see how well it does perform, how fast, how slow.  We expose the breaks, the errors that aren’t handled, and the paths the software was never supposed to take but somehow does.

We’re testing.

I think the best response to finding a bug I’ve ever gotten from a developer is, “How in the hell did you find this bug?”

Praise indeed