Monday 1 December 2008

Testing Testing

Custom-written software obviously needs to be tested. But what's needed for software packages?

It's easy to assume that a package will have been thoroughly tested. Sadly it is rare for packaged software to be bug-free for three main reasons:

  1. It will be unlikely that the software will have been tested with your specific set of systems parameters.
  2. For new versions of software, authors are dependent on end-user "beta" sites that are prepared to test software before general release. The extent and depth of testing is dependent on the organisations involved, and restricted by the time they have available.
  3. Not all identified bugs will have been fixed. Are any significant to your business?

Examples of bugs that I've seen go live include:

  • Payment generation routine that didn't work. Cheques had to be raised by hand, and the delay meant some supplies were put on stop.
  • System set-up problem that resulted in changes being lost. Training sessions became farcical.

Therefore testing of at least the key functions is worthwhile. This also provides the opportunity to develop and test the associated manual procedures. Are instructions clear, concise and complete? Printing can be a problem - does it work as expected?

By collecting representative transactions during production of the User Requirements Specification, the suitability of the software to cover the range of business can be checked. This should include checking if and how to make changes, for example if a customer order has to be changed or corrected.

A testing plan that includes each process, such as product set-up and credit note production, helps to ensure the system will be fit for purpose once implemented.

No comments:

Post a Comment