For a myriad of reasons, software bugs are a fact of life. Among the contributing factors are: software environment, data, usage patterns, human error, complex usage, invalid usage and configuration. The aim with Infocouncil's projects is to have a minimum number of bugs in the software when the client starts to rely on it.
Infocouncil identifies and corrects as many critical bugs as possible prior to delivering the first cut of the software, by performing two types of testing.
The first type of testing is performed at a very low compartmentalized level. This testing involves the programmer examining the element that he or she has just created and checking that it performs as intended without obvious error. This is often referred to as 'unit testing'.
The second type of testing is performed across the entire scope of the software to be delivered. This is often deliberately performed by someone other than the original developer to mix usage styles and because it is difficult for developers to objectively test their own work. The focus of this testing is to reconcile the software back to the specification. This testing is intended to catch any obvious bugs or critical functional anomalies. This can be referred to as 'pre-delivery' testing.
Prior to relying on the software for 'live' usage, the client must be satisfied that what has been delivered meets the specification and is free of critical bugs. This process is called 'User Acceptance Testing'.
Overview of the User Acceptance Testing Process
User Acceptance Testing is typically performed in one or more iterations of the following steps:
- Infocouncil issues a release of the software
- The client performs (re-performs) as many tests as possible
- The client sends the issue register (explained in the following page) back to Infocouncil
- Infocouncil corrects the issues in order of priority
We expect two or three iterations of this process for the average software system.
The process stops when the client is satisfied that as many bugs have been found as can reasonably be expected. This is the point that the software moves from User Acceptance Testing to 'live'. Live means that the software is now being used by the intended user base and relied on.