The computer scientist Edsger Dijkstra made a precise and important observation: testing can show the presence of bugs, but never their absence. No matter how many tests pass, you cannot prove from testing alone that the program is correct for every possible input — because the number of possible inputs is usually infinite and you can only test finitely many of them.

This does not make testing pointless. It means that testing gives you increasing confidence, not certainty. The more diverse and deliberate your tests — covering typical cases, edge cases, and cases designed to stress the program's logic — the higher your justified confidence. Formal proof of correctness exists as a discipline (called formal verification), but for the programs in this course, well-designed testing is both sufficient and professionally standard.

In professional software development, these categories map loosely onto a larger taxonomy. Functional and boundary testing are forms of black-box testing — you test the program's behaviour without looking at the internal code, only at inputs and outputs. This contrasts with white-box testing, where you design tests based on knowledge of the code's internal structure — making sure every branch of every conditional is exercised, for example.

User testing in professional contexts is part of usability testing and UX research — a discipline with its own methodologies for recruiting representative users, designing observation protocols, and analysing qualitative data. Playtesting is similarly established in the game industry, often conducted in dedicated labs with video recording and eye-tracking equipment. The techniques in this course are simplified versions of real professional practices.

The test structure above — input, expected output, actual output — is the structure of every unit test in frameworks like pytest. In pytest, the tests are written as functions, and the comparison is made with an assert statement:

def test_classify_score():
    assert classify_score(85) == "Merit"
    assert classify_score(70) == "Merit"
    assert classify_score(65) == "Pass"
    assert classify_score(50) == "Pass"
    assert classify_score(49) == "Fail"

When pytest runs, it calls every function whose name starts with test_, executes the assertions, and reports which passed and which failed. This automation means a test suite of hundreds of cases can be run in seconds. The manual approach in this course produces exactly the same thinking — the framework just runs it faster and keeps a record automatically.

Boundary testing is grounded in the observation that the density of bugs is much higher near boundaries than in the middle of a valid range. A grade classifier that works correctly for scores of 55, 65, and 75 almost certainly works correctly for 58, 63, and 72 as well — because the same code path handles all of them. But the code path that handles 50 might be different from the code path that handles 49, because there is a condition boundary between them. The boundary is where the code makes a decision, and decisions are where mistakes are made.

This is formalised in the testing concept of equivalence partitioning: divide the input space into regions (partitions) where the program behaves identically, then test one value from each partition plus the boundary between adjacent partitions. If a function behaves correctly for one value in a partition, it is likely correct for all values in that partition — so testing the representative and the boundaries gives maximum coverage with minimum test cases.

The principle behind staying quiet during user testing is that you are trying to observe behaviour in its natural state. As soon as you explain, help, or correct, you have changed the thing you are studying. The user is no longer interacting with your program; they are interacting with your program plus your explanation. This is called the observer effect in research methodology — the act of observation changes the phenomenon being observed.

Professional usability researchers use a technique called think-aloud protocol: they ask users to narrate what they are thinking as they use the product, without the researcher responding. This gives a continuous stream of qualitative data about the user's mental model, their expectations, and where those expectations are violated. For Grade 9 projects, a simplified version — asking the user to say out loud what they are trying to do, without the developer responding — produces similar insight without formal training.

Playtesting as a formal discipline emerged from the board game and video game industries, where the gap between a designer's intention and a player's experience can be enormous. A mechanic that feels elegant to the designer — who has deep familiarity with the system — can feel arbitrary or confusing to a player encountering it for the first time. Playtesting is the systematic process of discovering and closing that gap before release.

The distinction between intended experience and actual experience is the central design question that playtesting answers. A related concept is emergent gameplay — behaviours and strategies that arise from the rules of a game that the designer did not explicitly plan for. Sometimes emergence is delightful (players invent creative strategies), sometimes it is a problem (a strategy makes the game trivially easy). Playtesting is how you find out which kind of emergence your game has.

In professional software engineering, regression testing is almost always automated. A test suite runs automatically every time code is committed — a practice called continuous integration (CI). If any test fails, the team is notified immediately and the failing code is not merged into the main codebase until the regression is fixed. This makes the cost of regression nearly zero: failures are caught within minutes of being introduced, by the person who introduced them, while the change is still fresh in their mind.

The alternative — manual regression testing performed periodically — is far more expensive. By the time a regression is discovered manually, it may be days or weeks old, introduced by any of dozens of changes, and require significant investigation to locate and fix. Automation does not change what regression testing finds; it changes how quickly it finds it.

The IB MYP Design cycle asks students to evaluate against criteria they set themselves in Criterion B — not against a generic standard. This means the quality of your Criterion D evaluation depends in part on the quality of your Criterion B criteria. Criteria that are vague ("the program will be good") cannot be tested. Criteria that are specific and measurable ("the program will return the correct classification for any integer score between 0 and 100, including boundary values") can be directly tested and the results directly reported.

This is one of the reasons that learning to write specific, testable criteria is a skill developed deliberately in this course. A criterion you cannot test is a criterion you cannot honestly evaluate. The connection between Criterion B and Criterion D is not administrative — it reflects a genuine principle in engineering and design: you must define what success looks like before you can determine whether you achieved it.