Testing and launch

Transcript

There are a variety of considerations to keep in mind when testing a scenario. In this training, we’ll consider some of the major concepts and questions to ask, but with experience in practice anyone building integrations will begin to craft their own test cases to go through each time they build a new integration. The first thing to keep at the forefront of your mind is that testing should be a constant part of any integration build or implementation. Effective testing begins with a clear understanding of requirements and how to verify a requirement is met through testing. Testing should not be an afterthought and should not wait until you consider the integration ready to go live or launch. Every stage of building should incorporate testing. Typically, the first testable stage is a prototype that meets some very basic requirements. For example, a prototype of a request queue use case would have a trigger module for request records and an output like a project record. A functional prototype makes it possible for Fusion users to add transformations, complex mappingsو conditional router logic, and other scenario features incrementally. Each new feature or change should be tested to make sure it meets the requirements and also that the entire scenario still functions as expected. Eventually, the scenario should be tested outside of Fusion. For example, if your scenario is triggered by a new case in Salesforceو then testing should be done from within Salesforce. Fusion testing involves both the source and destination systems, not just monitoring what happens in the Fusion scenario. You’ll need to be logging into third-party systems with which you are connecting as part of your testing as well as monitoring what happens in Fusion as the automation is running. As mentioned already, from the very beginning of your integration build, the approach you should take is one of constant iteration in testing. Build the first version of the scenario and then test, iterate, repeat, and retest. This applies not only to your Fusion scenarios but also to what may need to be adjusted in connected systems or business practices if applicable. There are a couple methods to make sure that the testing needed is performed correctly and to keep everyone involved in building the integration from not feeling overwhelmed. To make sure testing is performed correctly, you need to adequately inform and educate the customer or the team performing the testing. You should make sure that a shareable spreadsheet is used for your user acceptance testing. It’s important that this document is shared and allows collaboration. Avoid sending versions of the spreadsheet back and forth as that typically results in mistakes or confusion for all involved. To not feel overwhelmed by how much testing is required, you need to create a comprehensive testing plan to match which could be documented in the same spreadsheet. A test plan should have clearly defined expectations for what is being tested specifically. How do you best do this? First test cases should be discreet infusion centric. They should test specific requirements of your Fusion scenario and not just be general testing. By avoiding general testing, you can identify nuances such as issues with changing variables. For example, a user inputting numbers instead of texting to a custom form field or vice versa. Or maybe a user doesn’t fill out a field as you typically would expect. Ask yourself if changes in the data from your input system will ever change in effect what is expected by your output system. A simple rule, if the data could change, definitely test for it. Now, how do you know what data or how much data to test? Focus on these three principles. First, you need to make sure you are testing the depth of the data. Similar to what we were just talking about, make sure you test all the different fields, values, and pieces of data involved in your integration. For example, for a multi-select field, make sure that if one, two, or 20 options are selected your automation can handle those variations. Next, consider the breadth of data. When testing, are you trying multiple different variations of the data coming into your automation. Ask those what if questions here. What if the project name is changed but everything else remains the same? What if the request is submitted without all of the required data, but then it’s added right after? What if someone puts dates in a different format than what’s expected? And what if the input system sends a corrupted file? Finally, consider complexity and load. What happens if a file sent from another system is much larger than expected? What happens if someone does a bulk update? Will your automation be able to handle that much input? What happens if you exceed limits set by other APIs or the Fusion system itself? You’ll never be able to handle or consider every possible complexity that your automation may face but just think beyond what you would expect is possible. A good reminder from Benjamin Graham, “The most important part of every plan is planning on your plan not going according to plan.” Ultimately, you want to instill a culture of testing on your team or at your organization. Encourage well thought-out, detailed test plans that involve all systems and variations and data. Make sure testing is not something that you wait to do until the very end of your design, but it’s something that happens early and often as you iterate to your final version. Do this and you’re on your way to successfully implementing integrations using Fusion. -