In addition to being a great way to elicit the complete scope of a project, the Event/Response methodology delivers a framework for test planning and execution. When using this methodology, what many call “User Acceptance Testing” can be replaced by the term “Event Testing”.
In my prior posts on this topic, I identified the primary deliverables of the Event/Response methodology as (1) the Event List (containing the event that triggers the response, the origin and data content of the information flow into your “business”, the named processes, the outputs of the processes and the destinations of the outputs) and (2) the Use Cases. You can plan to test by simulating the actual Events, creating the data flows, executing the processes and examining the outputs. The Use Cases give you a good start on creating the data and usage variations for each Event. Doing this yields a direct mapping of the scope and requirements to the test cases and execution.
Note that since the Event List also contains the roles of the actors initiating the events, as well as the roles receiving the outputs, security testing is also built into this framework.
Another major plus of planning and executing the tests this way is that you are testing the system as it will actually be used in context, as opposed to functional testing which tests bits of functionality in isolation.
A recent project of mine used this methodology and yielded 180 Events and over 1,600 test cases. Because of this comprehensive approach, the system was very well tested and only experienced minor problems after implementation.