Deciding How to Test Early, Twice
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