1. Testing E001 Access to Computing: Programming

2. 2 Introduction This presentation is designed to show you the importance of testing, and how it is used by software developers It is also designed to support you in preparing your portfolio.

3. 3 Testing and your Portfolio In your portfolio: Make sure your programs have been tested properly eg Use different types and values of input within the program stated range What sort of input validation should we consider? numeric? integer or float, + or -, within range, character? range, upper or lower case, max number of characters Yes/No? Yes, yes, Y etc Good testing will consider a range of conditions.

4. 4 Testing is Important! Programmers are human – they misunderstand users’ requirements and make mistakes, so almost all programs contain “bugs” (errors) Testing is an important task, to remove as many bugs as possible It is not unusual for developers to spend 40% of total project time on testing For critical software such as airline flight control, testing can cost 3 to 5 times as much as the rest of the project.

5. 5 The Purpose of Testing The purpose of testing is to find bugs, and a successful test is one that finds a new bug It is impossible to test everything - testing aims to systematically find as many bugs as possible in the shortest time Effective testing also shows that the software is working as stated in the original specifications Testing needs to be carefully thought out to achieve this In commercial situations it is important to test processing speed for high volumes.

6. 6 Test Plan The test plan for a big software development project is a major document, describing the approach and purpose of the testing work Writing a test plan provides a useful way to think through what is required - sometimes when the test plan is developed, problems are found with the requirements or design of an application A project test plan contains a series of test cases, to check how the application copes with different inputs (see example) The test plan contains tables to show which test cases check which requirements In this course you do not need to produce a full test plan. You are asked to “Write a brief explanation of how your program has been tested and show sample runs”.

7. 7 Handling Bugs In large projects, a reporting process ensures that testers, developers and project managers are kept informed of bugs and fixes Whatever the size of the system, after a bug is fixed, the system should be retested There is a danger that fixing one bug can create a new bug in a different part of the system! What is a Heisenbug? (Use google to findout) If we test a program in a given situation with a given input (or no input) and it works first time, is that sufficient? (see lottery example)

8. 8 Two Kinds of Testing White box (or glass box) testing is designed by looking at the program code. The task is to create test data to check every logically possible path through the program Black box testing assumes the program logic is unknown. The task is to create test data for every possible kind of input, and show that the desired output is produced If the details of the program code are known, then both types of testing are used

9. 9 Black Box Testing for Database Queries Input Output Program Imagine you are testing someone else’s program and you cannot see what code they have written You have to check that the input always gives the correct output for every possible kind ofinput.

10. 10 Designing Test Data Output we expect: It is easy to create test data which should produce a partcicular in output Output we do not expect: We also have to think of other input data which could accidentally result in unwanted output (Have you heard of the system that kept sending out bills for £0.00? Nobody had thought of testing it with data for customers who owed nothing!) PostCodes are normally AANN N AA but are there exceptions? We need to notice the boundaries between data that should produce one output, and data that should produce a different output. These boundaries must be tested carefully. Some programs have no input but may need to be tested

11. 11 Boundary Value Testing The most common boundary conditions are concerned with dates Suppose we want to test the following query for a Film Club scenario Find all films showing between 3 April 2004 and 25 April 2004 The boundaries are 3 April and 25 April In our testing, we will check that films showing on 3 and 25 April are included in the output We also need to be sure that films showing on 2 April and 26 April are not included in the output Other boundary conditions should be tested in a similar way.

12. 12 Releasing Software and Version Control After programmers have tested their part of a project the programs are normally the tested by others internally (This is usually called an Alpha release) When most bugs are fixed the package may be offered to selected external customers (early adopters) with no guarantee of operation. Feedback is expected. (Why would these users participate?) –(Usually called a Beta release) After further modifications based on feedback a full first release is made available (may still have a list of known bugs or limitations) –(Why would a software house do this?) Version numbers usually indicate minor or major revisions of later releases. E.g. v1.0, v1.1 may have minor differences. V2.0 may have major differences and may have no backward compatability with v1.x

13. 13 Key points to remember Testing is important and time-consuming Most programs have bugs – the challenge is to find them Try to test your program as if someone else wrote it and you can’t see the code Test boundary conditions with care.

14. End of Lecture