Quality Money Management : Process Engineering and Best Practices for Systematic Trading and Investment

(Michael S) #1

216 CHAPTER ◆ 2 3 Check Performance and Probationary Trade


historical data, the SPC charts from Stage 2 and Stage 3 should be nearly identical. The
stability of the system using prototypes must be very, very similar to that using the pro-
duction software if the system is to pass Gate 3.

23.3. LOOP 2: Test Data and Graphical User Interfaces


In Loop 2, the development team has built and tested the presentation and data interface
layers. Now the traders and financial engineers, along with a risk manager, will perform
QA for validation and verification of the GUIs, integration, and reports. The traders
should run live data examples between prototypes and the coded implementation using
regression. To accomplish this task, the traders will need, say, 1000 snapshots of real data
in the correct format. The traders can run this data through the system to make sure GUIs
and graphs and reports are running properly.
Auditing the presentation and data interface layers and the development team ’ s integration
testing will uncover data mapping issues, error handling issues, data cleaning issues, and
anything unexpected using real-time data. Using inputs and outputs, the traders test:

● GUIs by changing user-defined data, or putting in error/boundary conditions. Does
the system catch it and respond correctly?
● Reports through interactive testing using scenarios. Are reports coming out correctly?
Are the graphs and colors right? Does printing work right?
● Data integration to search for truncation errors. What happens if a bond has a name
longer than 20 characters. Does it get truncated? What happens if the portfolio
grows from $100 million to $10 billion? Does the data or do fields get truncated?

GUIs and reports will change after implementation. Over the following year, GUIs and
reports will evolve to help the traders better manage the system. QA testing must also test
for supportability and the modifiability of GUIs and reports over time.

23.4. LOOP 3: Perform Final Audit and


Probationary Trade


In Loop 3, the development team has built the hardware and network infrastructure to
house the trading/investment system and performed system tests. The product team, led
by the traders, must verify that the operation, functionality, and quality attribute requirements
are met. Acceptance testing refers to the functional testing of a working trading/investment
system by the product team prior to implementation. As the customer, the product team
runs black box scenarios to test different components and behaviors of the system and
whether those components have been correctly implemented. A component or behavior
can have one or more user acceptance tests, whatever it takes to ensure that it works to
specification. Each acceptance test must have a predefined, expected result. The product
team is responsible for verifying the correctness of these tests and reviewing test results to
decide which tests failed and which ones succeeded. As always, acceptance tests should
include regression tests of the outputs of the system against Stage 2 results.
The product team ’ s user acceptance tests confirm through trial and review that the sys-
tem in its entirety meets the specification requirements and quality attribute requirements.
Free download pdf