Test plans Miscellaneous testing types

6.16 Exercises 145 •

6.14 Summary

This chapter has introduced the following topics: n software development processes; n the generic software development life cycle; n the original build-and-fix model; n the conventional stage-wise and waterfall models; n the incremental model; n prototyping models – throw-away and evolutionary; n choosing an appropriate development approach for your own project; n top-down and bottom-up development; n verification, validation and testing your software; n software quality. •

6.15 Further reading

Davis, A.M. Bersoff, E.H. and Comer, E.R. 1988 ‘A strategy for comparing alternative software development life cycle models’, IEEE Transactions on Software Engineering, Vol 14 10, pp. 1453–1461. Hughes, R. and Cotterell, M. 2006 Software project management 4 th Edition, McGraw-Hill, London. Turner, J.R. 1993 The handbook of project-based management, McGraw Hill, Maidenhead, UK. •

6.16 Exercises

1. What development approach would be suitable in the following cases? i. You are undertaking a project that has been specified quite precisely by your project supervisor. The project requires you to develop a software system, written in C, to solve a problem specified by your supervisor. You will meet your supervisor every one or two weeks to discuss progress. ii. You are undertaking a research-oriented project that involves the development of a new algorithm to solve a particular mathematical problem. When you complete your project you will be expected to present a software system that incorporates this algorithm and illustrates how it works. iii. You are developing a multimedia DVD for a business client that will be used as a marketing device to ‘sell’ that company’s products to potential customers. iv. You are developing a web site for a local sports club.

2. Given the following simple software specification, produce a set of test cases for

the resulting software system. What kind of testing would you undertake for this? 146 Chapter 6 n Software development The system must convert Celsius into Fahrenheit temperatures. The user should enter a numeric value representing the temperature in °C and the system should respond with the equivalent temperature in Fahrenheit.

3. Identify any omissions in the simple specification above.

•

6.17 Action points

n Choose an appropriate development approach for your own project. If you are al- ready pursuing your project, is your approach appropriate in light of what you have learnt from this chapter? n Justify why you have chosen the development approach you are using in your own project. n Think about how you will evaluate your chosen development approach at the end of your project. n Put together a test plan for your own project and discuss its content with your super- visor. Have you gone into too much or insufficient detail? n Think about how you will be evaluating your system towards the end of your project. Check that you have allocated sufficient time for this evaluation in your project plan and confirm that you have access to the right people to test your software when the time comes. • Solutions to selected exercises

1. i.

As this project is quite clearly specified and you will be having regular meetings with your client your supervisor, a conventional waterfall-type development approach could be used here. Alternatively, if the system can be broken down into a series of sub-systems, you might consider an incremental approach, adding components of the functionality as the project progresses and discussing these with your supervisor. ii. An experimental prototype would be suitable in this case to explore any feasible ideas you have and how these might be implemented. This might be written in a 3GL such as C, C++, Pascal or Fortran. This prototype may well be discarded, when you are satisfied that the algorithm works, and the final system can then be developed in a more graphical language for example, Visual C++™ so that a user-friendly front end can be developed for the system. iii. An evolutionary prototype would be suitable in this case as the requirements are quite broad and the technology may be new to you. iv. Evolutionary prototyping would be suitable in this case. The technicalities of the project are fairly basic but the user-interaction issues are paramount. Alternatively, you might wish to develop two or three throw-away prototypes at the project’s outset using an alternative platform from the final system for example, page mock-ups in a drawing package to provide the client with Solutions to selected exercises 147 some different interface ideas. Having chosen a suitable interface you could then move onto an evolutionary approach to develop the final system.

2. As you do not know how the code was written, this is black-box testing; you only

know the overall functionality of the software. You should therefore run the pro- gram to test it with a test set of input values. During these tests, have you included tests for the following? n Do you test a number of ‘reasonable’ input values – for example, 0, 10, 100, –1, –10, –200? Do these provide the correct results? n Do you test for extreme values – for example, values below –273.15, values above say 10,000? How should the system react in these cases? n Have you tested real and integer values? n Have you tested non-numeric data entry – for example characters or strings? n Have you tested the sensitivity of the system – for example, does 1.0 produce the same result as 1.000001? n Have you tested negative and positive values for both the input and the output?

3. If you were given this simple specification, there would still be a number of ques-

tions you would need to answer in terms of its implementation. You could make a number of assumptions yourself as to what is appropriate or you could return to the user for clarification. In some cases, the user may be happy to respond to these questions; in other cases they may be annoyed that you cannot make simple deci- sions for yourself – so tread carefully. Although we haven’t even touched on the interface for this system in this exam- ple which would throw up another series of questions, the following are things you would need to clarify: n How should the system deal with incorrect data for example, character input, data outside the acceptable range, etc.? n Should the system ask the user for another number after it has provided a result or should the program terminate? n Should the system end after an incorrect input, or should it allow the user to have another go? n If it allows the user another go, how many times should it allow this? n How should the results be displayed – for example, how many decimal places should be displayed? Should °F or Fahrenheit appear after the result? n What range of inputs should the system cope with? Does it need to provide a message to the user informing them of this? n How accuratesensitive should the system be? This largely depends on the sensitivity of the input data – so how many decimal places are allowed for the input data? It is worth noting that even a simple program specification such as this has a significant number of ambiguities or areas where clarification is needed. Imagine the number of questions that will arise from much larger specifications.