ato logo
Search Suggestion:

Rollover version 2 test cases

An overview of rollover testing and lists the test cases.

Last updated 15 January 2018

Testing overview

This section gives an overview of rollover testing and lists the test cases that form the basic requirement for integration, interoperability and peer-to-peer testing for both fund and government transactions.

B2B (fund to fund) test cases

B2B (Fund to Fund) peer to peer tests – send and receive the following:

Initiate Rollover Request (IRR)

  • Single member IRR message successfully
  • Multiple member IRR message successfully (optional to send, mandatory to test receiving)
  • Valid message with Other Details tuples populated with agreed value
  • Valid message with Record Count populated

Initiate Rollover Error Response (IRER)

  • IRER Business error – member doesn’t exist
  • IRER message with Context ID included (optional to send, mandatory to receive)

Rollover Transaction Request (RTR)

  • Valid single member rollover for processing (validate all figures based on rollover transaction)
  • Multiple member RTR message successfully (optional to send, mandatory to test receiving)
  • Valid member rollover with no TFN processed
  • Valid member rollover with Other Details tuple populated
  • Valid member rollover with Record Count populated

Rollover Transaction Outcome Response (RTOR)

  • Rollover processed successfully
  • Business error: member not found (member level refund)
  • Business error: Roll over message but no money paid – document level response with no refund
  • Business error resulting in document level refund
  • RTOR with Context ID included (optional to send, mandatory to receive)

Version 1 & Version 2 scenarios

  • Version scenario 1 – Both Fund A and Fund B are v1 and v2 compliant – all messages sent in v2
  • Version scenario 1A – Incorrect Scenario – Both funds v2 compliant, but RTR sent in v1
  • Version scenario 3 – Fund A v1 and Fund B v2 – fund A moves to v2 post sending IRR
  • Version scenario 4 – Response message scenarios – linked messages for the following combinations result in messages being sent in v1  
    • Fund A v1 and Fund B v1
    • Fund A v2 and Fund B v1
    • Fund A v1 and Fund B v2
     

G2B (ATO to fund) test cases

G2B (ATO to Fund) peer to peer tests – send and receive the following:

Unclaimed Superannuation Money (USM) –from ATO to Fund

  • Valid single member USM rollover for processing
  • Valid multiple member USM rollovers for processing
  • Valid member USM rollover with no TFN processed
  • Valid member USM rollover with Other Details tuple populated
  • Valid member USM message with all fields populated that will be sent in a normal message
  • Valid member USM message with only the minimum number of mandatory fields populated
  • Valid member USM message with Record Count populated

7. Unclaimed Superannuation Money Outcome Response (USMOR) – from Fund to ATO

  • USM rollover processed successfully
  • Business error: member doesn't exist (member level refund)
  • Business error: Roll over message but no money paid. OOB response
  • Business error resulting in document level refund
  • USMOR with Context ID included (mandatory to send and receive)

Electronic Portability Form (EPF) – from ATO to Fund

  • Single member EPF message successfully
  • EPF message with Other Details tuples populated with agreed value
  • EPF message with Record Count populated
  • ATO sends EPF v1 and Fund is v1
  • ATO sends EPF v1 and Fund is v2 (INCORRECT)
  • ATO sends EPF v2 and Fund is v2
  • ATO sends EPF v2 and Fund is v1 (INCORRECT)

Integration test cases

This section gives an overview of test cases that should form the basis of application integration testing for funds.

Integration testing checklist

  1. Fund and Service Provider/s testing sending messages

1.1. FVS call

1.2. SuperTICK call

1.3. XBRL message construction

1.4. ebMS message transmission

  1. Fund and Service Provider/s testing receiving messages

2.1. ebMS message receipt

2.2. XBRL message deconstruction

2.3. Process rollover into registry system and generate response

  1. Fund and Service Provider/s testing sending responses

3.1. Error or outcome messages generated

3.2. XML message construction

3.3. ebMS message transmission

  1. Fund and Service Provider/s testing receiving responses

4.1. ebMS message receipt

4.2. XML response message deconstruction

4.3. Error or outcome message processed

  1. Government and Service Provider/s testing sending:

5.1. FVS call

5.2. XBRL message construction

5.3. ebMS message transmission

  1. Government and Service Provider/s testing receiving responses

6.1. ebMS message receipt

6.2. XML response message deconstruction

