MYP Design Designing Tests for a Solution Notes

Testing Turns an Opinion Into Evidence

1. Every prototype looks convincing to the person who built it, which is why testing is a separate step and not a feeling.
2. A test puts the solution in front of a real task, under conditions you have written down, and records what happens.
3. Criterion D, Evaluating, starts with designing tests, so marks come from the quality of the test itself and not only from the result.
4. If no possible outcome would count as a failure, you have written an opinion rather than designed a test.
5. Ask two things of every test you plan: what result means this point is met, and what result means it is not.

Test the Specification, One Point at a Time

1. Your design specification from criterion B is the list of promises the solution made, so it is also the list of tests.
2. Turn each point into its own test instead of running one big trial that mixes everything together.
3. A point like "the stand must hold a 1.2 kg tablet at 60 degrees without sliding" already tells you the mass, the angle and the outcome to watch for.
4. A vague point such as "must be durable" has to be sharpened first, for example into "survives 50 open and close cycles with no visible cracking".
5. Number your tests to match the specification points, so Test 3 clearly answers Specification 3.
6. Points you cannot test yet, like a five year lifespan, need a proxy test such as accelerated wear, and you say openly that it is a proxy.

Fair Testing: Change One Thing, Hold the Rest Still

1. A fair test changes only the thing being tested and keeps everything else steady, so the result belongs to the solution rather than the conditions.
2. Testing your phone stand on a hard desk one day and a sofa cushion the next tells you about the surface, not the stand.
3. Write down the controlled variables before you start: same tester, same room, same 1.2 kg tablet, same table, same time limit.
4. Allow one change per run, so comparing version A with version B means comparing only the hinge you altered.
5. Testing your own design on yourself is the least fair test of all, because your hands already know the trick.
6. Fairness covers who tests it too, since three friends who want you to do well will miss problems a stranger finds in a minute.

Decide What You Will Measure Before You Measure It

1. A measurement needs a unit and an instrument, so "heavy" becomes "412 g on a kitchen scale".
2. Times come from a stopwatch or a screen recording, forces from a spring balance, lengths from a steel rule, each read to the same precision every run.
3. Things that are not numbers can still be scored with a rating scale, such as comfort from 1 to 5 with a written description of what 1 and 5 mean.
4. Counting works where measuring does not, so record 7 of 10 drops passed, or 4 of 6 users found the menu without help.
5. Set the success threshold in advance, for example at least 9 of 10 drops, so the threshold cannot change once you see the results.
6. Put the unit in your test plan, because a column of numbers with no unit is unreadable to a moderator.

Testing a Physical Product: Load, Wear, Fit and Place

1. A load test adds known masses until something bends or slips, so record the mass at which it failed rather than only stating the fact that it failed.
2. A wear test repeats the everyday action many times, like 200 zips or 50 lid closures, then looks for cracks, loose joints and worn paint.
3. An ergonomic test checks the product against real bodies: can a Year 7 hand grip it, does it slide into the school bag pocket.
4. Environment tests put the product where it will live, so an outdoor planter gets watered and left in the sun instead of tested on a dry bench.
5. Photograph the setup and the failure, since a picture of a snapped 3 mm plywood tab is stronger evidence than a sentence about it.
6. Safety comes first where there are sharp edges, heat or small parts, and a legitimate test result is "stopped, unsafe".

Testing a Digital Product: Tasks, Devices and Speed

1. Digital solutions are tested by handing a user a task, such as "find the Year 9 timetable", and timing them while they try.
2. Record where they hesitate, what they click first, and whether they finish without help, because the path matters as much as the finish.
3. Compatibility testing runs the site or app on the devices your client actually owns, for example an older school iPad in Safari and a Windows laptop in Chrome.
4. Performance testing measures load time on the school wifi with a stopwatch or the browser network tab, not on your fast connection at home.
5. Function testing walks every button, link and form field one at a time with a tick or a cross, so broken paths cannot hide.
6. For games and animations, test on the slowest machine you can find, because 60 frames per second on your laptop may be 20 on theirs.

A Test Plan a Moderator Can Follow

1. The test plan is what proves the tests were designed in advance and not invented afterwards to fit the results.
2. Written properly, another student could pick it up, run your tests and get numbers you could compare with yours.
3. Keep it in your design folder with dates, so the order of testing, changing and retesting stays visible.