Prior to agile development, requirements gathering for systems was traditionally performed by business analysts discussing requirements with the business, and expressing those requirements in documentation, such as Word specs and perhaps spreadsheets. The acceptance criteria for such requirements were often only sketched out, if at all; it would normally fall to the system testers to write acceptance tests for the requirements, through a mixture of consulting the original (by now out-of-date) requirements documentation and (as often as not) reverse-engineering the implementation.

Scenario testing combines the requirements capture and the acceptance test criteria in a single form, through scenarios. As before, these requirements are in a form that a non-technical domain expert from the business can understand. What differs though is that these scenarios can be used directly exercise the system, and so also represent the acceptance tests for the scenario. Moreover, the results of these tests are rendered in such a way that the business can understand, and thus can help determine if the code is at fault or the test. Once implemented, the acceptance tests also act as a regression suite for the system.

Scenario tests tend to act against a complete system, or sometimes at a subsystem-level. At any rate at a granularity that makes sense to a non-technical businesss person. Compare this to unit testing which exercises the behaviour / method of a single class.

Scenario testing is more usually called "agile acceptance testing", but I find that term rather clumsy. Other names also exist, including behaviour-driven development, and example-driven development. Here we use our own term "scenario testing".