Introduction Top-down and bottom-up development

138 Chapter 6 n Software development n Integration testing – of sub-systems and the system as it is drawn together. Do the components of the system interact correctly? n System testing – this is the final testing of the complete system against the specification and possibly the user manual. n Acceptance testing – by the userclient with or without you present. They will be inter- ested in how the system operates in its live environment, with real data and performing in real time under normal working pressures. n Regression testing – involves testing the system after you have made significant changes to ensure that new bugs, not present in previously working parts of the system, have not crept in as a consequence of the change. Regression testing is particularly important when working on group projects where individual members of the team are developing different parts of the system. It is important to ensure that, as components are integrated and members of the team work on different parts of the system perhaps not understanding how other programmers imple- mented certain parts of the system, new errors are not introduced andor old bugs are not reintroduced. You should test your code both statically and dynamically. Static testing does not involve running the program but inspecting the code either on screen or a printed copy or the designs, specifications or other documentation for example, the user manual. This technique can be used to assess the content and level of comments in a program, the scope and declaration of variables, the overall structure of the program, how the program matches the design and the layout of the code have you used tabs to indent statements, line breaks to separate different sections of the program?. Dynamic testing involves running the program in order to identify any errors. In large software developments, dynamic testing involves white-box and black-box testing. White-box testing means you know how the code is programmed and structured so that you can test out potentially error-prone parts of the system. Black-box testing means that you only know what the program is supposed to do, not how it is pro- grammed to do it. For your own program testing you will be undertaking white-box testing as you know how the program is structured. However, you may wish to involve others in black-box testing of your software if you feel this is appropriate. Some useful tips for dynamic testing are presented below. n Create appropriate test data sets. Try to create test data for your program that includes both extreme values and normal data. It may also be appropriate to gener- ate test data that includes ‘bad’ data – i.e., data that the program would not normally be expected to handle for example, text data instead of numeric data. How does your program cope with this? Does it need to deal with extremes or bad data, or can these anomalies be ignored is the user ever likely to enter something like this?? Your test data should include boundary values and equivalence partitioning can be used to minimise the size of test data sets. Boundary values are input values at the bound- aries of what the system is expecting. For example, if the system is expecting an input between 1 and 10, the test data should include 0, 1, 10 and 11, as well as a number in between 5, for example. Equivalence partitioning splits the test data into categories whatever might be appropriate that represent different aspects of the data. You then need only test the program with one sample from each category rather than all the data. 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