MCOM Wave 4 - High-Level Testing Strategy

Objective: 

Enable the relevant Banking and Finance stakeholders to verify that existing, business critical processes and connectivity points are functioning correctly after the migration to MCOM. Given that there is no new functionality being introduced, the scope is limited to validation and health checking of the pre-production or production environment.  

Timeframe: 

A maximum timeframe of 4 to 6 weeks is proposed for iterative execution of the necessary tests, excluding planning/preparation. The testing is intended to be surface-level, “happy path” (successful completion) smoke testing, prioritising the testing of connectivity and critical business processes over individual function testing. Time should be set aside within the test window for providing feedback about any issues and potentially re-running tests.

The strategy consists of a couple of key activities.

1. Key activity: Identify what should be tested

The relevant stakeholders must identify the connectivity points and mission-critical business processes that should be smoke tested during the available testing window. 

A Smoke Test (or "Build Verification Test") is a quick set of tests to verify that the most critical processes work end-to-end. It is designed to confirm that the network is working correctly after the migration to MCOM.

Answer questions such as: 

• What are my key workflows?
• What are the transactions that I do every day?
• What source systems do I use?
• How do my systems integrate with Cotality systems?
• What are all the different ways that I can order valuations?

Suggested tests for Lenders:

1. Verify that you are still able to log into all the relevant Cotality systems.
2. Order at least one valuation job from each of the integrating systems, and verify that everything works end-to-end, including panelling to a Valfirm and all the necessary system-to-system notifications. 

Note: It is NOT necessary to order every valuation type. The focus is more about verifying the basic end-to-end connectivity and processes, not exhaustive testing of every possible combination and function.

1. For lenders that integrate directly with Cotality systems to order valuations, perform an expandedSearch/findCall to determine the appropriate valuation type and then use the existing integration to place an order. This also tests the integration with the different rule engines (internal and external) that determine the valuation type. 
2. Order other types of products, such as property profile reports and suburb reports (if applicable), as these test connectivity to other services in the ecosystem.
3. Verify that you can still perform the necessary searches, confirming that the historical search results pre- and post-migration are the same.
4. Verify that you still have access to reporting and that the content of historical reporting pre- and post-migration is the same. 
5. Verify that you are still able to perform a Valuation Status Enquiry (“valstatus”) for a particular job. 
6. Verify that the entire query process still works end-to-end.

Suggested tests for Valfirms:

1. Verify that you are still able to log into the relevant Cotality systems.
2. Verify that you can still respond to requests for quotes.
3. Verify that you are still able to accept valuation jobs.
4. Verify that you are still able to place delays on jobs.
5. Verify that you can still complete and deliver a valuation report.
6. For valfirms that integrate directly with Cotality via webservices, verify that you can still perform all your common transactions, including:
   1. Accepting valuation jobs via the integration 
   2. Placing delays on jobs via the integration
   3. Completing and delivering a valuation report via the integration. 

Note: These are only some suggestions, based on common transactions for Banking and Finance stakeholders. It is certainly not an exhaustive list. Please select those tests that are most relevant for you, and feel free to add your own, focusing on your everyday transactions.

1. Key activity: Execute tests and provide feedback

Once you have identified what should be tested and the testing window starts, you should execute the tests, record the results (particularly the circumstances and details of any failures) and provide the necessary feedback to Cotality in a timeous manner. 

For direct integrations, you can utilise automated test scripts and/or simple network connectivity tests, performing smoke tests to verify that the integrated systems are connected and communicating successfully after the migration to MCOM.

For the business-critical processes that you have identified, execute your test scenarios using the existing systems in the migrated environment, and verify that the results are the same as before the migration. 

Providing testing feedback

Given the nature of the testing, testers should NOT wait until the end of their testing before providing feedback about issues to Cotality. It is absolutely vital that testers provide comprehensive details about any issues they encounter as soon as they occur, including details about the steps that they followed and the exact error message that they encountered. Please include screenshots if possible. This is so that Cotality can start troubleshooting the issue and resolve it as quickly as possible. 

An example template for reporting any issues can be found at the bottom of this page.

The customer should immediately report any issues to the relevant Cotality CDM (Client Delivery Manager) or Account Manager, who will escalate it to the program team. The team will investigate and determine what the issue is, who needs to deal with it and provide feedback to the customer.    

Re-running tests

If any issues are found during testing that relate directly to the MCOM migration, then a full retest cycle should be performed once fixes are deployed, in order to verify that the issue has been resolved.