Not Testing Early, Often, or Correctly

Software Development Mistake # 7

Source:Offshore Software Success

Author: Richard

Testing is one of the most important, yet often overlooked activities on a software project. How the test process is handled can make or break a project.

Here are a few "golden rules" of software testing.

• Programmers can't test their own work. It is the same as proof reading a letter you write, you just don't see the mistakes that others find.
• All software has bugs, some are just not found yet. Some bugs have been found, but not worth fixing because they are minor annoyances that are hard to fix, or will very rarely be seen (we just end up calling those "features" ;-).
• In the process of fixing bugs, even the best programmers for hire can introduce new bugs.

  This is why a feature that worked in the last version may not work in a new version. Your test plan must account for this, it's a fact of life with software.

  It does not matter how simple the change was or what the programmer tells you, fixes introduce new bugs more often than not.

• The earlier a bug is found in the project cycle, the cheaper it is to fix. Here is an example:
  • John finds a missing feature while writing up his project description (one could argue this is a bug). To fix this, he simply adds another sentence or two to his description.

    That was easy!

  • Two months later, John finds that one feature has a bug that makes it cumbersome to use with another feature. Since both features are already coded, changes must be made to two places in the code.

    The changes will introduce new bugs and the code that was "done" will have to be changed again.

    That was somewhat painful.

  • Two months later, one of John's users finds another bug. Now the program is in production. There is "live data" managed by the program and the shipping department is totally dependent on the program for their operation.

    Now it is risky to make the fix, down time has to be scheduled, new freelance programmers may need to be hired, and they will need time to learn the original freelancer's unique programming quirks.

    Now it's really painful!
    

  As time passes, pain and expense to fix a bug increase.

  Lesson: Test early, test often, test everything!

  
  

• Testing is not as effective when done haphazardly. You really need to create a test plan and follow it for each version.

  Your test plan should focus on the most important features of the program.

  You should account for which areas of the program are changing with each release and which features are ready for testing for the first time. These areas should get most of your attention when testing preliminary versions.

• You need to track what you test. Keep notes as you test so you will be able to refer to them when a problem occurs.

  The most important thing to tell the programmer is what you did right before you saw a bug. This is very important in helping the programmer locate and correct issues.

  Bottom line: Test early, test often, test everything you can on every preliminary version, and keep a log of your testing.
  

That's it for the seven mistakes. I hope you won't be making any of those mistakes on your projects!

I'd really like to hear from you. If you don't mind, take a minute to fill out the Topic Suggestions Form telling me what you think of the Seven Mistakes series and what other topics you'd like to see covered in the future.