Part 7 - Describe your approach to testing
In this part of developing a solution to a problem, you need to:
a) Identify the test data to be used during the iterative development and post development phases and justify the choice of this test data.
Things to consider doing:
a) Put a heading, Test data.
b) You should refer to Part 10 before writing your tests, as there are some requirements there that you could include in this section.
c) You should refer to the success criteria of Part 4. You will need to include tests to measure the degree of success of each item in the Requirements Specification using the success criteria you identified in Part 4.
d) You should refer to Section Part 12. You should include tests to judge the effectiveness of the useability of your system so that you can refer to it in Section Part 12 and you can do this in the User Tests you design.
e) Test plans should be written before the code is written. You therefore need to go through each of the modules of code you are going to write and decide how you are going to test them. What data are you going to use and why have you chosen that data?
f) You should discuss your approach to testing. You may also want to describe why you will draw up your test strategy and plan before you begin coding. In your discussion here, you should mention the need to test as you develop code (white box testing) and give some examples of the kinds of things you would test and the kinds of tests you would carry out. You should also discuss the need to test the final solution against the Requirements Specification (black box testing) and how you would go about doing this. The third part of this sub-section is to describe user testing, why you would carry it out and how you will go about this. You fourth area to consider is the need for acceptance testing; what it is and how you will carry it out. The test strategy is all about describing and justifying an overview to testing, a broad approach.
g) You should draw up four separate Test Plans, each done as a table.
Test Plan one will be Testing during development (white box testing). in a table, you should state what you will test, what data you will use, why you have chosen that data, what you expect the outcome to be and the results. There also needs to be a column for the page numbers of the evidence that the test has been carried out. You could plan to test some of your algorithms. You might want to fully test a couple of validation rules. Your teacher will advise you on the appropriate number of tests for your particular project.
Test Plan two will be Testing post development (black box testing). In a table, you should state each of your Requirement Specifications, the data you will use to test each one, why you choose that data, what you expect the outcome to be. There also needs to be a column for the page numbers of the evidence that the test has been carried out.
Test Plan three will be User testing. In a table, write down what you will ask your user to do, why you are asking him to do that test (what are you testing), what data you will use, why that data and what you expect the outcome to be. You are doing user testing to check that the user can use the system competently and get help when they get stuck. There also needs to be a column for the page numbers of the evidence that the test has been carried out.
Test Plan four will be Acceptance testing. At the end of the project, you need to agree with the user that it does what you both agreed it would in the Requirements Specification. The user will therefore need to carry out out the things identified in the Requirements Specification. If they are happy it all works, then they can sign it off. There also needs to be a column for the page numbers of the evidence that the test has been carried out.
h) You could also plan to do Acceptance testing as part of your User testing and have three tables instead of four. Your teacher can advise you on the best way forward for your particular project.