So you’ve just received a new version of your OMS and want to make sure that your FIX functionality isn’t negatively impacted by the new release. Typically the new release will go to your testing team who will be responsible for ensuring that no functionality has regressed. The key in this phase of the project is identifying major problems as early as possible so they can be sent back to the vendor. Find a showstopper on day one of regression testing and you could have saved yourself an entire regression cycle.

To test or not to test?

There are two schools of thought with regression testing FIX functionality. The first is to bury your head in the sand when it comes to FIX testing at these crucial early stages of regression testing. This is dangerous but there are good reasons for adopting this philosophy.

The second is to do a full FIX regression test with a ‘real’ broker. This can be time consuming since it’s so heavily reliant on external parties over whom you have no control and there are doubts as to the validity such testing.

Why wouldn’t you test?

There are many reasons why a testing team may not test FIX functionality with real life brokers. Firstly, your test environment is used for testing new functionality, why should a broker be any different? When we perform UAT with a broker there are no guarantees that the FIX message format of the broker’s test environment is the same as that of their production environment. If the FIX message format is different between UAT and Production, is there any validity in the testing?

Secondly, UAT connections are unreliable. A UAT FIX connection is important to everyone, but is it monitored? Is there a dedicated team to ensure up-time? This is highly unlikely. So when we want to test, there will undoubtedly be a debacle of getting a session up and heartbeating. Ensuring that firewalls and network configuration is in place and correct. Sequence numbers mismatches. All these add to the time taken to successfully complete a FIX regression test.

How many UAT connections to brokers do you have? If the answer is ‘one’ then you could have more problems to overcome before you can proceed with regression testing FIX. It’s likely that your front office support team use the UAT connection for replicating and resolving production issue. It can take some time to switch a UAT connection between OMS environments. This is more valuable time you’re losing.

As we said earlier we want to find show stoppers early on in the regression testing phase. Considering the above, this is not going to happen. Even if you do find any issues, can you guarantee that this is because of changes introduced by your new OMS? What if the issues are caused by changes to the brokers FIX message format?

What’s the answer?

The solution to this is problem is using a FIX simulator such as IntelliBroker. IntelliBroker is a broker test harness that simulates the sell side workflow and will allow you to exchange FIX messages with your OMS.

IntelliBroker is always available, quick to launch, automatically handles sequence numbers and supports all asset classes. This allows you to quickly regression test your FIX environment and produces results that you can rely on.

IntelliBroker allows you to define custom FIX messages. You can therefore take an existing production FIX message from any broker and assign it to IntelliBroker to send to your OMS. The user defined FIX message is persistent and will only change when you decide. This makes testing across different versions of your OMS consistent and provides results which you can rely on. Any change in behavior will not be due to changes in the incoming FIX message format.

Using IntelliBroker will save you time and will provide more reliable results than those produced by testing with a real broker.

To find out how IntelliBroker can help your business please feel free to contact us.