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!

Comments

Feel free to leave a comment...





  • Search by Topic

  • What’s Happening

    September 15, 2016: Thanks to the Vancouver chapter of the IIBA for inviting me to present a talk about Real Analysis agility - the bottom line is thoughtful application of effective analysis over Cargo Cult application of the latest fashionable approach! - fabulous interaction, great feedback!
    November, 2016 - A workshop series to help you develop resilience in the workplace and in your life!
    Next open enrolment sessions start soon - contact us to get involved!
  • 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:

    • March 1-3, 2017 - Winnipeg, MB
    • March 6-8, 2017 - Edmonton, AB
    • March 15-17, 2017 - Victoria, BC
  • What People are Saying

    I learned a lot from Jim, and will always be grateful to have had him as instructor and client. Jim’s class lectures reflect how knowledgeable and well rounded he is – as a person, software developer, and project manager. As a client, Jim is great because he understands the issues that obscure most projects. He made sure we both achieved our goals. It will always be a pleasure working with him.

    — Donabel Santos