Integration Scenarios, Scoping Use Cases or even simply collections of related User Stories form pathways through a system. Often these requirements form an intentional logical flow through a system. Sometimes this flow is called a "basic flow" or a "happy path" and is the primary input to development. Typically this workflow is the most tested workflow because it's tested during development and is the most "obvious" path through the system. Although testing this plain flow is necessary, as it typically must work, bug density and quality risk exposure tend to be relatively low. Testing of these flows is often automated and, even if manually tested, are normally required to pass testing at the lowest levels of done.
Often these workflows will have a number of alternative paths, expressed as User Stories tracing back to the same high level requirement or simply defined in an Integration Scenario. These work flows are intentional alternates to the simple, or normal, operation of the system. Since these alternates have been considered prior to development they again are likely to be tested as part of normal development and again can be often automated and part of low levels of done. In Use Case based processes bug density was typically higher in alternative flows, but in User Story based processes there isn't an explicit definition of a "basic flow" vs. "alternative flows" amongst stories so bug density (and quality risks) tend to be more consistent.
Fringe Cases, especially those across Integration Scenarios, are the paths through a system that haven't been written down and are often sources of higher bug density and quality risks. Professional test techniques, such as exploratory testing, are often designed to draw out Fringe Cases and professional testers (as opposed to developers doing testing) can be very skilled at finding Fringe Cases. Sometimes random techniques can be used to try to find Fringe Cases such as a "Chaos Monkey" or "Random User Simulation".