6.3. Error or outcome message processed

Message structure and content tests

  • Presence of fields  
    • Mandatory fields present
    • Conditional and dependent fields present if required
     
  • Values  
    • Values according to taxonomy
    • Cross field validations
    • Other business rules – fund
     
  • XBRL  
    • Message correctly formed
    • Message internally consistent – context and data
     
  • XML (responses)  
    • Message correctly formed
    • Message internally consistent – parameters and event items
    • Refund parameters match the Business Response Messaging Framework
     
  • ebMS  
    • Header and wrapper correct
    • Transmission and receipt successful
    • Response messages correctly packaged
    • Response message transmission and receipt successful
     

Test data

Sample message instances will be available separately to this document.

Gateway interoperability test scenario catalogue

This section gives an overview of tests required as part of interoperability testing between gateway to gateway and gateway to government.

Gateways can commence peer to peer testing prior to completing interoperability as long as they have completed interoperability with other gateway participants in the peer group. Prior to production it is required that all gateways have successfully completed testing with one another.

Refer to Interoperability test case detail for further detail of the tests listed below.

Table 1: B2B – Existing gateways

Test number

v1

v2

Description

INTERB1.1

 

 

Send a RTR message with correct data

INTERB1.2

 

 

Send a RTOR message (if applicable to gateway)

INTERB1.3

Optional

Optional

Repeat above test with mismatched payload (if applicable to gateway)

INTERB1.4

 

 

Send an IRR message with correct data

INTERB1.5

 

 

Send an IRER message with correct data

INTERB1.6*

 

 

Fund A v2 and Fund B v1 - incorrect versioning - IRR sent by fund A to fund B in v2. See Note 1 below.

Note 1: INTERB1.6: This test may not be able to be initiated by some gateways for interoperability testing because of the structure of their interaction with their funds. In those cases, the B2B fund to fund versioning test cases will cover this scenario.

Table 2: G2B – ATO to existing gateways

Test number

v1

v2

Description – Transport and MSH layer testing (See Note 2)

INTERG1.1

 

 

Establish https connection between endpoints

Note: ATO has already established connectivity for EPF, however for USM, connection also needs to go the other way(because of USMOR) so tests are to be repeated

INTERG1.2

 

 

Send a simplified message from the sender MSH to the receiver MSH

INTERG1.3

 

 

Send a simplified message from the sender MSH to the receiver MSH with PayloadInfo part properties configured for a particular source / target fund combination

INTERG1.4

 

 

Test message signing and signature validation

INTERG1.5

 

 

Test message compression

INTERG1.6

 

 

Multiple payloads - non compressed

INTERG1.7

 

 

Multiple payloads – compressed

Note 2: These low-level G2B test cases provide a checklist of message structure requirements and do not need to be performed separately if not appropriate. A single well-formed, signed, compressed message as specified in tests INTERG1.8, INTERG1.9 and INTERG1.10 will automatically provide a test of these requirements.

Table 3: G2B – ATO to existing gateways

Test number

v1

v2

Description

Application layer testing

INTERG1.8

 

 

Send a USM Rollover message with correct data

INTERG1.9

 

 

Send a USM Rollover Outcome Response message with correct data

INTERG1.10

 

 

Send an Electronic Portability Form message with correct data

INTERG1.11

 

 

BIP4 - check routing is consistent with BIP4

INTERG1.12

 

 

ATO sends EPF v1 and Fund B is v1

INTERG1.13

 

 

ATO sends EPF v1 and Fund B is v2 (INCORRECT)

INTERG1.14

 

 

ATO sends EPF v2 and Fund B is v2

INTERG1.15

 

 

ATO sends EPF v2 and Fund B is v1 (INCORRECT)

Peer-to-peer test scenario catalogue

The following test case scenarios are the minimum test scenarios required for Peer to Peer testing:

It is the responsibility of the trustee to ensure these tests are completed successfully for each solution, regardless of whether the fund or their service provider conducts the test.

Peer to Peer Test Case Scenarios – B2B

Each test case should be performed by Funds taking on both a sending and a receiving role – that is, Fund A sending to Fund B, and then repeated with Fund B sending to Fund A.

Each test requires checking of both sending and receiving solution correctness – refer to the test cases in Peer to peer test cases for further detail.

Note 1: The response pattern used by the responding party may be any of Error, Partial or Progressive. The receiving party for a response must be able to process all response pattern types.

