That Blue Square Thing

Applied ICT A Level Unit 10 - Advanced Spreadsheets

Note: this page applies to the AQA Applied ICT A level specification. This exam was withdrawn in 2012, with final exams in 2013. The content will be retained as an archive and because it has some stuff that might be quite useful for someone or other

Circuit board imageSection F - Test Plans:

You need to plan how to test:

In the exam you'll then actually carry out these tests - covered by Row G of the markgrid. What's clever is that some of the marks in Row G can't be got unless you've done Row F properly.

Part of the prep work needs to be to create data sets which will allow you to test the elements of the spreadsheet. This means you have to clearly specify what data you're going to enter in the cells of the sheet - the examples show this. Some of this data will need to "provoke failure" - i.e. try to 'break' the spreadsheet.

PDF iconExample test plan showing a possible layout. Note that you'd almost certainly want to link this to some screenshots. You might not need a screenshot for every test - one might allow you to demonstrate several tests if you think about it carefully

PDF iconExample whole system test (also known as integration testing - but nothing to do with mathematical integration I'm pleased to say). You'd want several whole system test cases to test a range of possibilities

Note that you can take sheets like these into the exam to evidence Row F. You could then take second copies in to evidence Row G - but you'd have to hand write the test results and comments etc... as you aren't able to take any electronic files in to the exam

Expected, Extreme and Erroneous:

Row G is clear that it wants you to have tested all three types of data input. But what do they mean?

Expected input (or normal input) is a standard value which you would expect the system to accept. It's perfectly reasonable for me to order 3 cakes, or buy 10 packets of biscuits for example.

Extreme input is a value at the edges of what is allowable. I can order 1 cake or, depending on the client needs analysis, up to 20 cakes, so I'd better test these values as well - the extreme values. These are sometimes known as Boundary Values. I could also test the next step across the boundary - if the system should accept up to 20 cakes then I should test 20 and 21. One should be accepted, one shouldn't.

Erroneous input values are simply wrong - things that I should never be allowed to enter. So, I shouldn't be able to order minus 4 cakes. Or 3.142 cakes (that's not a cake, it's a pi...<groan>). Or "red" cakes. If I do any of this I should get an error message - preferably a helpful one that you've customised to say something helpful to me.

Note that a lot of the time you're testing validation rules.

Entry values for things like names and addresses are difficult (or often impossible) to validate, but you can still test that whatever value the user enters is copied into the appropriate cells on the other sheets and so on.

The Markgrid:

You'll also want to look at the markgrid for Row G as well - the testing during the exam.

Markgrid Row F
Note: this markscheme is a copy of one which was available freely on the AQA Applied ICT webpages. It is copyright AQA and reproduced here simply to make access easier for students. No attempt to claim copyright is being made, although I could have copied the text into my own interpretation...