Did you know that a computer program can accept a perfectly typed number and still give the wrong result? A school attendance form might accept ‘300’ because it contains only digits, even though the permissible range is much smaller. Another program might reject a valid boundary value because the programmer used a strict inequality. Writing Python code is only the beginning of the task. Reliable computing requires a precise input contract, tests of its edges and a way to follow what happens after unexpected data arrive.
This independent eduKateSG Ministry of Education V3.0 Reference 357 develops 2027 SEC G3 Computing K349 Module 2.4: testing, debugging and input data validation. The syllabus identifies length, range, presence, format, existence and check-digit checks, normal/error/boundary conditions, trace tables, strategic print statements, incremental testing and different responses to invalid interactive and non-interactive input. Twenty-six original worked examples, twelve diagnostic stages, an entirely fictional school-lab exercise and independent repair checks connect those ideas to practical student reasoning.
The code examples are deliberately small educational demonstrations, not real identity-verification, cybersecurity or production data-handling systems. Names, access codes and records are invented; no personal data should be uploaded or recorded for these exercises. Students must follow school rules for use of Python, JupyterLab, software and any AI assistance, and confirm the exact examination-year syllabus and assessment procedures with SEAB. This reference is independent of Singapore’s Ministry of Education.
Study route for busy learners
- Write the input contract and the exact acceptance condition in ordinary English.
- Distinguish presence, length, range, format, existence and check-digit rules.
- Design normal, valid-boundary, adjacent-error and wrong-type tests.
- Dry-run Python statements into a trace table; diagnose syntax, run-time and logic errors.
- Repair the earliest invalid step and test a different dataset independently.
1. What the official K349 syllabus actually requires
The 2027 G3 Computing syllabus K349 covers testing and debugging under Module 2.4. Students should be able to dry-run code into a trace table, use print statements for inspection, backtrack from unexpected behaviour, test incrementally and isolate program sections. It specifically names six types of input validation and asks students to distinguish syntax, logic and run-time errors. A sound lesson therefore tests both what a program is designed to accept and what it must refuse, rather than evaluating success only because it runs on one demonstration input.
2. Start with an input contract written in plain English
An input contract describes the permitted data before any Python is written. For a fictional score field, it might say: one integer from 0 through 100 inclusive, no letters, and invalid interactive input should prompt another attempt. That sentence identifies the data type, lower and upper limits, boundary inclusion and response. Without a contract, the programmer may write technically valid code whose behaviour cannot be judged. The contract is the most efficient first step because it gives every later test an expected answer.
3. Validation checks acceptance rules; verification addresses other questions
Validation asks whether input satisfies specified constraints. Verification can concern whether data were copied or entered accurately against an original source, and authentication concerns a person’s claimed identity. A correctly formatted fictional pupil identifier may still refer to the wrong person or be maliciously submitted. It is a mistake to treat a successful length or check-digit test as proof of truth. Learning to distinguish these questions helps students avoid inflated claims about what software can establish.
4. Presence checks reject an absent required value
A form may require a response; an empty string is not a meaningful selection. In a simple Python model, the length of an entered string can be used to detect zero characters. If spaces alone are not acceptable, the validation rule must say so and handle whitespace appropriately. The distinction matters because a field filled with three blank spaces may have length three while communicating nothing. Write the desired definition of presence first, then choose the code that enforces it.
5. Length checks count the correct unit
A fictional ticket code may require exactly six characters. The string ‘AB1234’ passes while ‘AB123’ fails. If a specification instead requires six numeric digits, a length check alone is insufficient because ‘ABCDEF’ also has six characters. Treat character count and content format as separate tests. Students should not make up a maximum length from an example input; it must come from the problem’s stated requirements.
6. Range checks are about inclusive boundaries
An integer field may permit values from 1 to 12 inclusive. The correct condition is 1 <= value <= 12, not 1 < value < 12. Boundary tests are 1 and 12, values just outside them are 0 and 13, and an ordinary valid middle case might be 7. A good test set must distinguish these outcomes. If a program wrongly rejects 1, testing only with 7 will hide the defect.
7. Format checks describe structure, not significance
A fictional code could require two uppercase English letters followed by four digits. ‘AB1234’ meets the stated pattern, while ‘A12345’ does not. A program that merely checks length would accept both. If the syllabus task supplies character conditions, validate those explicitly with the approved Python operations. Avoid assuming that a pattern also establishes existence, authorisation or authenticity.
8. Existence checks ask whether a value already occurs in a dataset
A fictional library cataloguer enters a new book code. The program may check whether it is already present before adding a record. For a lookup task, the opposite rule may apply: only codes already recorded are valid. The question’s purpose determines whether existence means accept or reject. In both situations, a successful existence check tells us something about this dataset at this moment; it does not prove the item exists everywhere or that the dataset is complete.
9. Check digits help detect some entry mistakes
A check digit is an additional character computed from the others using a stated rule, then compared with the submitted character. It can detect some transcription errors, but performance depends on the algorithm. An example examination question should supply the required scheme or enough information to derive it; do not assume every real identifier uses the same calculation. A valid check digit is not proof of identity, ownership or permission.
10. One field may require several validation checks
A fictional appointment ID can be non-empty, eight characters long, formatted as two letters followed by six digits and already present in an authorised lookup. Passing length does not guarantee format; passing format does not guarantee existence. Design the validation sequence so the program avoids applying operations to unsuitable types. Record which check failed and ensure the response is useful without revealing private details about actual records.
11. Interactive and non-interactive input need different handling
With interactive input, the program may ask a user to re-enter an invalid value when the task allows it. With non-interactive data loaded from a file, repeatedly asking a person may be impossible, and a program may need to stop or report the invalid record according to the specification. The 2027 syllabus asks students to justify when re-prompting or exiting is appropriate. The deciding factor is the mode of input and the intended workflow, not an arbitrary personal preference for endless retries.
12. Normal test cases show the central route
If valid scores are integers from 0 to 100 inclusive, a normal test might be 62. It should be accepted and processed correctly. Normal cases are necessary, but they are weak at exposing edge mistakes. A program can handle 62 while failing at 0, 100, or a nonnumeric string. Test classification should therefore come from the contract and the anticipated failure, not from how complicated the input looks.
13. Boundary cases are where comparison operators fail
For the inclusive range 0 to 100, valid boundary inputs are 0 and 100; adjacent invalid values are -1 and 101. Testing both sides helps detect an off-by-one error such as treating <100 as the rule. The requirement might instead define an exclusive range, in which case the boundaries differ. The phrase ‘boundary case’ describes a position relative to the specified rule, not a fixed list of numbers used everywhere.
14. Error cases should exercise invalid type and structure
A numeric input might receive ‘nine’, an empty string or a value with unexpected punctuation. A robust test asks what the program should do under the contract: reject, re-prompt, stop or record a controlled failure. A program that crashes without the intended response has not met the requirement merely because the data were invalid. Distinguish expected rejection from unhandled failure.
15. A trace table is a record of changing state
A trace table captures selected variable values as statements execute. The learner should name the current statement or iteration and show how variables change. It is not a freehand guess of what the code was supposed to do. For a loop that counts valid entries, trace the counter before and after a condition. The table helps identify an incorrect update or comparison even when the Python syntax is perfectly valid.
16. Print debugging is a temporary observation tool
Printing a counter or key variable during execution can show where expected and actual states diverge. Debugging output should be chosen strategically instead of filling every line with messages. It should also avoid exposing real passwords, personal details or confidential records. In an exam-style example, the student can state exactly what would be printed at a selected location and how the value guides further investigation. The display is evidence, not the fix itself.
17. Backtrack from the first unexpected state
If the final total is wrong, compare intermediate values to the expected trace. Find the earliest step where actual behaviour differs, then inspect the statement that produced it. Changing a final output statement may conceal rather than repair the underlying cause. This resembles Mathematics error repair: the useful diagnosis is the first invalid mental or computational move. The goal is to explain why the failure arose and retest the smallest relevant region.
18. Syntax, run-time and logic errors are different
A missing colon after an if statement is a syntax error. Dividing a number by zero can cause a run-time exception. Accepting an invalid boundary because of the wrong comparison operator is a logic error. A program may run successfully while being logically wrong. Classifying the error helps the pupil decide whether to inspect grammar, exceptional input or the intended algorithm. Avoid calling every unexpected output a syntax error.
19. Incremental development reduces uncertainty
Start with a small correct route, such as reading one score and checking its range. Then add a second requirement, a loop or a record lookup, testing after each change. If the new version fails, the most recent addition provides a useful starting point. This does not guarantee correctness, but it makes faults easier to localise. Students should keep expected results visible rather than relying on a satisfying success message.
20. Isolating small program sections can clarify a fault
The syllabus includes testing small parts of a program by commenting out sections not needed for the check. This technique should be used carefully: removing code can also remove an important dependency and change behaviour. A student should state which function or branch is under inspection, what input it receives and what output is expected. After repair, restore the full program and run integration tests so the isolated success is not mistaken for total success.
21. Trace tables should show the final iteration too
In a loop, the value that ends iteration is often where an off-by-one error becomes visible. If the loop condition is count < 3, a trace may show counts 0, 1, 2 while the body executes and then 3 when the condition becomes false. Writing only the body rows may hide why termination occurred. Clearly distinguish a condition check from a completed iteration, especially when tracking index changes.
22. Validation does not solve privacy and security by itself
A field can be well-validated while the application still stores excessive personal data, exposes records or uses a weak access model. Real digital systems need appropriate confidentiality, permission, error handling and retention practices. In educational cases, use only fictional values and test datasets. A pupil should be able to say precisely what a validation rule establishes and what remains beyond its boundary.
23. Avoid giving away existence information in a real system
In a classroom dictionary, a message such as ‘this fictional code is missing’ is harmless. In a real access-control workflow, detailed messages can reveal whether someone else’s account or identifier exists. Production systems may therefore use different user-facing error wording while keeping useful internal logs. This is an extension of computing ethics, not a requirement to implement authentication in a G3 paper practice exercise.
24. Independent transfer means a new specification
A learner who validates scores in one exercise may still stumble when the next task involves book codes, dates, repeated input or a file. The tutor should change the input type, boundaries and response strategy, then ask the student to design a new test table without copying the old one. If the learner explains why a value is normal, boundary or error and traces a failing path to its cause, the skill is transferring.
25. A small original Python reference example
The following miniature program illustrates an interactive integer range check; it is not an official examination solution and contains no actual student records. It converts text safely in a limited way, repeats the request when the input is invalid and accepts only the specified inclusive range. A production program would need broader interface and security handling appropriate to its environment.
while True:
raw = input("Enter an integer from 0 to 100: ")
try:
score = int(raw)
except ValueError:
print("Enter a whole number.")
continue
if 0 <= score <= 100:
print("Accepted:", score)
break
print("Number out of range.")The three useful tests are 0, 100 and a nonnumeric value such as ‘hello’. The first two should be accepted because the contract includes its boundaries; the third should prompt another entry rather than crashing on conversion. Notice that a string such as ‘4.5’ is not an integer and fails the conversion. Whether a field should allow decimals is a separate specification decision.
26. Twelve-stage Contract–Test–Trace–Repair protocol
Stage 1 — Read the problem statement
Write the exact input, output and permitted values in words before programming.
Stage 2 — State each validation rule
Separate presence, length, range, format, existence and check-digit requirements that apply.
Stage 3 — Classify the input mode
Identify interactive input or file/batch data and the expected response to invalid input.
Stage 4 — Design representative data
Choose normal inputs, valid edges, adjacent invalid values and wrong-type cases.
Stage 5 — Predict expected outcomes
Mark each test as accept, reject, re-prompt or stop according to the specification.
Stage 6 — Write minimal working code
Implement one rule correctly before layering more conditions and loops.
Stage 7 — Dry-run the critical path
Record important variable values and control-flow decisions in an ordered trace table.
Stage 8 — Check failure boundaries
Try the values immediately inside and outside each permitted edge.
Stage 9 — Observe strategically
Use selected print statements or inspection points without exposing confidential input.
Stage 10 — Backtrack from divergence
Identify the first step where actual state differs from expected state and explain the cause.
Stage 11 — Repair and rerun
Change the relevant condition or operation and retest both the failing case and the normal case.
Stage 12 — Transfer independently
Apply the method to a different fictional dataset and justify the full test set.
27. Fictional student computing lab
At an entirely invented school coding lab, three learners inspect a small program that registers pretend library materials. Pupil A reads the specification and writes expected acceptance outcomes. Pupil B traces variable values and implements one validation rule at a time. Pupil C designs maliciously awkward but harmless fictional test inputs and explains the likely error class. They rotate roles. The tutor ultimately gives each learner a new problem to solve alone, checking understanding of the rule rather than the appearance of a working screen.
28. Twenty-six worked examples and repair explanations
Worked Example A. Inclusive score boundary
A fictional score must be an integer from 0 through 100 inclusive. The input 0 is valid, 100 is valid, while -1 and 101 are invalid. The condition is 0 <= score <= 100. Code that tests score > 0 and score < 100 will wrongly reject both valid boundaries. Include these four inputs even if 58 passes normally.
Worked Example B. Normal score
The same range accepts the ordinary test value 62. However, acceptance alone proves only that the central case followed its intended path. It does not establish correct behaviour for letters, missing values or boundary numbers. A complete test table records input, expected result, actual result and whether the result matches the stated rule.
Worked Example C. Empty required field
A fictional library form requires a nonempty title. An empty string violates presence. A string containing spaces may be nonempty in character count but empty in meaningful content, so the contract must say whether whitespace-only values are allowed. Do not assume len(value) > 0 is sufficient for every definition of presence.
Worked Example D. Exactly six-character code
A classroom passcode-format exercise requires exactly six characters. ‘AB1234’ passes length, ‘AB123’ fails length and ‘ABCDEF’ passes length while failing a separate letters-plus-digits format rule. This demonstrates why validating one property does not establish another. No real password or access credential should be used in classroom tests.
Worked Example E. Two letters and four digits
The fictional format is two uppercase letters followed by four digits. ‘SG2027’ satisfies the pattern; ‘S22027’ has six characters but fails the second-letter rule. It also illustrates why a six-character length test must not be substituted for a format test. The specification should state whether lowercase letters are acceptable rather than silently converting all inputs.
Worked Example F. Presence check with spaces
Input ‘ ‘ has length three but carries no visible characters. If whitespace-only responses are forbidden, trim or otherwise test meaningful presence using an approved approach. A test set should include the empty string, spaces and a legitimate word. The boundary here concerns a defined content condition rather than a numeric range.
Worked Example G. Existence check for a known code
A fictional dictionary maps ‘L101’ to a book and ‘L102’ to another. A search for ‘L101’ can pass an existence requirement; ‘L999’ does not. A new-record registration problem reverses the acceptance logic and rejects an existing code. Students must state whether the task is finding an item or preventing duplicates before choosing the condition.
Worked Example H. Missing dictionary key
Trying to fetch a key that is absent may raise an error depending on the Python operation used. The program should first test existence or use a suitable safe-lookup approach when that matches the specification. A syntax-correct expression can still fail at run time. Explain what input causes the failure and what controlled response is expected.
Worked Example I. A simple invented check digit
A teaching code has three digits a, b and c, followed by a check digit equal to (a+b+c) modulo 10. For 2, 4 and 7, the sum is 13 and the check digit is 3. The fictitious code 2473 passes; 2474 fails. The rule is wholly invented for this exercise and must not be used to validate real national identifiers.
Worked Example J. Check digit versus identity
The fictional code 2473 passes the invented arithmetic check. It does not prove that the associated person or account exists, nor that someone owns it. A check-digit test protects against selected mistakes in entry; identity or permission would require different evidence. The code’s success must not be described as authentication.
Worked Example K. Interactive re-prompt
A school practice program asks for a whole number between 1 and 5. The user enters 0, then 3. Under a re-prompt contract, 0 triggers another request and 3 is accepted. Explain why a ‘while invalid’ loop fits this interactive workflow. The code should not silently coerce an invalid zero into a valid selection.
Worked Example L. File input with an invalid record
An invented CSV file contains counts 4, 8 and ‘eight’. The third record fails an integer-conversion rule. If the supplied task says to exit on non-interactive invalid input, the program should stop or report the failure under that specification, not repeatedly prompt an absent user. The learner must justify the difference from an interactive keyboard form.
Worked Example M. A TypeError or ValueError distinction
Converting the string ‘three’ to an integer with int(‘three’) raises a ValueError in ordinary Python. The statement itself is syntactically valid; the failure occurs during execution. Therefore classify it as a run-time error, not a syntax error. An expected invalid-input response may require checking or handling this possibility.
Worked Example N. A missing colon
The educational snippet ‘if score >= 50’ without a colon before its block is syntactically incomplete in Python. The interpreter cannot parse it as intended. Fixing the colon addresses syntax, but does not prove that the threshold is correct. After the edit, test the real boundary values of the decision as well.
Worked Example O. Logic error at a threshold
A pass rule includes scores from 50 upwards, but the program uses score > 50. The code runs and accepts 51 but wrongly rejects 50. This is a logic error, exposed by a boundary test. Repair to >= 50 after verifying the written specification, then retest 49, 50 and 51.
Worked Example P. Trace a counting loop
In an invented sequence 2, 5, 8, a counter starts at zero and increases for values above 4. The state remains 0 after 2, becomes 1 after 5 and 2 after 8. The final count is 2. A trace table should record the value inspected and the counter after each decision; a bare final answer hides where an error occurred.
Worked Example Q. Trace a running sum
Start total = 0. Loop over 3, 4 and 2, adding each item. The trace gives totals 3, 7 and 9. If a program outputs 7, the student can inspect whether the last iteration ran or whether an early exit occurred. Write expected intermediate states before inserting debugging print statements.
Worked Example R. Range check accidentally reversed
A fictional field permits 10 to 20 inclusive. The condition 10 >= value >= 20 accepts no ordinary number because it asks value to be at most 10 and at least 20 simultaneously. The correct condition is 10 <= value <= 20. Testing 10, 15 and 20 exposes the direction error immediately.
Worked Example S. Boundary and error classification
For the valid integer range 1–9, inputs 1 and 9 are valid boundary cases, 5 is normal, while 0 and 10 are adjacent invalid cases. Input ‘hello’ is a wrong-type error case. A valid 9 and invalid 10 test different decisions, even though the numbers are close. Classification follows the contract, not visual impression.
Worked Example T. A list-membership requirement
A fictional course form accepts only ‘A’, ‘B’ or ‘C’. Input ‘B’ passes existence in the allowed set; ‘D’ fails even though it has the same length and alphabetic format. This is a membership rule, not a simple character test. A clear validation message should explain the allowed choices without inventing categories.
Worked Example U. Duplicate registration
A fictional dictionary already contains item codes C01 and C02. A new item with code C01 should be rejected under a no-duplicates rule, while C03 may be accepted subject to its other checks. Here existence indicates a conflict rather than validity. Both tasks use the same underlying dataset but different intended behaviour.
Worked Example V. Validation sequence order
A fictional age field must contain integer text between 1 and 120. Trying to compare a raw string ‘nine’ with integer limits is invalid. Validate or safely convert the type before applying the numeric range. If the format is not numeric, report controlled rejection. Good order prevents an avoidable run-time failure.
Worked Example W. Backtracking from an unexpected total
A program should sum three fictional quantities 6, 7 and 8 to make 21, but prints 13. Trace shows updates 6 and 13, with no third addition. The earliest divergence is an omitted iteration or premature loop exit, not the final print statement. Fix the route, rerun and verify that another three-item list also works.
Worked Example X. Isolating a formatting function
A larger fictional program produces incorrectly formatted item codes. The student tests a small formatter with known input while unrelated file-loading sections are temporarily excluded. If the formatter succeeds, the data arriving from an earlier stage may be wrong. Restore the full program before claiming success; isolated correctness is only partial evidence.
Worked Example Y. A date-like string without date validation
The string ’31/02/2027′ has a plausible length and separator pattern but does not describe a real calendar date. A simple format rule can therefore pass a value that fails a deeper semantic requirement. Only implement the additional calendar check if the specification requires it and appropriate methods are available. Never claim string shape proves validity as a date.
Worked Example Z. Independent new registration program
Design a fictional event-code form requiring three uppercase letters, two digits and absence from a supplied list. The learner specifies normal, length, format, existing-code and boundary tests, then explains whether the program re-prompts or stops on invalid input. A complete answer identifies the contract, expected results, trace checkpoints and limitations, rather than copying the score checker.
29. Ten common errors and precise repairs
1. Relying on a single normal input
Add valid boundaries, adjacent invalid values and wrong-type cases so errors at the edges cannot remain hidden.
2. Treating length as format
A six-character value can contain the wrong kinds of characters. State and test each required property separately.
3. Treating a check digit as authentication
An arithmetic check does not establish identity, ownership, permission or completeness of a real dataset.
4. Using exclusive comparisons when inclusivity is required
Read the specification and test both endpoints explicitly.
5. Catching an error by changing output text only
Backtrack through actual variable states and repair the first incorrect step.
6. Calling a run-time failure a syntax error
Check whether parsing fails, execution fails or execution finishes with the wrong logic.
7. Re-prompting for every file-record error
Match error handling to interactive or non-interactive input and the task’s expected workflow.
8. Assuming existence means acceptance
In a lookup, existing may be valid; for new registration, existing may be a duplicate to reject.
9. Printing sensitive values while debugging
Use invented records and carefully chosen non-confidential diagnostics; real systems have data protection duties.
10. Stopping after isolated component success
Restore the full route and retest integration and boundary cases after each repair.
30. Three-pupil tutorial and independent check
Use three different forms—an integer score, a patterned catalogue code and a non-interactive record file. First have all pupils describe each contract and the expected response to invalid input. Assign one to propose tests, another to implement a miniature check and the third to trace failures. Rotate after feedback. The teacher should correct an underlying misconception, such as treating a format match as proof of identity, before asking for more coding. Finally, take away the model answers and give each student a novel specification requiring a different order of checks.
31. eduKate Depth–Load–Transfer diagnostic
Depth: can the learner explain why format validation, existence validation and verification are not interchangeable, and why a check digit does not prove identity? Load: can the learner keep a multi-rule contract, Python control flow, several test categories and expected error responses in working memory? Transfer: can a new file-processing task be designed and tested without copying the interactive score checker? Categorise weakness as contract reading, condition, type handling, tracing, test selection, error classification or unjustified claim. Repair the smallest useful concept and retest with different inputs.
32. Parent and tutor coaching
Ask: ‘Which values are allowed?’, ‘Which edge is included?’, ‘What is one input just outside the rule?’, ‘What would the user see after a failure?’, ‘Which variable first became wrong?’ and ‘Can you test an unfamiliar code without copying the previous one?’ Praise precise debugging and written expected outputs. If the student is stuck, reduce the system to one condition, verify the boundary on paper and then put the code back together. The aim is independence and reliable reasoning, not memorising dozens of print statements.
33. Independent practice tasks with checks
Practice 1 — Build a test matrix
For an integer 10 to 20 inclusive, label 10 and 20 boundary valid, 9 and 21 adjacent invalid, 15 normal and ‘abc’ invalid type.
Practice 2 — Repair a strict inequality
The rule accepts 0 through 5 inclusive but the code uses value > 0 and value < 5. Rewrite the condition and name the four useful edge tests.
Practice 3 — Separate two checks
Design length and format tests for a fictional code made of two uppercase letters and three digits. Explain why either test alone is insufficient.
Practice 4 — Trace a loop
For input values 3, 6 and 1, sum the values greater than 2. The accepted values are 3 and 6, and the final sum is 9.
Practice 5 — Use membership correctly
A task permits only ALPHA and BETA as category labels. Show the expected decision for ALPHA, GAMMA and an empty string.
Practice 6 — Invent a check digit
Given rule last digit = (first two digits’ sum) modulo 10, confirm 572 because 5+7=12; reject 573. Explain this is not a real identifier rule.
Practice 7 — Choose the response
For an interactive menu, justify re-prompting after invalid input. For a batch file, justify the specified controlled exit or report.
Practice 8 — Classify three faults
Missing colon is syntax; int(‘apple’) produces a run-time conversion error; using > instead of >= at the threshold is logic.
Practice 9 — Backtrack
A fictional loop should count three valid entries but reports two. State which loop states you would record to find the first divergence.
Practice 10 — Full transfer
Create a new invented library registration problem with a format rule, a lookup rule and a test table. Explain each expected outcome independently.
34. Frequently asked questions
What is data validation in G3 Computing?
It checks whether data meet stated acceptance rules. For 2027 K349, listed methods include presence, length, range, format, existence and check-digit checks. It does not on its own verify truth or permission.
What is a boundary test?
A test at an edge of the permitted range or an immediately adjacent value. For inclusive 0–100, test 0, 100, -1 and 101 as well as ordinary values.
How are normal and error cases different?
Normal inputs are representative valid values. Error cases violate a stated condition, such as wrong type or length; the expected program response should be defined.
What is the difference between a syntax error and logic error?
A syntax error breaks Python grammar, while a logic error allows the code to run but produces behaviour inconsistent with the specification. Run-time errors happen during execution.
Is a six-digit numeric string automatically a valid student ID?
No. It may satisfy basic length and format but not an existence, checksum, authorisation or identity check. Use only fictional identifiers in classroom practice.
When should a program ask again?
When the interactive task’s specification calls for a new attempt after invalid input. For non-interactive files, a different response such as controlled exit may be required.
What is a trace table?
An ordered record of variable values and decisions while statements execute. It helps locate the first difference between intended and actual state.
Can a print statement repair a program?
No. It reveals useful state for diagnosis. The student must still find the faulty logic, make an appropriate change and rerun relevant tests.
Does one successful run prove that the program works?
No. Test normal, boundary, error and integration cases, and check that the output matches the intended contract.
Is this a real SEAB practical paper?
No. It is an independent teaching reference with original educational examples, not an authorised specimen paper or a replacement for official 2027 K349 instructions.
35. Closing principle
Good computing begins with a precise claim about acceptable input and ends with evidence that the program behaves as specified at normal cases, difficult boundaries and failure conditions. A robust learner can locate the earliest incorrect state, repair its cause and explain the limits of the validation. The outcome is not merely a running Python program. It is an independently testable piece of reasoning that behaves predictably under unfamiliar inputs and protects real people from unwarranted claims about their data.
Official syllabus and connected eduKateSG references
SEAB 2027 SEC G3 Computing K349 official syllabus directory; Reference 325 — Python Functions and Testing; Reference 311 — Computing Spreadsheets; Reference 342 — Manual Algorithms; MOE V3.0 library; immutable Clementi teaching standard.