Testing Like a User
You built something. You click through it. Everything works. Then a classmate tries it and immediately gets stuck on step one. What happened? You tested it the way a builder tests — you already knew where to click, what to type, and what to expect. Your classmate had none of that knowledge. They tested it the way a user tests. These are two completely different experiences of the same product, and only one of them matters for shipping.
Builder Testing vs. User Testing
Builder testing means you check that your code does what you intended. You know the happy path — the sequence of steps that goes perfectly. You follow it and it works. You mark it done. User testing means watching someone who has never seen your project try to use it with no guidance from you. The user does not know the happy path. They read labels, guess at what buttons do, and try things in unexpected orders. User testing reveals confusion, missing instructions, broken edge cases, and assumptions you baked in without realizing it. Both kinds of testing matter. But before you ship, user testing is non-negotiable.
An edge case is an input or situation that falls outside what you expected when building. Example: you built a quiz app expecting users to type a single word. An edge case: a user types nothing and presses Submit. Another: a user types 500 characters. If your app breaks on edge cases, users will find them.
Here is a five-step user testing routine you can run before shipping any project: 1. Find one real person who has not seen your project. 2. Give them a one-sentence goal: 'This is a vocabulary bot — try to get a definition for any word you want.' 3. Say nothing else. Do not help, explain, or point. 4. Watch exactly where they pause, hesitate, or fail. Write those moments down. 5. After they finish (or give up), ask: 'What was confusing? What did you expect to happen?' The pauses and failures in step 4 are your bug list. They are more valuable than any testing you could do on your own, because your own knowledge of the project blinds you to its gaps.
Testing with AI-Built Projects
When an AI helped you build something, there is an extra testing responsibility. AI-generated code often handles the expected case cleanly but fails on edge cases the AI did not anticipate. The AI built from your prompt — and your prompt described the happy path. Nobody told it about the user who types nothing, or the user who pastes in an entire paragraph, or the user on a phone whose keyboard behaves differently. After any AI-assisted build, deliberately try to break your own project: Type nothing and click Submit. Type something very long. Click every button twice. Refresh mid-flow. Open it on a different device. Each test that reveals a bug is a win — you found it before your users did.
The most dangerous tester is yourself. You will unconsciously avoid the actions that break the app because you know they are wrong. Real users do not know what is wrong. Sit on your hands and let someone else try it before you call it ready to ship.
Fill in the blanks to complete the testing principle.
What is the main reason builder testing is not enough before shipping?
A student builds a calculator app. During testing, she types a letter instead of a number and the app crashes. What kind of issue is this?
Break Your Own Project
- Step 1: Choose any project you have built or a classmate's project.
- Step 2: Spend three minutes trying to break it. Try: submitting empty inputs, clicking every button, using it on a phone, typing very long text, refreshing the page mid-way.
- Step 3: Write down every moment the app behaved unexpectedly, broke, or confused you.
- Step 4: For each issue, write one sentence describing what should happen instead.
- Step 5: Prioritize your list: which issue would most frustrate a real user? Fix that one first.