Validation Verification, validation and testing

142 Chapter 6 n Software development n Recovery testing. Because your system may be handling inconsistent or error-prone data it may be important that your system is robust and does not crash when it encounters such problems. Recovery testing involves testing how well the program recovers from ‘bad’ data, an overflow, a crash, etc. You can test your system in this way by generating ‘bad’ data that can be used during testing. n Documentation testing. Your clientuser may have requested comprehensive documentation to support your software and this may be assessed as part of your overall project mark. Documentation testing involves evaluating how good the supporting documentation is for your system. This can be performed by users, non- expert assessors naïve testers, the client, yourself and experts. It can be performed off-line i.e., assessed without the software system to hand, in which case you will be checking for things like readability, layout and clarity or on-line assessed with the program to hand. During on-line testing you will be assessing how well the documentation supports the user in using the system: Do any tutorials match the program?; Is help available if things go wrong?; etc. n Interface testing. This is particularly important in web development projects in which the user can be very critical of the overall look and feel of the site and has many other web sites with which to compare it. The home page of a web site is effectively the site as far as the user is concerned so getting this right is important. Interface testing also checks whether the system is usable from a functional perspective. The system you have developed may perform some quite complex, interesting functions, but if the interface is clumsy, difficult to use, or not intuitive it may well put the user off. You should consider reading guidelines on HCI Human-Computer Interaction principles when designing your system to ensure it is user-friendly and accessible. •

6.13 Quality

6.13.1 Introduction

In Chapter 4 we introduced a generic model of the project process and showed that any product produced by a project will have a certain level of scope and quality see Figure 4.1. Although scope what the product does, its functionality, capability, etc. has been defined separately, it is sometimes subsumed within the concept of quality – being one of the aspects that define a quality product. In student projects quality can refer to a number of things – the quality of the report content and presentation, the quality of the underlying research, the quality of the contribution the project has made, the quality of a software system devel- oped, etc. While the quality of your project is assessed by the examiners and measured by the mark you receive, in this section we focus on software quality and how software devel- opment projects control and manage quality. To begin this discussion we need to determine what is meant by software quality as it means different things to different people. 6.13.2 What is software quality? The first point to note is that a high-quality product might not necessarily be appropriate for our needs. For example, a small system with limited functionality may provide just the functionality a user needs, while a more complex system with lots of ‘bells and whistles’, although doing what a user requires, might be so complicated as to make it unworkable.