All good software testing begins with a clear and concise comprehension of the business objectives in the form of business requirements. Sometimes during the requirements review process this results in a knowledgeable tester’s contribution by bringing certain scenarios, that might otherwise be overlooked, to the attention of the cross functional team. Such a tester will have a better understanding of business logic and desired business objectives then a tester with no experience.
Testers with a working knowledge of all trading principals have a direct impact on risk mitigation. Risk is minimized because the tester(s) know all of the ins and outs of not only what is possible but what should not be possible as well. It isn’t enough to give your client what they are looking for, but, you also have to be sure they are not getting what they didn’t ask for in addition. An example would be where an inexperienced tester would stop trying to break the system and be satisfied with being able to enter an equity order, where a more seasoned professional will try all possible combinations of data entry. He/she will try adding not only positive integers to a price or quantity field but negative numbers, fractions, null values and other unrealistic forms of data for trading purposes.
An inexperienced tester might not catch the fact that the system just accepted an order it should not have such as a short sell for fewer than one hundred shares if the existing industry standards are to reject these orders. The risk of costly errors and orders making it to the exchange floor or market maker is reduced. I’m sure metrics will bear this out in black and white. Often I’ve seen people be asked to test options and commodities logic in a client facing system and they have no clue what so ever as to how options, complex options, bonds, or commodities even work. They won’t be able to even enter an order in most instances let alone be able to recognize what’s possible and what isn’t. This can seriously jeopardize a trading firm and expose itself to huge liabilities at the end of the trading day.
Knowledgeable test engineers automatically have a more complete testing coverage analysis of what will be involved in the verification to be done. A perfect example would be when validating extended hours trading. A tester must know when certain types of orders are valid and when they are not. They will conduct boundary testing for text entry fields. They will cover all bases possible and approach validation not just from a mechanical white box user approach but a more human and unpredictable way as well.
A good tester will take a lot less time to get up to speed and probably need minimal training time which can not only be costly but risky. The learning curve to a new project or functionality is significantly reduced with a veteran test engineer.
Good testers also don’t make rookie mistakes like validating something and then realizing half way through the process that they’ve been looking at the wrong test configuration, quote sources, or environments. A good tester should also be able to effectively trouble shoot their own issues as much as possible and not waste the time of developers or test environment engineers. I’ve seen this numerous times and its just wasteful lost testing time.
The value of the subject specific knowledgeable tester is not in the number of defects found but return on investment.