Build end-to-end test cases

In parallel, you should also identify end-to-end test cases for the system. The goal of these test cases is to test data entering and flowing through your system. These test cases should include every integrated application.

For example, one end-to-end test case could be entering or capturing orders in Sterling Call Center. As part of the order capture, the test would call systems to validate and authorize payment, and possibly to conduct fraud check, validate shipping addresses, and so on. Next, the test could move the order to the Distributed Order Management for fulfillment.

A significant component of this activity will involve defining the test cases, developing the test data and configuring the applications to support the tests, and writing stub code to implement the necessary integration. The benefit in investing in this early is that the tests can be used to validate your system architecture. More importantly, these test cases can be reused as you start to incrementally harden or secure your system. Knowing that functionality worked in your baseline environment, and not in the subsequently hardened system, will help you isolate the root cause. The converse means that running these tests the first time on a hardened system will make problem diagnosis much harder.