Exam practice

• User story: a need written from a user’s side, in one sentence: who, what they want to do, and why. “As a passenger, I want to see when the next microbus to Bhaktapur leaves, so that I don’t wait at the stop for nothing.”
• Acceptance criterion: an exact condition that shows a story is done, which can be tested. “Given it is 4:10 pm, when I open the stop’s page, then I see the next three departures after 4:10.”
• Prototype: an early, rough version of a design, made to test and learn from, not to keep. Paper sketches of the bus app’s screens, tapped by a tester.
• Stakeholder: anyone affected by the app, or who can affect whether it succeeds, whether or not they use it. The microbus drivers and their association, if the app shows their departure times.
• Data minimization: collecting and storing only the data the app really needs, and showing it only to those who need it. The bus app needs no passenger names or phone numbers at all.

• i.“Tell me about the last time you looked for a tutor. How did you find one?” The original asks for a guess about the future, which people answer kindly with yes.
• ii.“What do you pay for tuition now? How did you decide it was worth it?” The original is leading: it tells the person the answer you want.
• iii.“What have you paid, in the last year, to find tutors or classes, and how?” The original asks people to price something that doesn’t exist yet; what they have already spent is evidence.

Stories (any good ones, each with who, what and why):

• S1. As a student, I want to order my tiffin before the break, so that I don’t spend half the break in the queue.
• S2. As a student, I want to see what is still available, so that I don’t order something that has run out.
• S3. As the canteen didi, I want a list of orders by class an hour before break, so that I can prepare them in time.

Acceptance criteria for S1:

• Given it is before 10:30 and chowmein is available, when I choose chowmein and confirm with my class and roll number, then the order is saved and the app shows my order number and where to collect it.
• Given it is after 10:30, when I try to order, then the app tells me ordering has closed for today, and no order is saved.

• Roles: a facilitator gives the task and keeps quiet; a note-taker writes what the tester does and says, and the times; one member plays the computer, putting down the next paper screen when the tester taps a drawn button.
• At the start: thank the tester; say we are testing the app, not them, and that anything hard is the app’s fault and is what we need to find; ask them to think aloud: say what they are looking for and what they expect.
• The task: a goal from a user story, in the user’s words, such as “Get a used Grade 9 Science book kept for you.”
• When stuck: don’t help; ask “What would you do if I weren’t here?” If they would give up, note that as a finding.
• The task must not say where to tap because then the test only shows whether the tester can follow instructions; real users will have no one to tell them, so the test must show whether they can find the way alone.

The list of books is shared: when one student keeps a book, every other student’s phone must show it as kept. If each phone kept its own list, nobody would see what others had done: two students could keep the same book on their own phones, and both would arrive at the library on swap day expecting it. Deciding who gets a book must happen once, in one place that every phone asks and believes: the server.
An app that needs no server: a bill splitter, a timer or a unit converter. It works for one person on one phone, with nothing shared with anyone else and nothing that must be decided fairly between people.

A server handles many requests at the same time. With two steps, two students’ requests for the same book could both run their SELECT before either runs its UPDATE: both see the book is free, both UPDATE, the second overwrites the first, and both are told the book is theirs. This is a race condition (Unit 4).
The single statement checks and changes in one step the database won’t let anything come between. Only one of the two requests finds kept_for still empty and changes the row (rowcount 1); the other changes nothing (rowcount 0) and is answered 409, “Someone has just kept this book.”

Odd statements (answer − 1): 4 − 1 = 3, 5 − 1 = 4, 4 − 1 = 3, 4 − 1 = 3, 5 − 1 = 4; total 17.
Even statements (5 − answer): 5 − 2 = 3, 5 − 1 = 4, 5 − 2 = 3, 5 − 3 = 2, 5 − 2 = 3; total 15.
Points: 17 + 15 = 32 of 40. Score: 32 × 2.5 = 80, above the average of about 68.

• Finished: 4 of 5, met (target 4 of 5).
• Median time: the four times sorted are 2:10, 2:40, 3:30 and 4:50; the median is halfway between 2:40 and 3:30, that is 3:05: just over 3 minutes, not met.
• Median SUS: the five scores sorted, the middle is 70: met (target 68).

Summary: “With five testers, the app met two of its three targets: four finished and they rated it about average, but the typical time was just over the 3 minutes we aimed for, so we will look at where testers spent the most time.”

• Privacy: a student’s phone number shown on a list anyone in the school (or anyone the address reaches) can open, without them choosing it.
• Safety: younger students and their parents said in the interviews that they didn’t want to meet strangers; a phone number invites exactly that, and could be misused by anyone who found it.
• Fairness: givers would be pestered by whoever messaged first; students without a phone or data couldn’t take part in the arrangements at all.
• (Honesty is not the issue here.)

The need behind the button was getting the book from the giver to the taker. The app meets it through the library: givers hand in books there, takers keep one in the app, and the librarian hands them over on swap day, checking the student’s ID card. Nobody needs anyone else’s number.

1. (i) The hidden button: version 2, first. It stops some users completely, those on the cheapest phones, and is probably a small layout fix (put the button above the keyboard, or let the page scroll).
2. (iv) The word “Submit”: version 2. It slowed or stopped two of five testers; changing the word (or showing it in Nepali) is a small change. Test the new word with users.
3. (ii) Dark mode: later. One tester’s wish, and the app works without it. Note it and see whether others ask.
4. (iii) Names beside scores: no, with the reason. Showing every student’s score to everyone is a privacy harm, and it shames weaker students more than it motivates them; it would make the app worse for many of its users. Offer something that helps instead, such as each student seeing their own progress.

A funnel counts how many people (or items) reach each step of the same journey, in order, so that the team can see where they drop out. It shows where something goes wrong, and how big the drop is, without recording who anyone is. It can’t say why people stopped.
To find out why, the librarian asked six of the students whose books weren’t collected. Four had been away at their village over the holiday and came back after swap day. So the team added a second, smaller collection day in the first week of school (in version 3).

• The testers have learned the app: they know where things are from version 1, so they are quicker and make fewer mistakes, whether or not version 2 is better.
• They may want to please the team, having seen it work hard on their feedback, and rate the new version kindly.

A fair comparison uses new testers like the real users for each version, the same tasks, the same measures (completion, time, errors, the same questionnaire given the same way), and targets written before testing. With five testers, report counts and medians, and claim only what so few people can show.