Deciding How to Test Early, Twice

February 9, 2003 by
Filed under: Process, Quality 

To develop a software product, there are a couple of things you should do to help ensure it gets done as expected (actually, there are quite a few things you need to do, but this is a brief missive). You need to decide how to test early, and decide how to test early.

You need to [decide how to test], early in the game. Throughout the development lifecycle you reveal what the product should do, how it should be done, and so on. Each bit of information can be used to clarify the best approach for assessing whether the product is correct. Exposing bandwidth issues in a real-time system will inform you that you need to assess performance against the design. Identifying that the environment of data the product will be used in cannot be controlled will lead you to rigorous boundary testing of interfaces. Knowing that the end user is looking for an optimized work experience will drive you to business process analysis, thorough usability testing, or managed customer feedback.

There is immense value in deciding early (through test planning), rather than just coding the thing up, then figuring out what went wrong. First, it gets the whole team involved early, rather than waiting around for some code to test. Second, it gives you the lead time to build in a test infrastructure as required to facilitate the entire test workload. Third, it gives you the opportunity to correct changes throughout the lifecycle – to test early.

By deciding how to [test early], you ensure that you are capturing issues as soon as they are injected into the system. A critical best-practice in software (and elsewhere, for that matter) is to identify mistakes as quickly as possible after they have been injected into the system. We will make mistakes at all stages, but making a mistake early and finding it late is costly (I’ve seen companies take a product to beta and find out they developed the wrong thing, or only start to test their product when they hit ‘code complete’ – not good). Have you ever seen an application count down the time remaining on a long task, get close to completion, then jump back up to 30 minutes or so? Too many software projects appear to progress in the same manner.

Anything that is produced as part of a software project can be subject to scrutiny – specifications, designs and test plans as well as code. There are plenty of opportunities early in the product lifecycle to inspect, review, and test the system so that issues are found and resolved earlier in the cycle. It can be a fatal mistake to wait until you are 90% through your project to determine that you have 90% left – the costs in time, credibility and opportunity for not testing early are far too high.

Decide how to test early, and decide how to test early – the software equivalent to that old carpentry saying, “Measure twice, and cut once”. – JB

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


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    Jim is a true professional. His expertise in software development and project management is outstanding, but perhaps more important is his commitment to his clients and his own personal learning. Working with Jim is a pleasure for me – and will be beneficial for you.

    — Kevin Eikenberry, Owner, The Discian Group