Normal, Extreme and Erroneous

And that's just the usual Year 13 class...

So, this is about testing and test plans.

When you create them - and this applies equally for unit 10 (spreadsheets) and unit 3 (databases) you need sets of test data. That means data you want to use to test that your system works properly and check that it gives you the expected results.

You need to be really clear about the data you're going to use - that means I expect to see precisely what you're going to input - 10 in that box, Blue in that option and so on.

Now, the data needs to include 3 types:

• Normal - this is data which you would expect. Standard data that the system should accept without any problems
• Extreme - this is data at the extreme range of acceptable. You sometimes see this called 'boundary values'. You need to test each side of the boundary - so if a data value should accept values from 1-9 then I'd expect to see 9 and 10 being tested; if it has to be a maximum length then I'd expect testing at that length and one above the length and so on
• Erroneous - this is data which is clearly wrong - data which should never be accepted by the system. You want the system to reject this data. So, if I wanted a value 1-9 then I'd test things like 14, 473535, -1, 0, 4.5 and red.

OK?

Testing and Test Plans and Tests and other duck stuff

Ooh, I love a test. Especially in the Unit 10 spreadsheet exam

There are 12 marks (out of 70...) for testing and test plans - so they're important! It's rows f and g of the markscheme you need to consider: row f is in the prep work; row g is in the exam.

1. Plan first:

a) You need (second row of f):

• a plan which shows how you will test each individual element of the spreadsheet. This means each time data is entered, a button pressed, an option chosen or a spinner or tick box or something clicked.
• this plan needs to be in a sensible order
• it needs to say what you're going to do, what data (precisely) you're going to test the spreadsheet with, and what exactly the expected output is (bear in mind, doing something on one worksheet might have an impact on several worksheets)

b) Then you need (first row of f):

• a plan for the whole system - i.e. taking a series of clients through the spreadsheet from start to finish as if they were doing it for real
• this needs to include the expected output as well
• there must be sets of test data (second mark requires this)

2. Do the Tests

For row g all you do is actually follow the test plan through and provide evidence of doing so. It's important in this bit to show whether or not the actual outcome is what you expected it to be.

This means for both parts of the test plan - the individual testing elements and the whole system testing

Here's a hint - this will need a bunch of screenshots and might take a while. Numbering your tests will make this a load easier.

You'll also want to look at Testing, Testing 124 which I blogged last year (it's about databases but it'll kinda work) as well as Normal, Extreme and Erroneous which I'll blog in a minute.

Oh, there's a Default Value option?

Yes, there's a default value option in the field properties bit of database table design.

So use it already!

There's all sorts of reasons and situation when you might use this feature. For starters, you might have a common value that many times will need to go into the box. Here's an example - let's say it's a stock control system being designed by someone who is completely hypothetically called "Steph"...

The field here is one where the user can say whether or not a bill has been paid.

The chances are that when the stock is booked in the bill won't have been paid - a bill is sent afterwards (the designer knows this because she spoke the the client - she knows the client's needs...). So a No is by far the most common value to go into the field when the record is created.

So, we use a default value of No!

You can also see some simple validation and whathaveyou. Of course, an alternative might have been to have used a Yes/No Data Type rather than a Text field...

Now, the same database also needs to enter the Date In of the stock being stored. Here again we can use a default value - the chances are that most of the time the value will be the current date.

Again, the designer knows this because she spoke to the client about it and found out. For sure. Can I stress that this step is really, really important in all of this? Thanks.

Here's the field properties:

We can use Date() to get the current date in that cell.

Note the validation here.

It's possible, although unlikely, that a different date might need to be entered. A container might be fortgotten about or not entered for some reason. Because of that the validation rule has been set to accept any date from 7 days before today until tomorrow - a container might sometimes be logged on the system the day before it's actually present on site.

Do I need to tell you how she knows this?

Here's the Planned Date Out field properties:

The minimum length of time a container can be in store for is 1 week apparantly. Seems a bit odd, but that's the way it works. So the Default Value can be set to a weeks time - Date()+7. The Valudation rule here might need to be >Date()+6 actually - I think you'd need to test all of this.

---

Now, testing...

All these rules and default values need testing. This goes in the Testing section of a report - in the Test Plan. In all this you clearly have to test the Boundary Values as well as values which are obviously going to the right and those that are obviously going to be wrong.

So, if I'm testing this all today (10/3/09) then I'd be checking if I could enter 2/1/06 (hopefully no - it's clearly wrong), 9/3/09 (OK), 2/3/09 (shouldn't accept it - and it's a boundary value) and 3/3/09 (should accept it - it's a boundary value again).

This demonstrates the importance of a clear test plan at this sort of level - it shows you the detail of testing that systems like this need.

Testing, Testing, 124

Test plans rock.

Really, they do. They're sooooo important. But they're always the stuff people leave out.

One of the key things with a Database Testplan (for the AQA Applied A Level course btw) is that the plan needs to relate clearly to the evaluation criteria. This is totally like crucial dude - check out the markscheme AO4 Line 3.

So, you can have all of your generic testing stuff like field sizes, queries and whathaveyou, but if you don't have specific testing points related to your evaluation critieria you're not getting very far down the mark line.

Here are a couple of someone's evaluation criteria. We'll call him "Alex" (it's OK, he's not a duck...):

Test Number 11
Test: User can edit data (eval crit 2)
How tested: I will try to edit data in tables
Expected Outcome: Able to edit data

Test Number 12
Test: The database prints weekly and daily reports related to that week/day (eval crit 3)
How tested: I will try and print reports which automatically print the records for today or this week
Expected Outcome: The right data will be printed without anything which is not needed

Ideally you want to refer all of your evaluation criteria to points in your test plan. I'll say it again: this is in addition to the generic testing points that you might have. That's really important. Like, really.

Or the ducks will know.