Bottom-up development Top-down and bottom-up development

140 Chapter 6 n Software development have anticipated particular inputs occurring or whether your system can handle rare events that you had not thought of. n Your supervisor. Is it appropriate to involve your supervisor in the assessment of your system? n You. There are some drawbacks to testing your system yourself. You know how the system works and may not test it with data you know it cannot handle because you could not imagine anyone being so stupid as to enter such data. You may steer away from parts of the system you know to be weak consciously or subconsciously. However, it is up to you to evaluate certain parts of the system – particularly the validation of your system as noted in the previous section. As you can see, a number of people can be drawn in to the evaluation of your system. You should ensure that you select an appropriate sub-set of these and be able to justify why you did not test the system with a certain group. For example, your examiners would be keen to know why you didn’t get your multimedia DVD evaluated by poten- tial users and only tested it on friends from your course. All this evaluation will take time. You must make sure that when you plan your project you allow sufficient time for this evaluation to take place. Your project would be significantly weakened if such an evaluation did not take place.

6.12.6 Test plans

As part of your development you may well want to put together a test plan. This will identify what aspects of your program you are going to test, what inputs you are going to make, how you expect your system to perform and how it actually performs. You would also use test plans to separate out testing the functionality of the system i.e., does the application behave as the clientuser intended – validation from testing for errorsbugs for example, if I enter this value, does the software deal with it appropriately?. Table 6.4 presents an example test plan for a student project. It is based on the simple project outline in Figure 6.7. This test plan shows that you have put some thought into your system’s evaluation, the aspects that you feel are important, and not merely tested it ‘on the fly’ as the program developed. The test plan shown in Table 6.4 may have too much or too little detail for your own purposes. For example, the tests for Data Analysis – Long-term are rather broad. You may want to identify specific periods, test data or selections within this. This test planning is more useful if you have designed it from the start of your development when the system requirements were drawn up. If you design your test plan at an early stage you are more likely to test that the system is doing what the user wants it to do rather than designing the tests to match what you have actually developed.

6.12.7 Miscellaneous testing types

The nature of your project may dictate that other factors are important and require addi- tional types of testing: n Volume testing. Will your system be handling large quantities of data or processing lots of numbers? Your program may work well during testing with a small data set, producing the correct results, but can it cope with the larger data sets that it might 6.12 Verification, validation and testing 141