At most one email a week. Unfollow anytime with one click.
Transcript
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Show transcript
Introduction
Hi, and welcome back. The Sunset Coffee mini cashier is running. But an app that runs isn't necessarily ready for a busy shop. Today we test the cashier with tough scenarios, report bugs to Claude Code, add automated tests, and ask Dimas to try it for a whole day.
Step 1: Write test scenarios
Raka writes test scenarios in Google Sheets. Each row has a scenario, an input, the expected result, and the actual result. Scenario one, a normal sale: two cups, paying fifty thousand, change of fourteen thousand. It passes. Scenario two gets naughty: the total is ninety-one thousand, but only fifty thousand in cash is received. It should be rejected. In reality, the cashier shows change of minus forty-one thousand. That's bug number one. Scenario three: an empty cart, then tapping save. The button should be disabled, but a zero-rupiah transaction gets saved. Bug number two. Scenario four: the save button tapped twice quickly, something very likely to happen when it's busy. The result is two transactions. Bug number three, and the most dangerous, because it makes the recap disagree with the cash in the drawer. Scenario five: the page is reloaded. The transactions are still there. It passes. Scenario six: a hamper paid by QRIS with the exact amount. Change is zero. It passes. So out of six scenarios, three failed. That's good news, because they were found before customers used it. How do you come up with scenarios like these? First, be a careless user: tap the wrong thing, tap twice, or type random input. Second, test numbers at the edges: zero, negative, very large, or exactly at a rule's limit, such as exactly two hundred thousand for the free shipping rule. Third, write down the expected result before trying. If you write it afterward, you tend to accept whatever shows up as correct. You can also ask Claude to suggest naughty scenarios for your project. It often finds situations you hadn't thought of, but deciding which scenarios matter is still up to you and your users.
Step 2: Report bugs to Claude Code
Raka reports the bugs to Claude Code in a three-part format: the steps to reproduce, the expected result, and what actually happened. He also asks Claude Code to find the cause and explain it first, rather than changing things right away. Claude Code reads the test scenario file and the cashier logic file. It finds three causes and explains them in plain words. Change is calculated without checking for too little cash. The save button doesn't check for an empty cart. And the button isn't locked while saving, so a second tap gets recorded too. Here's the change: three green lines, each one answering one bug. Even though we're not programmers, we can guess what they mean: if there's not enough cash, show a warning; if the cart is empty, stop; lock the button while saving. Raka reads the change, then approves it. He retests the three scenarios that failed. All three pass. The result column in Sheets is updated with check marks.
Step 3: Add automated tests
Testing by hand after every change is exhausting. So Raka asks for automated tests: every scenario in Sheets turned into a script, plus six edge-case scenarios suggested by Claude Code. Claude Code writes twelve tests. Six come from Raka's list and six are new suggestions, such as a very large amount of cash received or an item quantity of zero. Then it runs them all. Twelve pass, zero fail, in a matter of seconds. Claude Code reminds Raka of a new habit: run the tests every time you ask for a change, before saving a new version with Git. If something fails, the last change broke something, and we know exactly where to look. Let's sum it up as a cycle. First, find a bug, from the test scenarios or from users. Second, report it clearly: steps, expected, actual. Third, fix it with Claude Code, and read the changes before approving. Fourth, retest, both by hand for the scenarios that failed and automatically for all of them. Fifth, save a version with a Git commit, as in the Advanced Claude Code session. Then the cycle repeats. A good app isn't an app without bugs; it's an app whose bugs are found quickly and fixed safely.
Step 4: A trial by the user
The most important test is done by a real user. Dimas tries the cashier for a whole day at the shop, while still writing paper receipts as a backup. That day there were forty-seven transactions. The good news: the nightly recap matched the cash in the drawer and took only four minutes. Laras's measure of success was met. There are two pieces of feedback. First, the hamper button got pressed by accident because it sits too close to the cold brew button. Raka would never have found this at his own desk. Second, Dimas needs a button to cancel the last transaction, because a customer changed their order. Raka sorts the feedback. Spacing out the menu buttons gets fixed now, because it causes miscounts. The cancel-last-transaction button also gets built now, on the condition that it asks for confirmation before actually canceling, so it can't be pressed by accident. Dimas also mentioned member discounts and ingredient stock. Those are recorded as later features, following the project sheet. This discipline keeps the project finishable. Raka also thanks Dimas and tells him when the fixes will be done. Users who feel heard keep giving honest feedback, and that feedback is the fuel for your project. Raka passes both pieces of feedback on to Claude Code, and asks for a new test for the cancel feature as well. Claude Code adds wider spacing between the menu buttons in the style file. Then it adds the cancel-last-transaction button, complete with a confirmation dialog. The automated tests run again. There are now fourteen tests, and all of them pass. The old features are still safe. Notice a small but important decision: a canceled transaction isn't quietly deleted; it's marked as canceled in the recap. That way, Laras can still match the records against the cash in the drawer.
Step 5: Ready-to-use checklist
Before calling it ready, Raka compares the results with the measure of success in the project sheet. The nightly recap went from thirty minutes down to four. There were no miscounts in forty-seven transactions, checked against Dimas's paper receipts. And all fourteen automated tests passed. These numbers will become material for the presentation. A measure of success written at the start lets us prove the project's value with data, rather than just feeling that it's done. Finally, the ready-to-use checklist. First, all tests pass: fourteen automated tests and six manual scenarios, including the fixes from Dimas's feedback. Second, version one point zero is saved with a Git commit and tag, so if a later change causes problems, we can go back to this version. Third, a CSV export every night as a backup, because data in the browser can be lost. Fourth, a shortcut on the shop laptop's desktop, so Dimas just double-clicks to open the cashier. Fifth, an emergency plan: if the cashier has problems, go back to paper receipts and contact Raka. The screens in this video are simulations, so commands and menus on your screen may differ slightly.
Done!
The Sunset Coffee mini cashier now passes tough scenarios, has fourteen automated tests, and has been used for a day by Dimas with a four-minute nightly recap. Laras's measure of success was met. A good project needs to be explained well. In the next episode we write the documentation and prepare the final project presentation. See you there!
Practice exercises
Try these on your own after watching to lock in what you learned.
Write ten test scenarios for your project, including five 'naughty' ones
Report one bug to Claude Code using the steps, expected, actual format
Ask one user to try it for a full day and note their feedback
Ask the class material
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
My notes
Notes are saved with the current video time and are only visible to you.
Questions & answers
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.
Your instructor
Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
53 video classes1,290 episodes
We build software, BIM models, games and AI automations for clients every day, and turn that hands-on work into step-by-step classes: every step is shown on screen and comes with a PDF guide you can keep.
