Be it Zoom and HubSpot integration, WooCommerce, and HubSpot integration, or HubSpot and Sage 300 integration, the success of any integration is said when the data sharing in the integration matches the requirements. Or, if, in any case, a couple of data fields do not work as they should because the two tools in integration don’t allow that, there should be a constructive explanation of why it didn’t happen.
Integration generally involves data sharing between the two tools. Sometimes, it is a one-way integration where data from one software tool is shared with the other software tool, and then that data is used further. In the two-way integration, data travels from one software tool to the second software tool and then moves back to the first software tool with additional data.
Data fields generally include name, email, address, phone number, subscriptions, payment, form submission acceptance, and cancellation, among others, based on the client’s requirements.
Native integration is the standard integration protocol set by both the tools with the desired software tool. You get native integration options as an additional benefit when purchasing the software tool. The native integration projects are click-n-play things where you just turn off or turn on the data fields sharing, and you are good to go. It may seem easy, but errors can occur in native integration as well.
Go to HubSpot Marketplace and see the listed apps under their native integration policy. HubSpot has a standard set of data fields shareable with these apps. You can even have custom integration with all these applications based on your unique requirements.
The basic of native integration testing involves filling the data fields with the anticipated entries and testing how the data is getting displayed and saved in the other software tool. However, you should also do negative testing, i.e., you must enter the wrong data in the fields, for example, a numeric value in the text field and vice versa, to see how things will be displayed if someone fills the field with the wrong data.
This is the scenario where the stakes are high, and one cannot go wrong in delivering a successful integration project. Custom integration projects are way more complex than native integration for various reasons.
Integration experts design middleware in the programming language of their choice or the client’s choice. The Middleware is used to receive the data from one software tool and send it to the other software tool. So, you see, the testing is done in two phases.
This was only for the one-way data transfer scenario. If it is a two-way data transfer, double the testing.
Keep multiplying the testing scenarios if you want to integrate more tools in sync. At any step, one wrong data field will break the chain of successful integration.
Let’s say your client wants to add a Paypal payment method to the website and assign you the task of integrating HubSpot with Paypal with some custom fields. And, in the middle of the project, the client wants to add another payment method, i.e., Stripe, because they gave your client a great offer. Adding additional payment methods was not mentioned in the beginning. Developers and the client have two options. They can either postpone adding the additional payment method or do it quickly with some changes in the initial requirement and scope of work.
If you choose to do it in the current version, then the development and testing standards will be changed to meet the new requirements.
New standards should be discussed with the client and documented to avoid confusion at a later stage.
Positive testing is done when the intended data is inserted in the data fields to check how it gets transferred on the other side of integration. Fields include name, email, address, phone, company name, designation, subscription level, and payment.
All the data fields in the software tool are related to each other. In the case of HubSpot, the contact properties are associated with the primary contact. And this association must be present in the second software tool post-integration.
Negative testing is when you put an invalid or unintended data field and see how the tool reacts. This includes typing letters in the numeric field and vice versa. It is up to you how you want your software tool to behave. If it handles the invalid inputs the way you want it to, you are good to go.
This is done by inserting the repeat data in the field. See if any of the integrated software tools make a copy of the info or don’t save it or save it but mark it as duplicate. It should perform the action that developers coded it to perform.
Now that you know the whats and whys of testing an integration project, it’s time for you to know the How of it. Let’s hear it from Farhan Arshad, Software Quality Assurance Engineer at Computan, who believes that “we need to have a deep understanding of the product or feature before we can start creating a test plan for it. There are some points you need to know clearly before starting the testing.
Next, it’s time to decide the scope of our test plan. We need to dig in and think about the customer requirement and what the client wants to get from the development team with a bug-free product. Talking about bugs, we use different bug management tools here in our company like Jira, Trello, Asana, Bugherd, and Github to report and monitor the issues.
Once you decide the scope of the test plan, you need to define the test objectives, and pass/fail criteria. As we define each different test we are going to run, we need to know when our test is “done.” This means defining the pass and fail criteria for each specific test.
The results of our test plan will depend as much on the feature we’re testing as the environment we are testing it in. As part of the scope, we need to determine what browser we will test.”
It’s like asking who will taste my Pizza, the expert cook or the regular restaurant-goers. Both will apply different approaches here. And, both reviews would be important. Farhan Arshad, Computan’s Software Quality Assurance Engineer, sheds some more light on different ends of integration project testing, “the user checks the functionalities and business requirements given to the development team to develop and explore the flows to make sure the flows are working correctly. But a QA engineer tests the features deeply through the back-end, database, API, and code reviews. The QC is more of a technical explorer than an end-user, and you can say QC is technically strong and able to break the flows to test functional and non-functional requirements.”