Learning Objectives
By the end of this lesson you will be able to:
- Navigate the Test Case Generator interface confidently
- Understand what each result option (Number, User input error, Application error) means
- Recognize the three testing techniques used to design the cases
- Know exactly when XP and your badge are awarded
The Test Case Generator Interface
When you open a challenge, you'll see the same familiar layout from the Guided Tests lesson — but with a twist. Instead of typing values, you select them.
The screen is organized into three practical zones:
- A top progress row with six dots, where each dot represents one test case
- A left-side test case area with three dropdowns (Option 1, Option 2, Expected Result) and a Validate Test Case button
- A right-side read-only preview panel that mirrors the currently selected values so you can review your choice before validation
The Three Dropdowns
Option 1 and Option 2 — the two inputs you're feeding to the multiplication form. Each case presents a specific value from a curated set that covers different input categories.
Expected Result — your prediction of what the application should do with those inputs. You have three choices:
| Result | Meaning |
|---|---|
| Number | The application successfully calculates and returns a numeric result |
| User input error | The input is invalid (e.g. text where a number is expected, or empty) — the app should reject it with a validation message |
| Application error | The input is technically parseable but causes the application to behave unexpectedly — an overflow, an unhandled edge case, or a crash |
Pro Tip: "Application error" is the most interesting category to a tester. It reveals gaps between what a developer assumed would be input and what a user might actually type.
The Testing Techniques Behind the Cases
The 6 test cases in the Number Multiplication challenge weren't chosen at random. They are designed using three classic testing techniques. You don't need to master these now — they'll be covered in depth in future courses — but it helps to know their names:
- Equivalence Partitioning — dividing inputs into classes where the system should behave identically, then picking one representative from each class
- Boundary Value Analysis — testing at the edges of valid and invalid ranges, where bugs love to hide
- Error Guessing — using experience and intuition to predict the inputs most likely to cause a failure (empty values, special characters, extremely large numbers)
These three techniques together cover the most common sources of defects in any input-handling feature.
Reading Feedback After Each Submission
When you click Validate Test Case:
- All fields turn green — your prediction was correct. The case is marked complete and you advance to the next one.
- One or more fields turn red — something is off. The highlight tells you exactly which dropdown was wrong. Correct it and try again.
No points are deducted for incorrect attempts during a practice. The goal is learning, not punishment.
When Are XP and the Badge Awarded?
XP and the "Number Multiplier" badge are awarded only when you complete all 6 test cases in a single session. There is no partial reward — this mirrors how real QA work is judged: a half-tested feature is a bug waiting to happen.
Completing this challenge earns you 8 XP.
Pro Tips
- Read each test case instruction carefully before selecting. The wording is deliberate.
- Use the Live Preview panel on the right to visualize what you're submitting before you commit.
- If you're unsure between "User input error" and "Application error", ask yourself: "Would a well-written application even let this input reach the calculation logic?" If yes — it's an application error.
- You can revisit completed cases by navigating the progress dots; no need to start over.
What's Next
Now that you understand the interface and the logic behind it — it's time to test a real multiplication form. Open the Number Multiplication challenge and work through all 6 cases. The "Test Case Architect" badge awaits.