A label for a path that starts with the first action and finishes at the result a person or another system can observe. Every queue, service, and handoff in the middle stays inside that same path. A check that stops at one function, one team, or one contract between two components is a smaller slice of the work.
How the Boundary Is Drawn
The boundary is a choice about where the path begins and where it is allowed to end. Teams name those two points before they measure the path, or the phrase collapses into a vague claim that the work is complete.
- Start. The event a customer, employee, or outside system initiates, such as placing an order, submitting a form, or sending a message.
- Middle. The services, people, and queues the work crosses. The finish still has to be an outcome the starter can see, or the path has been cut short at an internal handoff.
- Finish. An outcome that can be confirmed without opening an internal log: a shipped item, a posted balance, a delivered message, or a screen the person was promised.
How Wide the Check Is
Width is the number of steps kept inside the path. A wider check catches a broken handoff. It also takes longer to run, and it tells you less about which step failed.
| Scope | What It Covers | What It Leaves Out |
| One function | A single calculation or rule | Every neighboring service |
| A contract between two parts | The request and the response those parts agreed to | The screens and the rest of the business process |
| The full path | The first action through the observable result | Almost none of that path, so the failing step is harder to name |
Where the Path Shows Up
A customer journey uses the phrase when the path runs from the first request through billing, fulfillment, and the notice that the request is done. A supply path uses it when the order ends as a receipt in the buyer’s hands. A message uses it when protection holds from the sender’s device to the recipient’s device, which is End-to-End Encryption (E2EE).
How a Test Uses the Same Idea
Quality assurance (QA) uses the phrase for a test that starts in the user interface (UI) and asserts the outcome after the real services have run. The test is broad, so it is slower than a check of one function, and a failure points at the path rather than at one line of code. User acceptance testing (UAT) is a related gate: the people who will live with the product exercise a finished flow and accept or reject it.
A build pipeline may run a small set of these flows after continuous integration (CI) produces a build, and again before continuous delivery (CD) promotes that build. The suite stays short on purpose. A long suite of full paths is expensive to keep green.
Reading a Failed Result
A failed full-path check says the outcome did not happen. It does not name the step. Teams keep a shorter test beside it so the same break can be traced to one service, one application programming interface (API), or one screen. The full path stays in the suite because a green set of small tests can still miss a handoff between them.