Science // Scientific Inquiry

Fair testing (age 8+)

Plan and carry out fair tests in which variables are controlled and failure points are considered to identify aspects of a model or prototype that can be improved

Ages
8 to 11
Type
Method
Builds on
1 topic
Leads to
1 topic
Standards
1 code

Quick check

When the learner builds and tests a prototype, can they run a fair test, find what didn't work, and figure out how to make it better?

Ask this to see whether the topic is secure.

Topic // Mastery

What mastery looks like

What a learner can do once this topic is secure.
  • Plan a fair test of a prototype with clearly identified variables to control
  • Carry out the test and identify failure points or weaknesses in the design
  • Propose specific improvements based on test results and retest

Topic // Map

Where this fits

What to learn first and what this topic opens up, with the reason for each link. Required links come first.
  • RequiredMust come first
  • HelpfulHelps, but not essential

Before this

1 topic
  • Comparing Possible SolutionsRequired

    Scientific Inquiry // Ages 8 to 11

    Must compare solutions before planning fair tests to improve prototypes

You are here

Fair testing (age 8+)

Ages 8 to 11 // Method

Leads to

1 topic
  • Controlling variablesRequired

    Scientific Inquiry // Ages 9 to 11

    Must plan enquiries with variable control before running fair tests on prototypes

Topic // Research-informed

Teaching notes

From the Marble Skill Taxonomy. These notes have not been validated in classrooms, so treat them as a starting point for your own judgement.

The approach

For ages 8–11, learners run the engineering test→find failure point→improve→retest loop on a prototype (bridge, parachute, boat). The core skill is controlled fair testing of a model: hold every condition constant except the one design feature being changed, locate the SPECIFIC point where and why it fails, propose an improvement targeted at that failure, and retest under identical conditions so any gain can be credited to the change. Hands-on building and testing is the primary vehicle (consistent with the KS2/NGSS requirement for pupils to build, test and improve); build-and-test simulations, a 3D structure sandbox, a reference diagram, recognition checks and a design-mentor dialogue serve as distinct supports with their own purposes and limits.

Common misconceptions

  • Treating a test as a pass/fail verdict rather than as diagnostic information about where and why the design failed.
  • Changing several design features at once between versions, then not knowing which change produced the improvement (loss of fair-test control).
  • Believing a first failure means the design (or the designer) is 'wrong', rather than that iteration is the normal engineering process.
  • Proposing improvements based on appearance or preference instead of on the observed failure point.
  • Judging a prototype on a single trial, ignoring that variability needs repeat runs to see the real behaviour.

Useful representations

  • The test → identify failure point → improve → retest iteration loop
  • A prototype annotated with its observed failure point (where it bent/broke/leaked)
  • A version-comparison table (v1 vs v2) with the single changed feature and the measured outcome
  • Design criteria + constraints checklist the prototype is tested against
  • A repeat-trials results strip for one prototype version

Teaching practices

  • Frame testing as diagnosis, not verdict: the goal is to locate the SPECIFIC failure point (where/why it broke), not just to record pass/fail — this turns a test into information that drives the next design change.
  • Insist on controlled comparison when crediting an improvement: change only the one design feature between prototype versions so any performance gain can be attributed to that change, not to an incidental difference.
  • Make iteration explicit and expected: run the test→identify failure→improve→retest loop at least twice so pupils experience redesign as normal engineering rather than as 'getting it wrong'.
  • Tie every proposed improvement to evidence from the test ('it snapped in the middle, so I'll add a support there'), not to untested hunches or decoration.
  • Quantify where possible (mass held, distance travelled, drop time) and take repeat trials so a fragile prototype's result isn't judged on a single fluke run.

Activities to try

  1. 1

    Build, test, and diagnose the failure point of a prototype

    Why it works: A test is a diagnosis, not a verdict: it shows where and how the design failed, giving evidence for reasoning about why, so you know what to change. Changing only one feature between versions, while keeping test conditions identical, is what lets you credit an improvement to that change (repeat trials then check it was not a fluke).

    1. Build a simple prototype against stated design criteria — e.g. a paper bridge spanning the gap between two tables, a parachute, or a floating boat.
    2. Plan a fair test: decide one loading/testing method and keep it fixed (same weight increments, same position, same drop height), and agree that version 2 will change only one design feature, chosen after you see where and how version 1 fails.
    3. Run the test and observe carefully WHERE and HOW it fails — e.g. 'it sagged and tore in the middle', 'the seam leaked at the corner', 'it buckled near the left support'. Record this failure point, not just pass/fail.
    4. Propose one specific improvement aimed squarely at that failure point (e.g. 'it snapped in the middle, so I'll add a support there' or 'fold the middle to stiffen it').
    5. Build version 2 changing only that one feature, then retest under identical conditions, and judge from the results whether it actually improved.
  2. 2

    Repeat trials and quantify before crediting an improvement

    Why it works: A fragile prototype's result shouldn't be judged on a single run; repeat trials and measurement reveal the real behaviour and make an 'improvement' claim trustworthy.

    1. For one prototype version, run the same test several times (repeat trials), using a fresh identical copy whenever the test destroys the prototype, and record the measured outcome each time — mass held, distance travelled, drop time.
    2. Compare the repeat results: notice whether a single run was a fluke or whether the behaviour is consistent.
    3. Fill in a version-comparison table: v1 vs v2, the single changed feature, and the measured outcome for each, with repeat trials for each version.
    4. Decide whether version 2 is genuinely better given the spread of results, not just one lucky run.
  3. 3

    Build-and-test simulation with a locked version tray (supporting scaffold)

    Why it works: Seeing the exact failure point highlighted and retesting under locked identical conditions can make 'test as diagnosis' and 'controlled comparison' visible and fast to iterate.

    1. In a bridge/parachute/boat builder with a test rig, assemble a prototype and load/drop/float it under fixed conditions.
    2. When it fails, read the overlay that highlights the exact failure point (the beam that buckles, the seam that leaks) and name where and why it failed.
    3. Use a version tray that keeps v1 beside v2 and locks all conditions except the one feature you change; reinforce precisely the highlighted failure point and retest.
    4. Watch whether the prototype survives the identical retest, and connect that result to the single change you made.

Topic // Standards

Curriculum standards

Codes for the curriculum statements this topic maps to. Each publisher owns its standard text.
Next Generation Science Standards (NGSS) K-5
3-5-ETS1-3

Science // Scientific Inquiry

More in Scientific Inquiry

All 30 topics