118 CHAPTER ◆ 1 1 Check Performance
more passes over the K|V Stage 1 spiral, the more opportunities there are for errors to be
removed. For code inspection, team size is usually three or four. We recommend the team:● Create a policy requiring comprehensive prototype testing. Testing should consume
25–40% of prototype development time.
● If pretesting is done, look over spreadsheets for errors and sees that error checking
programs are good but should not be used in lieu of comprehensive testing.
● Only use execution testing for regression testing unless the user training and oracle
problem can be overcome.
● Use logic testing for comprehensive testing.For team testing we recommend the following roles be divided among the team:● Author. Developer of the spreadsheet.
● Moderator. Inspection leader.
● Reader, who paraphrases the spreadsheet logic being discussed.
● Recorder, who records spreadsheet errors found during the inspection meeting.
● User. Either a trader, who will use the spreadsheet, or a programmer who will convert
the spreadsheet to code in later stages.11.3. STEP 4, LOOP 1: White Box Test Formulas
As mentioned, all team members are responsible for performance testing. All team mem-
bers should review the formulas and test them against proven journal reference results
and unit test all prototyped calculations against known inputs and known outputs.Coding is fun. Testing is boring. There is real money at stake, so you had better make sure $4.72 is the
correct theoretical price of the option.White box testing, also known as glass box, structural, clear box, or open box testing,
is a software testing technique whereby testers have explicit knowledge of and access
to the internal workings of the model being tested as well as the test data. Unit tests
are white box tests that verify the individual mechanisms, or components, of the system.
In a white box test, the tester first analyzes the code and then derives test cases, targeting
specific logical paths so as to achieve broad coverage, including boundary conditions.
Experienced programmers often perform scenario tests (a form of white box testing)
with large numbers of combinations of inputs. While this is a good testing technique,
we believe complete scenario testing is not feasible for most trading/investment systems.
Scenario testing is slow and cumbersome, requiring a huge effort to produce and docu-
ment exhaustive coverage of possible scenarios. We recommend the product team test
only known scenarios and move on.
The advantages of white box testing are that testers can quickly uncover program-
ming errors and examine potential error handling techniques, dependencies, and logic
flow. Furthermore, such tests are a check on design decisions and mathematical formulas