The card below is the “product under test”. Use guided mode to see the bug list upfront, or blind mode to find them yourself first.
Techniques: Error guessing, Decision table testing
👥
KiwiConnect
Create your account
Error
Your findings
0 / 0 bugs foundTick each bug as you confirm it on the page above. Progress saves automatically.
Write down every bug you find. Be specific — where it is, what’s wrong, what it should be.
Planted bugs (5)
- The error message is a single word: “Error”. It gives no context about which field failed, what rule was violated, or what action the user should take. Good error messages are specific, actionable, and field-level where possible.
- An empty red-bordered div is rendered above the form even when there are no errors. This creates visual clutter and trains users to ignore error styling because it appears even on a fresh page load.
- The password helper text reads “Must meet requirements” but never lists what those requirements are. The user must guess whether they need uppercase, numbers, symbols, or a minimum length. Requirements should be visible before typing begins.
- The “Error” message is visible on initial page load, before the user has typed anything or clicked submit. Error messages should only appear after a validation event (blur, submit, or explicit check).
- There is no visible feedback when the password and confirmation password fields contain different values. The form should show a real-time or on-submit mismatch message such as “Passwords do not match”.
Error message testing: check timing (when do they appear?), specificity (do they say what’s wrong?), location (are they near the failing field?), and tone (are they helpful, not accusatory?).