The requirements for the top mark are to show that you have tested your system thoroughly, that your user has tested the system and that you have found unexpected results during testing.
You will have to test all the user requirements that you specified in Analysis. Look at these critically before you start and, if necessary, change them to make sure that they are substantial enough to test.
My user requirements were specified earlier (sample requirements):
To test these requirements I created the following data:
Insert table here with a column for each field and a row for each record. You should create around 10 records for entry into your system.
Some of the fields must test the validation routines that you included such as:
Think about the data you create:
Test every record and field as you enter them. To avoid pointless testing you can make generic comments about certain fields e.g. names cannot be validated, they can only be verified. But you could test for excessive length of name e.g. 21 characters for a field length of 20.
Describe the test. State the expected outcome. Show the actual outcome. Comment on the outcome. Look for discrepancies between expected and actual output.
The best unexpected outcomes will arise naturally from your work. It will be imperfect; testing is supposed to discover this.
Most tests will produce actual results in line with the ones expected. To get full marks you need to have two outcomes that were unexpected, where the actual results were different to what you expected. The idea is that you should notice that the results are different to what you expected.
Thorough testing of your system should yield some unexpected results because your system will not be perfect: it is not expected to be. If you do not encounter unexpected results you may have to create some.
One way to create an unexpected result is to amke a mistake in a query such as '<' instead of '>' - either you or the user could create this. Or you could change the criteria in an existing query – if they enter wrong criteria the output will be wrong.
Another would be to enter a value such as 'Yes' where the entry should be 'No'. The query based on this data would include the 'Yes' record but this is a mistake because it should have been 'No'.
Another way would be to have a mistake in an input mask e.g. 5-blank-6 for a phone number; but this will not apply to London or Cardiff as these use 3-4-3 or Leeds, which is 4-7 or Sedbergh, which is 6-5. In each case you are expecting a phone number to fit the input mask but the actual data is more complex than you thought when you designed it.
Another source of unexpected results is a date. You might encounter a date in non-UK format e.g. 12/23/1990, which you cannot enter because your date format is UK; or 09/11/1990, which is valid but not correct because the UK format should be 11/09/1990.
Another source of an unexpected error is printing. We had an instance of where a page had been set up in Publisher as A3 instead of A4 – a genuine mistake as it happens. When the labels were printed they were split across two pages of A4 because the original size was A3. This was unexpected and easy to fix using Page Setup, changing the size to A4 and dragging the labels into their correct position on the page.
The best unexpected outcomes will arise naturally from your work. It will be imperfect; testing is supposed to discover this.
Run the query and show the output. Comment on the output produced – actual vs. expected, as before.
Create outputs from your merges and print the results. Base the outputs on a query. The query will be something that the user would want to use e.g. all people who subscribe to a newsletter .
You should do this off-site with either the real user or a parent. You need good documentary evidence e.g. a signed list of tests and photographs of the system in use.
You could delete your test data and re-use it with your real user.
Write out a list of tests that test your system. Work once again from your user requirements and make sure each one is tested by the user:
Data entry – test validation rules and any issues over accuracy e.g. the effect of Yes instead of No.
Query – does it work
Outputs – letters, labels, leaflets, etc.
Add a section at the end for general comments such as weaknesses and possible improvements – these will be very useful in evaluation.
Get the user to sign and date the form. One way to do this is to write the tests on a sheet of paper and get the user to tick and/or comment on whether the test worked.
If possible, take a photo of the system in use – anything to be convincing. For the evaluation (section 6) you will need some critical user comments so ask for these on the same form e.g. I would like it to do… It would be nice if it would…
You must convince the marker and moderator that you have truly tested your system with an adult user, not a peer. Think about how you can be convincing.