Happy path
In software testing, the happy path is the default scenario in which a user does exactly what the feature was designed for, with valid input and nothing going wrong: sign in with the right password, add a product, pay with a card that is accepted. It is the first case tested and the one the specification describes, and everything else, the unhappy paths, is where most of the defects live.
The longer version
The happy path is the route through a feature with no branches taken: no validation error, no declined card, no timeout, no second tab. It is what the demo shows, what the acceptance criteria describe, and what the developer ran before saying the feature was done. As a test case it is the smoke test of the feature. If the happy path fails, the feature is not ready for any other test; if it passes, the feature has been shown to work for a user who does everything right on a good day, and for nobody else yet.
The term is also used in UX and product design for the ideal journey through a flow, and that sense dominates part of the search results; this page is about the testing sense. In testing, the neighbour is the unhappy path, sometimes the sad path: every route off the main one, whether by user error (wrong password), by system error (payment provider down) or by circumstance (the session expired between two steps). A feature has one happy path and many unhappy ones, and test design is mostly the enumeration of the latter. Edge cases are the subset of unhappy paths that occur at the limits of what the feature handles.
A team that ships on the happy path alone has tested the one path anyone is paid to demonstrate. The defects it lets through have a shape: a real user does something slightly wrong, gets an error nobody wrote, and cannot recover. A form that validates the data it expected and crashes on the data it did not. A checkout that handles a successful charge and leaves the order half-created on a declined one. Every one of those passed its happy path test.
Common questions
What is the difference between the happy path and the unhappy path?
The happy path is the single route where the user provides valid input and every dependency responds correctly. The unhappy paths are every other route: invalid input, a declined payment, a timed-out request, an expired session, a double click. A feature has one happy path and many unhappy ones, and most defects are found on the second kind.
Should the happy path be tested first?
Yes. The happy path is the feature's smoke test: if it fails, nothing else about the feature can be tested, so it is run first to establish that the build is testable. The failure is stopping there, since the unhappy paths are where users who make an ordinary mistake find the defects.
Is happy path testing enough?
Enough to show that the feature works when everything goes right, which is the least informative thing a test can show. Real users mistype, lose connection, press back, open two tabs and use the wrong card. A feature tested on its happy path alone fails the first time one of them does, and the failure is usually one the team never wrote a message for.
What is an example of a happy path?
A shopper with an account signs in with the right password, searches for a product that is in stock, adds one to the basket, enters a valid address and pays with a card the issuer accepts, and the confirmation page shows the order number. No step fails and no branch is taken. Every unhappy path starts from one of those steps going differently.
Who decides what the happy path is?
The product owner, through the acceptance criteria, which describe the feature working as intended for a user who does everything right. The tester writes it down as the first scenario and then derives the unhappy paths from it by asking at each step what else the user or the system could do. A happy path nobody has agreed is a tester's guess at the specification.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.