Test plan — data, expected, actual, remedial
Testing comes before implementation (going into live use) — an untested system may fail once real users depend on it. Work follows a written test strategy, and each test is recorded in a test plan under four headings: the test data used; the expected outcome, worked out in advance; the actual outcome once the test is run; and the remedial action taken if the two do not match — fix the fault (e.g. a validation rule), then re-test.
Normal, abnormal and extreme test data
Normal data is valid and inside the accepted range, so it should be accepted and processed correctly (65 for a 0-100 field). Abnormal data is invalid — wrong data type, outside the range, or blank where one is required — and should be rejected, with an error message ("abc", 150, -5). Extreme (boundary) data is the highest or lowest value that should still be accepted (0 or 100); it is valid data, and checks that values right up to the edge are accepted.
Levels of testing, then live data
Development is tested in two stages. Module/function testing checks each part on its own first (one formula, one form), so a fault can be traced to that part. Whole-system testing then runs every module combined, checking data entered in one module reaches another module's report. Live data — real data the organisation already holds — is run last, to check the system gives correct results and runs quickly enough on the genuine volume and variety of real records.
Drawn from real examiner reports.
Extreme data: one value, not a range
Asked for extreme (boundary) test data, candidates write an explanation ("test the highest and lowest values that should be accepted") or a range ("0 to 100") instead of the thing actually being asked for. Give ONE specific value — "100" — and then the reason it is being tested: because 100 is the highest value the field should still accept.
Flagged s23 P12 Q7 · w22 P11 Q4a · s22 P12 Q9b
Abnormal data is not one fixed value
Some candidates treat abnormal data as if only one wrong answer counts (usually text typed into a numeric field). Abnormal data is any data the field should reject: the wrong data type, a value above or below the accepted range, or a blank where an entry is required. For a 0-100 mark field, "abc", "150" and "-5" are all acceptable answers.
Flagged s22 P13 Q5a
Extreme data ≠ abnormal data
Extreme (boundary) data is still valid and should be accepted — it sits exactly on the edge of the allowed range. Abnormal data is invalid and should be rejected with an error message. For a 0-100 field, 100 is extreme, but 101 is one step beyond the boundary, so it is abnormal. Offering 21 as abnormal for a field accepting 1-21 is the same slip.
Normal data ≠ extreme data
Both normal and extreme data are valid and should be accepted, so candidates hand over one when the question named the other. The difference is position, not validity: normal data is a typical, mid-range value (65 in a 0-100 field), while extreme data sits exactly on the edge of the accepted range (0 or 100). Read which word the question uses before choosing a value.
Test data with no expected outcome
A test-plan answer that records only the test data value is half an answer. Testing means comparing what should happen against what did happen, so the expected outcome has to be worked out and written down before the test is run. Without it there is nothing to compare the actual outcome against, and nothing to trigger remedial action.
Whole-system testing is not enough
Candidates describe testing the finished system only, skipping module testing — or write "the modules are tested first" and stop, with no reason. Each module or function is tested alone because a fault can then be traced to that specific part; a fault surfacing only in the combined system is far harder to locate. The whole system is still tested afterwards.
Live data: naming it is not explaining it
Answers often say live data is "real data" and go no further. State the advantage — it checks the system gives correct results and runs quickly enough on the genuine volume and variety of records that invented test data cannot reproduce — and the risk: an undiscovered fault could corrupt or lose the organisation's real records, which is why live data is tested last.
Give the value, then the because
For any test-data question, write the actual value first ("0", "101", "abc"), then a reason tied to that exact value: "because 101 is one more than the highest accepted value, so it should be rejected". A vague reason such as "to check it works" scores nothing.
Fill all four test-plan columns
A test-plan question usually wants the whole row, not just a value: the test data, the expected outcome worked out in advance, the actual outcome once the test is run, and the remedial action taken if the two differ, before re-testing.
Boundary questions target a formula
Examiners record extreme/boundary test data being set on the boundaries of a formula — a field with a stated valid range feeding a calculation. Read the range given in the stem, then pick a value sitting exactly on its upper or lower limit and say which limit it tests.
Discuss: cover every named part
A discuss question that names three areas — levels of testing, types of test data, use of live data — must cover all three; answering on test data alone caps the marks. Finish a high-tariff discuss with a judgement, not just a list of points.
Full notes, flashcards, Q&A and the topic quiz for every premium subject.
Premium plans are US$8.99/month or US$49.99/year — first month free.
Studying with a parent's blessing? Show them this.
