Applications, just like human beings, rarely live in isolation. With the proliferation of digital and IOT platforms, communication is even more important. A digital banking application must interface with the customer application and a trading application must connect to real time data feeds; communication channels are crucial to making the ecosystem run. A messaging system is one example of how communication between systems enables the entire ecosystem to work properly.

Let us consider a simple use case. I have successfully completed a banking transaction, the records of which need to be processed further in my customer application. My banking application publishes a transaction in the form of a message to a message channel. My interfacing application, in this case my customer application, can read the message from the channel at a later time. The applications must agree on a channel as well as the format of the message.

The type of messaging channel dictates the validation scenario that the QA team must test. Below are five of the most common validation scenarios by messaging channel; it is crucial to keep these in consideration when designing your test strategies.

  • Point-to-Point channel:  In this scenario, only one receiver will receive a particular message
    • Validate a multiple receivers scenario – If the channel has multiple receivers, only one of them can successfully consume a particular message
    • Validate that consumed messages are not available for any other receiver
    • Validate that invalid messages are handled
  • Publish subscriber channel: In this scenario, the sender broadcasts an event to all interested channels. Each output channel has only one subscriber, allowed to consume a message only once.
    • Validate that messages can be broadcast across multiple channels
    • Validate that each output channel has only one subscriber
    • Validate that consumed copies disappear from their channels
    • Validate invalid message types are handled
    • Validate that there is a mechanism to handle system /network failures
  • Data type Channel: In this scenario, various types of data are transferred, such as trading data and consumer data. The type of channel will differ for each data type; all of the messages on a given channel will contain the same type of data.
    • Validate that there is a separate channel for each data type
    • Validate that message is routed on different channels depending on data type
    • Validate that invalid messages are handled gracefully through an invalid message channel
    • Validate that there is a mechanism to handle system /network failures
  • Invalid messaging channel This is a channel designed for messages that could not be processed by their receivers.
    • Validate that invalid message types are routed to an invalid channel.
    • Validate that there is a mechanism to handle system /network failures via a dead letter channel
  • Dead letter channel: This is a mechanism for handling system and network failures. Due to system/network failures or failures at the recipient’s end, messages may not get delivered and must be gracefully handled. In this case, one can design the system to periodically resend the message or ensure that the dead messages are delivered once the system is up
    • Validate through negative scenarios that there is a provision for a dead letter channel to handle network/system failures

Architectural understanding and contributing to secure, usable design of enterprise applications and messaging systems is critical. As a tester, our responsibility is to connect the dots to create a safe user experience.

Reference: http://www.enterpriseintegrationpatterns.com