At a glance
Solo, with a play-tester and one paired workday · six working periods mid-course · play-tested in class twice, in threes and then across the room · one Python program plus a test log
What you are making
A quiz program in Python on a topic you genuinely care about — a sport, a band, a game, a language, your neighbourhood. It asks questions, reads answers, checks them, keeps score, and gives feedback, and it must use Conditionals and at least one loop.
Checking answers is where the craft lives — exact matching rejects
"ottawa" because you typed "Ottawa", so your checker forgives it:
guess = input("What is the capital of Canada? ")
if guess.strip().lower() == "ottawa":
score = score + 1Then a classmate play-tests it, and every piece of their feedback is either addressed in the code or logged in an honest known-issues list.
How to work
- Choose the topic — the test is that you would happily talk about it at lunch. Write your questions and accepted answers on paper first.
- Build one question end to end — ask, read, check, score — and get it working before you write ten. The Password Checker is full of checking patterns worth borrowing.
- Add forgiving matching, so spacing and capitals never cost a point. Decide, and comment, what your checker forgives and what it does not.
- Notice the repetition — question two looks like question one. That pattern is your loop. Comment as you go, in the spirit of Writing Good Comments: a stranger should follow your checker.
- Add the final score and feedback that actually says something — “7 out of 10, your goalie knowledge is elite” beats a bare number.
- Play-test in class: your classmate plays while you stay silent and take notes. Address each finding or log it honestly. The building happens in the working periods, at a keyboard I can stand beside, which is the only way I ever get to watch anybody debug — How Marks Work explains why that counts as evidence.
Success criteria
| Quality | What it looks like in your program |
|---|---|
| A topic that is yours | The questions could only have been written by you |
| Runs end to end | A player gets from first question to final score |
| Forgiving checking | Spacing and capitals never cost a correct player, and the rule that decides it reads in one line — and, or and not where you need them |
| Structures where they are needed | Each conditional is there because something has to be decided, and the loop is there because something would otherwise be typed out again |
| Built for diverse players | Prompts and feedback are clear, forgiving of capitalization and spacing, and tested with diverse classmates |
| Readable throughout | Comments let a stranger follow the checking logic |
| Feedback honoured | Every play-test finding is fixed or honestly logged |
Reflect
Write a Dev Journal entry after the play-test: what did your tester find that you could not have found yourself, and why not? Your tester did you the favour of not knowing what you know.
If your program only half-works (click to expand)
Ship the half that works, with a known-issues list naming the half that does not. A readable program with honest known bugs outscores a flashy one nobody can follow — that is the rule in How Marks Work.
Curriculum connection
A1.3
develop computational artifacts for a variety of contexts and purposes that support the needs of diverse users and audiences
Link to original
C1.5
identify and explain situations in which conditional and repeating structures are required
Link to original
C2.3
write programs that include single and nested conditional statements
Link to original
C2.4
write programs that include sequential, selection, and repeating events
Link to original
C2.5
write programs that include the use of Boolean operators, comparison operators, text operators, and arithmetic operators
Link to original