3rd Party Integration Testing Challenges & Tally Way of Testing

Tally has been a thick client that runs on the Windows platform in isolation, with no requirement to connect to external systems for a long time. But with the changing business landscape and market demands, Tally is transforming and delivering features that require it to be connected to 3rd party entities. Some of these features are---e-invoice bill generation, sending payment links via WhatsApp, GST upload/download and filing returns, and so on.

The following article is intended for both technical and non-technical audiences, hence you may find some of the information abstract or at bird's eye view. Please reach out to us directly for more details with respect to the technical implementation.

Note: Sandbox is a kind of server that is developed by the 3rd party entity to simulate the actual production server.

Challenges and requirements while testing the connected features

During the initial development phase (where the connection with 3rd party is not yet ready), where we have the required specifications from the 3rd party; we have some of the following challenges/requirements to sign off the initial releases:

• Is the client generating the request as per the 3rd party specification?

• Are all the required headers present with valid values?

• Is the payload correct?

• Is the payload encryption happening correctly?

Way forward for QA

There are two ways for QA:

• Point to 3rd sandbox and test only the possible scenarios that can be tested using the sandbox.

• Develop our sandbox.

To address the challenges with 3rd party integration, at Tally we decided to develop our own Mock server (a kind of sandbox that is developed for Tally Solutions by the Tally QA team). This helped us to overcome all the challenges that were mentioned earlier and helped us with better automation.

Challenges with Sandbox

Integration with a 3rd party has its challenges, but here in this article, we will focus on what are the challenges that the QA team faces to test and certify the features that the Tally client needs to talk to 3rd party entities. Following are some of the challenges:

• 3rd party Sandbox availability.

• Sandbox performance is low hence QA team cannot use it for performance testing.

• Simulating most of the negative scenarios is not possible pointing to Sandbox. For example, sending negative response when mandatory headers are missing, invalid encryption, etc.

• Simulating exceptions for example, server closes the connection abnormally, or server sends a response after some delay, etc.

• Different 3rd parties have different Sandboxes.

Challenges with mock server

Developing our sandbox has its own set of challenges and/or requirements:

• Mock server should be common for function and NFR testing

• Address all challenges mentioned in the “Challenges with Sandbox” section

• Most of the test script writers have little competency in programming and cannot understand code

• Having different mock servers for different projects has maintenance overhead

Design concept of mock server that is developed.

Following are some of the aspects which Mock Server needs to support:

• Multi-Threading: The expected response should not be set at a global level. This will limit the functionality of the Mock server when we are trying to test a multi-threading scenario where two requests are sent by different clients at the same time.

• Performance: Since the mock is common for both NFR and Functional testing, we cannot have too many loops and the mock code should be lightweight.

• Availability: The Mock should be available all the time.

• Reliability: The mock should have the capability to check if the received request headers, header values, payload, etc. are as per specification.

• Scalability: The mock server should be capable of supporting horizontal scaling to support a huge volume of traffic.

Technical details of the mock server

Following are some of the finer details of how the mock server is built:

• The expected response is set against the following parameters:

  • Type of Request (Example: Post, Put, Get, etc.)

  • Request End Point

  • Header/Payload key

  • Header/Payload Value

So, when a request is received at the mock server, the mock server extracts the type of request, endpoint, keys, and values from the request and compares what is already set. It will pick the matching response and responds with that response status code and payload.

• The mock server is developed in Node JS. While setting the expected response, we construct a JSON structure and store it in memory. To fetch the matching response, we index and get the required response code and payload so that we do have any loops and the mock server can run at high speed.

• To solve the availability problem, the mock server is built with the capability of running on the local machine.

• While setting the expected response, the mock server has the capability to set the expected headers, exception headers (headers that are not meant to be received) and, expected payload. So, when the matching request is received, before sending the expected response, the mock server also checks if the request has all the required headers, if the request has any unwanted headers, and if the payload in the request is as per the expectation.

• Mock server has optional decryption and encryption mechanism that can be enabled dynamically based on the project-specific requirement.

Advantages of having a mock server

Having an in-house mock server has the following advantages:

• Helps in identifying the issues in the client before actually integrating with the 3rd party entity during the early stages. This will help to mitigate any possible integration issues during the integration with 3rd party entities.

• The mock server functionality can be added/modified with changing business requirements.

• Always available with low latency.

• Ability to simulate exception scenarios for example, connection breakage, server down, etc. are easy to handle. Simulating most of such scenarios with the Sandbox is not possible.