Getting Started
Users can get more context about how Triangle will considerably improve the quality of their Findur/Endur platform in a related post. This post will cover sample automated test cases for Findur/Endur that use the popular Gherkin syntax. It allows business users with limited technical knowledge to contribute directly to the test suite.
Dynamic Test Generation
One feature that Triangle users appreciate most is the dynamic test generation. The application inspects the transaction history and automatically creates tests that cover a wide range of portfolio activity. Users can typically see the results of these automatically generated tests on the day that Triangle is installed.
When I generate Findur transaction tests as follows
| Filter | Template | Target |
| toolset == Bond | Bond Trade Booking | Bond |
| toolset == Cash | Cash Trade Booking | Cash |
| toolset == ComFut | ComFut Trade Booking | ComFut |
Dynamic tests can cover a range of processes in the system. The 1997 tests in the Trade Capture Combination Testing group were all generated dynamically.
IntelliSense
By utilizing SpecFlow users receive the benefit of IntelliSense. This feature uses find-as-you-type that prompts the user with suggestions while they are writing their tests.
Existing Triangle users confirm a shallow learning curve for writing your own tests.
Transactions
Transaction processing is a requirement for many tests. This can be time-consuming and deal-entry errors can lead to breaks that are red herrings, which contribute to further delays in the test cycle. Some tests require the creation of lifecycle operations on the transaction, like amendments, rollovers and buyouts.
Create a Transaction
Users sometimes need to perform a simple test that a transaction can be created without hitting an exception. The analyst can define as few or as many fields as the test demands. If a field cannot be set, or the transaction cannot be created, the test will fail.
When I create cash transactions as follows
| Ticker | Test Label | Internal BU | Internal Portfolio | External BU | Amount | Settle Date |
| EUR | MyCash | TREASURY | PO1 | THEIR_CO | 1,000.00 | 0d |
Amend a Transaction
Many core features and customizations fail when a transaction is amended. Sometimes it is important to test that an amendment will fail, for example a backdated amendment is blocked by an operation service. This test confirms that the specified transaction can have its settlement date amended. Additionally, the test confirms that the settlement date matches the expected value after the transaction processing is complete.
Scenario: Changing dates Given the following cash transactions exist | Test Label | Transaction Status | Settle Date | | T-Single-Trade-Cash | New | 02-Feb-2020 | When I amend the CASH transactions as follows | Test Label | Settle Date | | T-Single-Trade-Cash | -= 1m | And I process the transaction to New Then the following cash transactions exist | Test Label | Transaction Status | Settle Date | | T-Single-Trade-Cash | New | 02-Jan-2020 |
Any field on a transaction can be modified and its new value confirmed by the test case. The scenario could perform a test of a dependent fields. For example, if a settlement date is set to X, the bond’s purchased interest is expected to change to Y, or if a broker is amended to X, the broker fees are expected to be Y.
Scenario: Modify and check any field on a transaction Given the following cash transactions exist | Test Label | Transaction Status | Amount | Buy/Sell | | T-Single-Trade-Cash | New | 1500 | Buy | When I amend the CASH transactions as follows | Test Label | Amount | | T-Single-Trade-Cash | += 500 | And I process the transaction to New Then the following cash transactions exist | Test Label | Transaction Status | Amount | Buy/Sell | | T-Single-Trade-Cash | New | 1500 + 500 | Buy |
Deposit Rollover
Triangle can create a deposit, roll the deposit, and test the results. Findur users that perform deposit rollovers recognize how time-consuming acceptance testing is around this functionality. A deposit must be created and then rolled to test each scenario. Scenarios can include: the base case of a rollover that pays the interest and rolls the principal unchanged; a rollover that capitalizes interest and leaves the principal unchanged; a rollover that pays interest and increases/decreases principal; and a rollover that capitalizes interest and increases/decreases principal. That is a total of six scenarios including tests of the compliance rules, back office documentation, accounting, and every other post-trade processing requirement.
Fortunately, for Triangle users, there is support that allows us to automate these scenarios and the post-trade expected results.
Scenario: 100 T-Loan-RollOver-1 Roll-over to buyout new Given a LoanDep transaction with test label "T-Loan-RollOver-1" exists in status Validated And the transaction has events as follows | Event Type | Internal Status | Event Date | Position | Currency | Unit | Pymt Type* | Delivery Type | | Cash Settlement | Known | 02-Jan-2019 | 70000000 | USD | Currency | Initial Principal | Cash | | Cash Settlement | Known | 29-Mar-2019 | -123734.72 | USD | Currency | Interest | Cash | | Cash Settlement | Known | 29-Mar-2019 | -70000000 | USD | Currency | Final Principal | Cash | And I do not rollover interest When I rollover the loan to Rollover New and label "T-Loan-RollOver-1-New-Attempt1" Then a LoanDep transaction with test label "T-Loan-RollOver-1-New-Attempt1" exists in status Rollover New And the transaction has no events
Buyouts
Also known as terminations, buyouts are lifecycle events similar to deposit rollovers because there are several subtle variations that exist, and each must be tested individually. This example includes a loan, but it could be a swap, option, or any other OTC trade. Findur has robust support for partial buyouts and users need to confirm that post-trade functionality includes support for cases when an OTC trade is partially bought out once or even twice during its life.
Scenario: 100 T-Loan-Buyout-1 Buyout to buyout new Given a LoanDep transaction with test label "T-Loan-Buyout-1" exists in status Validated And the transaction has events as follows | Event Type | Internal Status | Event Date | Position | Currency | Unit | Pymt Type* | Delivery Type | | Cash Settlement | Known | 02-Jan-2019 | 70000000 | USD | Currency | Initial Principal | Cash | | Cash Settlement | Known | 21-May-2019 | -194638.89 | USD | Currency | Interest | Cash | | Cash Settlement | Known | 21-May-2019 | -70000000 | USD | Currency | Final Principal | Cash | When I prepare to buyout the transaction as follows | Side | Buyout Amount | Refinance Rate (%) | | 1 | 1000000 | 1.23 | And I try to buyout the transaction to Buyout New Then the buyout succeeds
The disposal of positions in fungible instruments, such as equities, discount notes, bonds, futures and options on futures, have similar testing requirements and burdens as OTC trade terminations.
Setting Settlement Instructions
The Gherkin syntax used by Triangle includes support for setting many properties of a transaction including the settlement instructions. Perhaps a test must check that a trade confirmation includes the instructions that were set on the trade.
When I set settlement instructions as follows | Business Unit | Int/Ext | Currency | Delivery | Settle Name | | C2 FX | Internal | EUR | Cash | FX EUR | | C2 FX | Internal | USD | Cash | FX USD | | JP MORGAN LONDON | External | EUR | Cash | JPM EUR | | JP MORGAN LONDON | External | USD | Cash | JPM USD | And I process the transactions to Validated
Market Manager
A lot of time is spent by users performing side-by-side tests in Findur, especially during an application upgrade. It is important to ensure that the two environments under test contain the same baseline input data such as prices, FX and interest rates, volatilities, CPI, resets, and more. Triangle supports comparison of index output to minimize the time wasted testing simulation results when the market data inputs are different.
It is also important to be able to simulate results that may not have occurred recently, such as high/low/negative interest rates, high/negative inflation rates, fixings that result in option exercise or option expiration, and more. Triangle supports setting historical prices to specified values to facilitate time-consuming edge-case scenarios. Before using Triangle, most Findur users failed to test some of these scenarios.
Scenario: Add historical prices When I add the following historical prices for the index "sFX_NOK.EUR" | Reset Date | Start Date | Ref Source | Price/Rate | | 01-Jan-2015 | 01-Jan-2015 | ECB FX | 66.666 | | 02-Jan-2015 | 02-Jan-2015 | ECB FX | 77.777 |
Triangle can also do the work to populate the historical prices table to ensure your fixings work correctly.
Scenario: 0010 Generate Historical Prices When I synthesise historical prices from "01-Apr-2021" to "30-Apr-2021"
Settlement Desktop
There is a wide array of functionality in the Settlement Desktop that is time-consuming to test. Here too, Triangle supports document processing and examination of the results. This base case test scenario moves a document to the next status and confirms it was processed successfully.
Scenario: 320 Successful document move Given a document with test label "D-Confirm-ComSwap" exists And I do not override STP When I move the document to status "1 Waiting" Then the document is at status "1 Waiting"
This scenario performs a negative test because sometimes the user needs to know that a document transition is not allowed. This test case also demonstrates Triangle’s ability to confirm the content of an exception message.
Scenario: 310 try to move to a status this is not a valid transition from the current status Given a document with test label "D-Confirm-ComSwap" exists When I try to move the document to status "Credit Note" Then the document move fails with the message "Failed to process document with id \d* to status 'Credit Note'" And the document is at status "1 Generated"
Simulations
A lot of Findur users have custom simulations results. Triangle supports tests of transaction results and general results. This test compares the FX result and includes an optional tolerance value.
Scenario: Single Deal Simulation - tran results Given a transaction with test label "T-Sim-Steps-Cash-1" exists And a comparison absolute numerical tolerance of 0.01 When I create a simulation with the following result types | Sim Result | | Transactions | And I run the ad hoc simulation Then the "FX" simulation results in the "default" scenario contain the following | label* | result | Scenario Currency | | USD | 1 | 1 | | EUR | 0.907453537 | 0.907453537 | | GBP | 0.646860615 | 0.646860615 | | NOK | 8.471115382 | 8.471115382 |
When performing side-by-side tests, you will often want to know that a set of simulation results match for all transactions. This sample also demonstrates how the difference tolerance can be defaulted to a very small number, and then overridden for specific results.
Scenario: Compare_Tran_Results Given a comparison absolute numerical tolerance of 0.00000001 And comparison absolute numerical tolerances as follows | Field | Tolerance | | MTM | 0.02 | | Cost of Carry | 1 | | Theta | 1 | | Unrealized P&L | 10 | | Impact of Amendments | 0.02 | | PV w/o Resets | 10 |
When the vendor fixes a bug, some differences are expected. This test documents the origin of an expected difference, and increases the tolerance of the comparison of the Discount Margin field.
And I tolerate row mismatch errors as follows
| ins_type | yield_basis | fix_float | disc_margin_calc_method | Discount Margin | Test Commentary |
| GBND | Act/365 Fixed | Float | ISMA/GDP | +/- 0.001 | Known bug fix - DTS 156246 |
Tasks / Workflows
Triangle can trigger tasks as part of a test. This task will generate an extract that Triangle will compare.
When I run a task called "Export Fpml"
A task in Findur can include a param script with arguments controlled by the user. Triangle extends this concept to allow the test analyst to specify the arguments passed into the task.
When I run a task called "Export Fpml" with overridden input table as follows
| tran_num |
| <tran_num> |
Triangle can trigger a Services Manager workflow. This workflow will generate reports that Triangle will compare.
When I start a workflow called "EOD Credit Reports" And I wait for the workflow to complete
TPM
TPM workflows in Findur support assignment of a task to a user. The user can then accept or reject the task, and perform additional processing. The following test confirms a task is assigned to our user ID and simulates acceptance of the task.
Scenario: 020 Wait for First Approval and accept one of them Given I wait for the following TPM tasks to be available for assignment | Task | Definition | VAR DealNumber | | First Approval | Simple Task Assignment | 456 | When I accept the TPM task Then the following TPM tasks are assigned to me | Task | Definition | VAR DealNumber | | First Approval | Simple Task Assignment | 456 |
When a task in TPM is accepted by a user, they can set the value of a variable. The following test sets a TPM variable and pushes the workflow to the next step. Perhaps afterwards, Triangle will confirm that a transaction was processed or an extract or document was created.
Scenario: 030 Set a variable and complete Given the following TPM tasks are assigned to me | Task | Definition | VAR DealNumber | | First Approval | Simple Task Assignment | 456 | When I set the TPM variables as follows | Variable | Value | | Comment | ok to me | And I complete the TPM task
User Tables
Triangle supports updating user tables and checking the values.
Scenario: Update and check user tables Given a user table called "USER_flight_schedule" exists When I update the user table with the following data | flight_number* | departing_from | arriving_at | departure_time* | | GH667 | London | Amsterdam | 19/12/2019 10:27 | Then the user table contains the following | flight_number | departing_from | arriving_at | departure_time | | GH667 | London | Amsterdam | 19/12/2019 10:27 |
Test Execution
Triangle supports deterministic execution of tests. It is often important for tests to be executed in a predictable order especially for tests that are dependent on execution of an earlier scenario. While this might fly in the face of best-practice test principles, such as keeping tests independent, Findur is a stateful system and it is important to confirm that day 1 activity is complete and reconciled prior to the execution of day 2 tests. Consider the following requirements:
- Realized P&L on day 2 of trades processed on day 1;
- Amendment/cancellation of trades on day 2 that were processed on day 1;
- Activity report on day 2 does not include trades on day 1; or
- Settlement on day 2 of an option traded on day 1.
All of these scenarios will require the tests to be executed in a specific order.
After the dynamically generated transactions are created, the following suite tests that the simulation results match.
More Information
Users can get more context about how Triangle will considerably improve the quality of their Findur/Endur platform in this post. We are happy to respond to any requests, including arranging a demonstration of the application’s capabilities. Reach out if you have any questions.
