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

6.12 Verification, validation and testing 139 n Break points. Many compilers allow you to insert break points into a program before it is run alternatively you could code them in yourself. This allows you to run the program part-way and inspect the values of variables at certain points. If your program is crashing you can use break points to ‘home in’ on the guilty portion of code. n Dynamic data entry. You may wish to see how changes to variables affect your pro- gram’s performance. Some compilers allow you to stop programs and change the values of variables before continuing. Alternatively, you may wish to include some statements in your code that allow you to enter a variable’s value part way through the program. n Displaying variables and markers. You can add code to your program that informs you of the value of variables as the program is running and also how far the program has reached for example, printf“here1” or writeln“here2”. This can be useful in tracking down faults or determining just how far a program has reached before crashing. 6.12.5 Who is involved with testing and evaluation? Although you will be primarily involved with the testing of your own program, at some point you will need to get additional feedback on your program’s performance. Not only are you interested in whether you have identified and removed any bugs, but you will also be interested in whether the system meets the user’s needs, if the interface is appropriate, whether it flows logically, etc. You will need to get a number of people involved in the evaluation of your system and answer some of the following issues: n The users. Is there going to be just one user of the system or many? If there are many, can you get an appropriate cross-section of users to look at your program and assess it? Will you be present during testing known as alpha testing or will you leave it to them to feed back their thoughts to you beta testing? Will you have a structured system test with them where they look at specific parts of the system in order or will you allow them just to ‘play around’ with the system as they feel fit? Are there specific parts of the system you want them to focus on? Will you gather feedback from them formally, through a questionnaire or interview, or informally? n The client. Quite often the client and the users of a system are not the same. For example, you may have developed a multi-media sales DVD for a company. While the company is your client, it is their potential customers who will be the users. In this case, can you get access to any potential users of the system for evaluation? If the client is happy does this mean the user will be happy? If the client wants one thing but you feel know that the user requires something else, who should you attempt to satisfy? n Novice. It might be worth getting someone who is a complete novice in terms of both IT andor the problem area to look at your system. They may identify issues you had never considered. For example, simple things like your colour-scheme or interface might be inappropriate; your system’s data input may be illogical, etc. n Expert. Will you be able to get someone who is very familiar with the problem area or the type of system you are developing to evaluate it? They can be very useful in identifying technical issues with your system. For example, they may ask you if you 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