Practical/Project Work and Laboratory Skills
What the examiner tests
The practical paper and project viva check whether you can plan, code, test and document a small program and use a spreadsheet or word processor competently.
Core rules
- Lab record format: Aim; software/hardware required; algorithm; flowchart; program listing with comments; sample input and observed output; conclusion. The output must match the code exactly.
- Compile before running; read the error message and its line number. Syntax errors stop compilation, runtime errors occur during execution (divide by zero, array index out of range), logical errors give wrong answers with no message - a trace table finds them.
- Test data: normal, boundary (0, 100, empty string), and invalid input. For “largest of three”, test all equal, two equal, and all negative.
- Use meaningful variable names, indentation, and comments. Keep backup copies and sensible file names.
- For projects: choose a small local problem (fee register, library list, quiz), keep to the syllabus, cite any external help, and be ready to explain every line you submit.
Worked example
A program computes the average of marks. Test 1: 80, 90, 70 → 80.0 (normal). Test 2: 0, 0, 0 → 0.0 (boundary; division is by the count, not by the total, so it is safe). Test 3: count entered as 0 → guard with if (n > 0), otherwise it is a divide-by-zero runtime error. Test 4: marks above 100 → validation message. Recording all four cases in the practical file shows the examiner that testing was planned.
Traps
- Submitting a screenshot with no input shown, or output that does not match the listing.
- Drawing the flowchart after writing the code and leaving the symbols inconsistent.
- Skipping boundary cases because “it worked once”.
- Copying a project from the Internet without understanding it - viva questions expose this.