Note 2: Payment reconciliation cannot be tested in a testing environment as no actual payments are created.

Table 4: Initiate Rollover Request (IRR)

Test number

V1

V2

Description

IRR1.1

 

 

Valid single member IRR message

IRR1.2

 

 

Valid multiple member IRR message

Note: it is optional to send a multiple member IRR but all funds must test that they can receive a multiple member IRR

IRR1.3

 

 

Valid IRR message with Other Details tuple populated with an agreed value between peers

Note: optional to send, mandatory to receive

IRR1.4

 

 

Valid IRR message with Record Count populated
Table 5: Initiate Rollover Error Response (IRER)

Test number

V1

V2

Description

IRER2.1

 

 

IRER Business error – member doesn’t exist

SUPER.GEN.GEN.21 – Member not found with supplied information

IRER2.2

 

 

IRER message with Context ID included

Note: optional to send, mandatory to receive
Table 6: Rollover Transaction Request (RTR)

Test number

V1

V2

Description

RTR3.1

 

 

Valid single member RTR message

RTR3.2

 

 

Valid multiple member RTR message successfully

Note: optional to send, mandatory to receive

RTR3.3

Optional

Optional

Valid member rollover with no TFN processed (using Member ID)

RTR3.4

 

 

Valid member rollover with Other Details tuple populated

Note: optional to send, mandatory to receive

RTR3.5

 

 

Valid member rollover with Record Count populated
Table 7: Rollover Transaction Outcome Response (RTOR)

Test number

V1

V2

Description

RTR3.1

 

 

Valid single member RTR message

RTR3.2

 

 

Valid multiple member RTR message successfully Note: optional to send, mandatory to receive

RTR3.3

Optional

Optional

Valid member rollover with no TFN processed (using Member ID)

RTR3.4

 

 

Valid member rollover with Other Details tuple populated Note: optional to send, mandatory to receive

RTR3.5

 

 

Valid member rollover with Record Count populated
Table 8: Versioning Scenarios

Test number

V1

V2

Description

VS5.1

 

 

Both Fund A and Fund B are v1 and v2 compliant – all messages sent in v2

VS5.2

 

 

Incorrect Scenario – Both funds v2 compliant, but RTR sent in v1

VS5.3

 

 

Fund A v1 and Fund B v2 - fund A moves to v2 post sending IRR

VS5.4

 

 

Response message scenarios – linked messages for the following combinations result in messages being sent in v1

  • Fund A v1 and Fund B v1
  • Fund A v2 and Fund B v1
  • Fund A v1 and Fund B v2

 

Peer to peer test case catalogue – G2B

Table 9: Unclaimed Superannuation Money (USM) – from ATO to Fund

Test number

V1

V2

Description

USM6.1

 

 

Valid single member USM rollover

USM6.2

 

 

Valid multiple member USM rollovers

USM6.3

 

 

Valid member USM rollover with no TFN, including Member ID

USM6.4

 

 

Valid member USM rollover with Other Details tuple populated

USM6.5

 

 

Valid member USM message with all fields populated that will be sent in a normal message

USM6.6

 

 

Valid member USM message with only the minimum number of mandatory fields populated

USM6.7

 

 

Valid member USM message with Record Count populated
Table 10: Unclaimed Superannuation Money Outcome Response (USMOR) – from Fund to ATO

Test number

V1

V2

Description

USMOR7.1

 

 

USM rollover response processed successfully

USMOR7.2

 

 

Business error: – Member level refund because member doesn’t exist, SUPER.GEN.GEN.21 – Member not found with supplied information

USMOR7.3

 

 

USMOR with Context ID included

Note: mandatory to send and receive
Table 11: Electronic Portability Form (EPF)

Test number

V1

V2

Description

EPF8.1

 

 

Valid Single member EPF message

EPF8.2

 

 

Valid EPF message with Other Details tuples populated with agreed value Note: optional to send, mandatory to receive

EPF8.3

 

 

Valid EPF message with Record Count populated

EPF8.4

 

 

ATO sends EPF v1 and Fund is v1

EPF8.5

 

 

ATO sends EPF v1 and Fund is v2 (INCORRECT)

EPF8.6

 

 

ATO sends EPF v2 and Fund is v2

EPF8.7

 

 

ATO sends EPF v2 and Fund is v1 (INCORRECT)

QC50524