The criteria are:
They refer to the testing strategy employed, -the program listing, evidence of user friendliness, error-handling facilities and the hard-copy results of testing. In order to use criteria E - H in a consistent and reliable manner it is important that documentation that is easily interpreted should be included, notes and annotations should relate to output, and different ways of highlighting particular features related to these criteria are used.
Guidance relating to documentation is outlined in the notes accompanying the assessment criteria, and in the Assessment Guidelines, in the guide to Computer Science, April 1998, pages 54-58. Some general observations by Senior Moderators in Computer Science concerning these criteria are included in this section.
Weak areas in many Program Dossiers include a lack of:
It is important that candidates correct these shortcomings since teachers and moderators need to identify certain features in order to judge standards against the criteria.
Although the writing of comments within program listings has been reasonably well done, there is a reluctance to amplify, either be hand or word processor, with notes on the hard copies of output. The criterion F, which candidates must address, will be applied in examinations from 2000, therefore o will not be sufficient for them to enter data into the program and simply submit all the printouts.
The test strategy, assessed using criterion E, should chart a logical route through the program, therefore the purpose of each set of test data should be clearly explained and justified. The data selected should also show how valid data, normal and extreme, and invalid data are handled The test strategy, once designed, must be reflected in the test output.
Candidates must add comments to printouts for all test data documented in the test strategy, even if only by hand. These should include:
The following pages exemplify both part of a test strategy and some sample output.
The output illustrates some of the features mentioned in the observations made by Senior Moderators in this section, with some typical annotation that could have been written be a student. In the descriptions of the test run, the sample output is in a frame and the student annotation appears like this.
The following samples are not meant to represent the complete output section of a Program Dossier. Obviously, many more test runs would be needed to show, for example, all error-trapping routines and the expected results of invalid data entry.
| Test Run | Data | Reason | Expected Results |
|---|---|---|---|
| Display file | Test that it is empty, and works with extreme data, ie. 0 records. | "THERE ARE NO STUDENTS ON RECORD" | |
| Add student details for Xenia Williams, 9PQ. | Test that program Accepts standard data. | No errors during input. | |
| Display file. | Test that display alters correctly withy 1 record. | WUKKUANSM XENUAM 9PQ. | |
| Add student details for Jenda Purgent 10HH, Harold Lurmin 9TF, Ilian Gurn 11KJ and Lilly Katern 10HH. |
Test that program accepts more than 1 standard data record, by calling entry routine 4 times from main menu. | No errors during input. | |
| Charge Xenia William's class to 9TF. | Test amend a record. | Display WILLIAMS, XENIA, 9PQ before accepting new data. | |
| Delete Lurmin's details. | Test that an existing record can be deleted by entering surname. | Display PURGENT, JENDA, 10HH before confirming that delete has not occurred. | |
| Start todelete Purgent's record, but then opt out. | Test that confirm feature works for error trapping. | Display PURGENT, JENDA, 10HH before confirming that delete has not occurred. | |
| Add two new records for Lorna Orgon 9PQ and Petra Rawl 11KJ. | Test that new data added to a file with more than one record in is added at the end of the file. | No errors during input. | |
| Display file. | Test that all changes have been saved. | WILLIAMS,XENIA 9TF PURGENT,JENNY,10HH GURN,ILIAN,11JK KATERN,LILY,10HH ORGON,LORNA,9PQ RAWL,PETRA,11KJ |
Each numbered heading refers to the number of the test run within the test strategy. The test run outputs appear in a frame and student annotation in italicised font.
1 Displaying initial (empty) file: | ||
| A text is used because it is clear to all users, even those who cannot control a mouse easily. The layout is clear and uncluttered, so it is easy to understand.>/i> | |
2 Adding one student: | ||
| This is the exteme case of an empty data file. | |
3 Showing complete file after this entry: | ||
| Note that the program converts all input to upper case. | |
4 Add the details of another four students as given in test strategy. File is now: | ||
| The data is exactly as expeted from the "expected results" of the test strategy section. It now states students in order to keep the grammar correct |
|
5 Amending Williams' details: | ||
| The details are shown before being deleted. (In the possible extensions I want to add the prompt: "Are you sure you want to deltete?".) The class has been changed from 9PQ to 9TF. |
|
6 Deleting a student: | ||
| An error trap has been inserted so that the record is not automatically deleted until it is confirmed. |
|
7 Avoiding deleting a record: | ||
| Note that the program accepts lower case or upper case inputs. ("Y" was entered before.) |
|
8 Add two new students, oRCoN and xAwL, with details as in test strategy. | ||
9 Showing current file: | ||
| The class has been changed correctly. The record was not deleted due to the error trap. Lurmin has been deleted from between Purgent and Gurn. The two new students have been added at the end of the file. |
|
|
|
![]() csgate@donaldson.org ICQ# 62833374 |
|