Verification Verification, validation and testing

6.12 Verification, validation and testing 141 Section Test Input Expected Result Actual Result Comment Main Menu All option buttons Correct sub-menu selected Correct Data Entry Back button Return to Main Menu Fault – jumps to splash entry screen Corrected – 250409 File selection Selects appropriate file and displays on screen File selected but also shows file directory User happy with file directory being displayed Selecting sub-set of data for processing – out-of-range selection Error message showing user incorrect range selected Correct Select appropriate sub-set of data Correct sub-set identified for analysis Correct Data Analysis Select either long- or short- term analysis Correct analysis selected Incorrect – both options go to long-term analysis Corrected – 250409 Data Analysis – Long-term Process data correctly on long- term forecast Calculates suitable long- term results Works for periods up to 99 years User needs 50 years so this is acceptable Table 6.4 Example of a system test plan encounter after its release or does the system crash or take too long to process the data? Volume testing is used to assess the ability of a system to deal with large quan- tities of data. Even if you don’t have a large, real data set available for testing, you could soon generate a test data set using a spreadsheet, a text editor or a simple program you write specifically for that purpose. n Usability testing. The interface to your system may be particularly important – for example, if you were developing a system to be used by partially sighted users. Usability testing focuses testing more on how easy the system is to learn and use rather than whether it is fully functional. n Installability. Your system may have been developed to run on different platforms – Macintosh, Unix or PC-based systems for example, a multimedia DVD. Installability involves testing your program to see how easily it can be installed and run by users on their own systems. 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.