The Programmers’ Revolt

A green sea turtle swims past a school of Raccoon Butterflyfish near Hawaii.

Every once in a while, something happens in life that makes you say, “enough!”

That happened a couple of weeks ago to me and a couple other programmers working on the same project that I’m working on.

The issue was that we had made some significant changes to a project, we had communicated to the project manager that the changes required that the entire project needed to be retested, but the testing never happened.  So of course we spent the next several days doing the “testing” and fixing.

This scenario should resonate with just about every programmer that reads this blog, but it should raise some questions as well.

The chief question that has to be raised is, “Why didn’t the programmers test the application?”  There are two reasons.  The first is, we never felt like we had been given time to test.  The second is that we don’t really feel like we understand exactly what the system is supposed to do.

But by not testing at all, the programmers are the ones who pay.  And that’s why the revolt took place.  We all came to the conclusion independently that since no one else is doing a complete test of the system before it goes to production each week (yes, we make weekly changes) the people who suffer the most are the programmers.  Therefore, it makes sense for us to start creating tests for this system that we run the application through prior to calling it “done.”  That is, testing is part of programming, not an extra step that we need to have time allocated for or that someone else should be doing.

So we’ve made testing part of the task of programming.  It isn’t as glamorous as coding and we won’t catch anything, but catching nothing is better than not even trying.  As new bugs surface we will add those conditions to our plan.

Of course, now that we’ve caught on to the testing religion, we need some tools to help us manage things.  The last time I implemented testing, I was using Test Complete.  This tool allows you to record tests to a script file and then modify the script and play it back.  It’s a pretty good tool.  The only problem is, you have to learn a new scripting environment and it is pretty expensive.  I also find the process of creating scripts tedious.  Many times you don’t know how to automate  something until you’ve repeated the steps several times so that you can see the commonality of what you are doing each time.

So what we really need to start with is a tool that just allows us to organize and record what needs testing.  This is called a test scenario.  I searched for a free tool and ended up at the xqual.com site where I found a free java application that is basically a project management system with testing as its center.  You should check it out.

As I started thinking through the tests that we needed to run immediately, I realized that one thing we really needed immediately was some way of spidering the site and making sure we don’t end up at a 404 or 500 error page.  I had been using iMacros for web process automation, but as a testing platform it falls a bit shy of what we need.

Then I found Selenium, which is a framework for building automated tests in several different environments, including Visual Studio’s MS-Test or NUnit.  It didn’t take me long after that to find an NUnit test for Selenium that spiders the web application and makes sure you don’t end up on a 500 error page.  I will be embellishing this over time so that it checks each page it lands on for things that must be true on every page.

So now we’ve got something in place that we can add to over time.  It’s not perfect, but it is something.

Related Post

  • Pingback: Tweets that mention The Programmers’ Revolt -- Topsy.com

  • http://www.howtobin.com John

    All the best, I hope something significant comes out of your revolt, so that other programmers also get benefit from this.

  • http://www.purefx.co.uk Pete @ Pure FX

    Hi,

    So are you testing in your spare time, or have you integrated the extra work into your daily routine? If the former, that’s outrageous!

    Pete @ Pure FX

    • Dave

      What spare time?

      It is totally integrated. Testing is as much a part of writing the program as writing the code is, especially when you can run “idiot test” that capture 99% of what the end user is going to find while you are writing code.

      • http://www.purefx.co.uk Pete @ Pure FX

        Hi,

        Ha. I meant – you know – outside work. But perhaps outside is just a distant memory. : P

        Thanks!

        Pete @ Pure FX

  • http://jamespeckham.com James Peckham

    “It isn’t as glamorous as coding” — You wouldn’t believe how much tail i get from being a programmer.

    “we don’t really feel like we understand exactly what the system is supposed to do” — Seriously or sarcasm? Have you tried talking to a customer before you wrote the code?

    • Dave

      James,

      I can’t go into the details here but let’s leave it at 1) we didn’t write the code, but were asked to maintain it, 2) there is more than one company working on the code base for this client (their choice) and 3) they don’t want to “spend the time.”

      This is the second time I’ve HAD to work on a system with no specs if I wanted to get paid. No it’s not ideal. But WHEN that happens, the next best thing is writing test as things are discovered.

      I admire that you work in an ideal world. I don’t.