In today’s lesson we will be looking at: what we mean by the software development lifecycle the phases in the lifecycle We will focus particularly on testing: what’s in the testing phase of a project why we test software how we can test software Software Development Lifecycle

Implementation Evaluation Testing Design Analysis Software Development Life-cycle

Analysis The analysis phase of a project involves looking at what the user wants. You might consider: features required, including hardware, operating system, user interface, etc. performance criteria data flow – including links to other systems skill level of the users different levels of user – e.g. administrators appearance – e.g. use of logos, corporate colours, etc.

Design The design phase of a project involves thinking about how you are going to create the software. You might consider: which programming language you are going to use data structures or database tables required the layout of the screen any addition files required, e.g. images, data files, cookies, etc. calculations required algorithms required as pseudo-code or flow-charts the test plan or testing procedure

Implementation The implementation stage is actually making the software. In a commercial setting, the end result will be the product that’s finished ready for testing. Comments should be included in the code to make it easy to maintain. In an educational setting – e.g. for GCSE coursework – you may need to “write up” what you’ve done; i.e. a commentary on how you created your program and how it works.

Testing Why would you need to test anything that you make? to make sure that it meets the requirements of the end-user to make sure that it works correctly, and there aren’t any bugs Ideally, who would do the testing?

Testing The requirements can either be: Quantitative – things you can measure and say for sure whether they’ve been done, e.g. there must be 10 slides Qualitative – things that are subjective, or a matter of taste, e.g. it must be easy to use, it must respond quickly Quantitative things are usually easier to test for using a test plan, e.g. validation…

Testing Validation If you created a system that performs calculations or includes validation, how would you test it? Create a test plan including sample values to try: –Normal data – the types of values you would normally expect –Extreme (or boundary) data – values that are right on the edge of what is acceptable –Erroneous – values that should be rejected

Testing Validation For example, in a system that processed marks from students’ exams there is a field for you to enter the percentage scored in the test. What values should you try in your test plan? –0–0 –100 –Something in the middle – e.g. 50 –101 –-1 Would they be accepted or rejected?

Testing Your Spreadsheet Why could you test in your software? Does it include all of the things you said you’d include? Do all of the calculations, etc., work properly? Is it suitable for your audience: –Do the colours make it easy to read? –Does the sorting, etc., happen quickly enough? –How would you decide what “quickly enough” is?

Writing a Test Plan A test plan usually takes the form of a table that includes tests to check whether: everything that the user requested has been included the boxes, buttons, etc., are the right size and behave as expected the system works with a set of typical data The usual method is to describe and action and then what you’d expect to see happen. There should be enough detail for someone else to follow.

Test Plan Template If you use my template, then... Initial Control States is the section where you check that With spreadsheets, changing the value in one cell (or clicking a button) can make something change elsewhere – you test that this happens correctly in the Dependent Control States section System Testing – does the software all work together once you use some typical data (you could use the files provided)