Yesterday you caught a boundary bug and filed a report a developer could act on without asking you a single question. Today the store lies to you on the screen, and you catch it in the layer underneath.
You are going to hear, probably in your first month, that manual testing is dying and you should skip straight to automation. That advice is wrong, and it will slow your career down. Manual testing is where you learn to see a product, and the product is much more than the screen.
Layer 1: the requests
Open Tumble Kitchen, press F12 (or right-click and choose Inspect), and open the Network tab. That panel shows every request the page makes to fetch data. Now search for “patty” and watch a request appear: products.json, with your query on the end as ?q=patty. Notice the request only fires most of a second after you click; the store’s supplier is slow on purpose.
You do not need to be technical to use this panel, and half of “the app feels broken” reports live in it. Three things to read on any request: did it succeed (status 200) or fail (a 4xx or 5xx error), how long it took, and whether it fired at all. A search box that never fires a request is a very different bug from one whose request fails, and knowing which you are looking at makes your report twice as useful.
Layer 2: the promise under the screen
The bug I keep coming back to, across every product I have tested: the screen said the right thing while the system underneath did the wrong one. The button works, the message appears, everything feels fine. Then you check the actual record and the product did not do what it claimed. Test the promise, not just the screen.
Tumble Kitchen has one of these, and you have everything you need to catch it:
- Add three dishes to your order, apply IRIE20, and note the total.
- Now remove one item.
- Read the numbers slowly. The item is gone. The subtotal updated. The total did not.
The screen happily shows a total that no longer matches the cart. A shopper who removes an item and pays would be charged the stale amount. The subtotal told the truth and the total lied, on the same screen, at the same time. File it; you know how since yesterday. In your report, the pairing of “subtotal correct, total stale” is the detail that points the developer straight at the cause.
The same plate, two prices
Everything so far has been the cart. Now open a single dish. A dish page is the page for one dish on its own: its picture, its description, its ingredients, and its price, all in one place. You reach it by clicking a dish on the menu.
Do this on the menu. Find the Fried Chicken Plate, note the price shown in the list, 1,600 JMD, then click the dish to open its own page and read the price there. It says 1,650 JMD. Same plate, same shop, two prices, fifty JMD apart.
That is a data-integrity bug. Data integrity means the facts a product shows about one thing all agree with each other. Here the menu and the dish page disagree about a price, so the shop is arguing with itself, and a shopper cannot tell which number is real. Notice that the dish page looked perfectly ordinary on its own. It read wrong only next to the menu. Test the promise the menu made, not just the screen in front of you.
The same page, tested with the keyboard
Now stay on that dish page and test it a second way. Accessibility means the shop works for people who do not use a mouse or a screen, including people who move through a page with the Tab key and people who use a screen reader, which is software that reads the page out loud. Put your mouse away and try three things:
- Press Tab again and again to walk through the page, and watch where the highlight lands. It never reaches the “Rate this dish” stars, so a shopper using only a keyboard cannot leave a rating at all.
- Find the small heart button that saves a dish as a favourite. It is only a symbol with no words attached, so a screen reader announces nothing when it lands there. A blind shopper hears an unlabelled button and cannot tell what it does.
- Look at the “You might also like” pictures near the bottom. Each one is missing its alt text, the short description a screen reader reads out in place of a picture. The screen reader reaches those images and has nothing to say.
None of that shows in a screenshot, and all of it shuts real people out. My Visual QA Checklist has the checks that catch exactly this: a control you cannot reach with Tab, a button with no label, a picture with no description. Run it down a dish page and it names each one.
Layer 3: everything else a human checks
- Accessibility. Put the mouse down. Get from the search box to a filled cart to Place order using only Tab and Enter. If you get stuck, so does every user who cannot use a mouse.
- Real devices. Open the store on your actual phone. Screens, thumbs, and slow connections find different bugs than a resized desktop window.
- The release itself. The unglamorous questions that prevent expensive mistakes: what build is this, what environment, was the fix verified on the thing actually going out? Releases taught me to love those questions.
The screen can look perfect while the data is wrong, the flow is confusing, and the build is the wrong one. Manual testing is the skill of checking all of it.
Do this today
File the stale-total bug properly, and this time include what the network tab showed while you did it (no failing request at all, which itself tells the developer the bug is in the page, not the server). After any action that claims to save or change something, verify it actually did. Both sides, every time.
Then open the Fried Chicken Plate from the menu, write the two prices side by side, 1,600 on the menu and 1,650 on its own page, and file that mismatch as its own report. While you are on the dish page, put your mouse away for one minute and Tab through it, so you feel for yourself how the star rating cannot be reached.
Then spend ten minutes with my API Testing Checklist. An API is the address a page calls to fetch its data, the same thing you just watched in the Network tab. The checklist page has a live console where you can fire a real API request yourself and read the response, which turns the network tab from a mystery panel into a tool you own.
Tomorrow, exploratory testing: the skill that finds what no checklist told you to look for.