What kinds of errors to look for
A checklist of the kinds of errors worth testing, with example case titles and priorities, and how to decide what to automate first.
This page is general QA advice, not a feature of Qably. Use it as a checklist when you plan a feature: walk through the kinds of errors below and write a case for each one that could hurt your users.
The kinds of errors worth looking for
| Type | What to look for | Example case title | Suggested priority |
|---|---|---|---|
| Functional (happy path) | The main flow does what the feature promises, with ordinary data. | Creates an order from a valid cart | Critical |
| Input validation and boundaries | Required fields, minimum and maximum lengths, the value just inside and just outside each limit. | Rejects a password of 7 characters | High |
| Negative paths and error handling | Wrong password, expired session, a service that does not answer. | Shows an error when the payment service times out | High |
| State and workflow | Steps out of order, the same action twice, going back, retrying. | Charges an order once when Pay is selected twice | Critical |
| Permissions and roles | Each role sees and does only what it should; one account cannot reach the data of another. | Denies access to the invoice of another account | Critical |
| Integrations and contracts | API responses, webhooks and third-party calls: status codes, fields, formats and behavior when the other side is slow or wrong. | Returns 404 for an order that does not exist | High |
| Data | Empty values, very large values, special characters, dates, time zones and rounding. | Saves a name with an accent and an apostrophe | Medium |
| Regressions | Every bug you fix. Add a case for it so it cannot come back unnoticed. | Applies a coupon only once per order | That of the original bug |
The priorities are a starting point. The same kind of error changes priority with the feature: validating the amount of a payment is Critical; validating the biography of a profile is Low.
Write each title as in naming tests: an active verb plus the expected condition, one behavior per case. "Rejects a password of 7 characters" can fail for one reason; "validates the password" can fail for ten.
From one feature to a list of cases
Resetting a password by email looks small, but walking through the table gives at least six cases:
- Functional: sends a reset link to a registered email address.
- Validation: rejects a malformed email address.
- Negative path: shows an error when the email service is unavailable.
- State: rejects a reset link that was already used.
- Time: rejects a reset link after it expires.
- Data: accepts an email address written in capital letters.
Not every kind applies to every feature. Skip the ones that do not apply and write the rest.
What to automate first
You cannot automate everything at once. Start where a failure costs the most or happens most often:
- Critical flows. Signing in, paying, and the actions that move money or data.
- Areas that already broke. A module that had three bugs last quarter is likely to have a fourth.
- Stable behavior. A test on a screen that is redesigned every week costs more to maintain than it saves.
Leave exploratory checks, one-off visual reviews and features that are still being redesigned as manual cases. Qably keeps manual and automated cases in the same suite, so both stay documented in one place.
What Qably does afterwards
Your CI sends each report to Qably, so every automated case builds a result history. The signals of a case show which ones need attention. When a case that used to pass starts failing, reading a regression explains how Qably compares two runs and which commits are candidates. To write the cases and choose their priority, see how to write a test case.