Quality and Task-completion Checking

With development teams of two or three in daily contact and frequently exchanging views and criticisms, detailed, written quality and task-completion checking procedures may be felt to be unnecessary. Procedures do still need to be agreed and the results do need to be documented. The need to check quality and task completion applies at all stages of the development process but is underlined especially during the prototype validation stages.

The importance of documenting checks applies whatever the size of the team and whatever the complexity of the software. In the production of assets, this may involve checking to confirm the following:

• that all the asset files listed in the product specification document have been produced;
• that files are correctly named;
• that files are the correct byte size or near the projected file size (examining the file-sizes in a directory listing can be helpful in identifying problem files which are either much too large or much too small);
• that files are the correct resolution (screen-size and bit-depth in the case of graphics; duration, sampling frequency and bit-depth in the case of sound files);
• that the quality of files displaying on the target monitor or heard on target listening equipment is acceptable.

Note that sampling is seldom a satisfactory checking method. Checking should be exhaustive, unless for reasons of time or economy this is impossible. Usually, hopwever, trying to economise on checking and testing is a false economy and cutting corners here will often come back to haunt the development team. At the end of the day, all files will need to be tested and, if at all possible, this should be done sooner rather than at a later trialling stage.