Never Miss Anything With this Checklist on Testing Online Chat Running on WebSocket | HackerNoon

Hi, I’m Alena, QA Lead! In this article I will talk about testing online chats running on WebSocket. I will provide a comprehensive checklist of checks, analyze what types of testing are needed and provide practical examples of using test design techniques.

Let’s start with theory and discuss,

What is WebSocket?

The WebSocket protocol is designed to exchange data between the browser and the server in real time. Data is transferred via the protocol in both directions without breaking the connection and without additional HTTP requests.

WebSocket is often used in online chats, online games, social networking marketplaces that require real-time interaction.

Using the example of a web application, a WebSocket connection is established by sending an HTTP request:

1. The client sends an HTTP request with specific headers. Among these headers there is the Upgrade: WebSocket header, which just indicates to the server that the client wants to switch from a regular HTTP connection to the WebSocket protocol.
2. The server confirms the request by returning Response Code: 101 Switching Protocols.
3. After a successful switchover, the client and server can exchange data in real time via a WebSocket connection.

Example client request to establish a WebSocket connection using the Socket.IO library:

📌 Sometimes, it is useful for the testing team to understand which library is used in the project. This is necessary in order to build the right strategy for testing functionality and decide on the tools. However, the library itself is not critical for testing; it is enough that the QA engineer has a clear understanding of the processes and principles of working with the protocol.

GET – this is the HTTP method that is used for the WebSocket connection. /socket.io/?EIO=4 – path to the resource on the server and its protocol version used, the Socket.io service is shown as an example. &transport=websocket – the necessary request parameters can be passed; as an example, a parameter is given that indicates that the transport protocol used for the connection is WebSocket.

This indicates the domain of the server to which the connection is made.

• Connection: Upgrade

• Upgrade: websocket

Required headers indicating that the client wishes to migrate to the new protocol from HTTP to WebSocket.

• Sec-WebSocket-Key: oLhMxYk714RNlBoiJesy8A==

Required header, which carries a unique key generated by the client to confirm that it has the right to request a connection from the server.

• Sec-WebSocket-Version: 13

Required header, which transmits the version of the WebSocket protocol.

In practice, optional headers may be sent in the request, which can be useful for correct operation or optimization.

Let me give you some headers as an example:

• Accept-Encoding: gzip, deflate, br, zstd

The header indicates the compression methods that the client supports. It is useful for optimizing data transfer, but its absence will not prevent the establishment of a WebSocket connection.

• User-Agent: Mozilla/5.0 (Windows NT; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/xx.x.x.x Safari/537.36 Edg/xx.x.x.x

This header conveys information about the client’s browser and device. It can be useful for collecting statistics.

WebSocket Testing Features.

• As stated above, WebSocket provides real-time data exchange, which means that it is necessary to test not only connect and disconnect, but also correct operation over a long period of use, check that the connection remains stable and messages are processed successfully.
• Before data begins to be transferred, WebSocket has a handshake stage. This is also important to test to ensure that the connection is correct and secure.
• WebSocket connections can be vulnerable to various attacks, such as message interception and user spoofing. Testing should take into account penetration and vulnerability scenarios.
• In addition, you need to check the correctness of the data transferred between the client and server. You should make sure that the data is not distorted or lost, and if we are talking about chats, then this includes checking the sending and receiving of different types of messages: text, different acceptable and unacceptable attachment formats, links, etc. A large number of different messages will need to be generated and their contents checked for consistency.
• Duplicate or undelivered message scenarios must be considered because WebSocket does not use message delivery confirmation mechanisms.
• Also, WebSocket does not guarantee the order of message delivery (especially under high loads); this can lead to data desynchronization. When testing, you should pay attention to the order of sent and received messages, situations when messages arrive simultaneously, etc.
• Thorough testing of functionality is required, developing detailed test scripts for each function.
• An analysis of the data transfer rate is required to ensure compliance with the requirements of the software product.
• It is necessary to check that errors are handled correctly and do not lead to failures.
• Testing should cover all popular platforms, devices and browsers.
• Performance and load tests are required.

How is WebSocket used in online chats?

As we already know, a WebSocket connection supports real-time two-way communication, which is perfect for online chats. This interaction allows the user to instantly exchange messages, which improves the quality of the product being developed.

Let’s take a quick look at the interaction process in practice:

1. When a user opens a chat, the browser sends a WebSocket request to the server. After confirmation by the server, a permanent connection is established.
2. The user writes a message in the chat – the text is instantly sent to the server via WebSocket, and the server immediately transmits it to the manager (as an example).
3. And vice versa, the manager sends a message – the user instantly receives this message in the chat.

Below I will provide a checklist for testing online chats, broken down by type of testing. Please note that depending on your project, checks may be supplemented and expanded. For maximum test coverage, use test design techniques.

The checklist is given specifically for the user part of the application in question.

I won’t go into detail about checking API requests, as this topic deserves a separate post.

Let’s imagine that the functionality of an online chat between a client and a site manager has been developed. The following business requirements exist:

The chat is available to all users of the web application from the moment they register in their personal account. The user can open a chat by clicking on the envelope icon in his personal account. After clicking, a chat window opens in which the user can type a message in text (up to 255 characters) and send an attachment up to 10MB (jpg, png, docx, doc, txt, pdf, csv). The user can edit a sent but unread text message an unlimited number of times, but cannot delete it or unsend it. The chat records the date the message was sent and the status of reading by the administrator.

The manager opens the chat through the admin panel (the interaction of the two services occurs through API requests). The manager can also send a text message (up to 255 characters) and an attachment up to 10MB (jpg, png, docx, doc, txt, pdf, csv). In addition, the manager has additional interaction options: the manager can mark the message with the “important” flag, as well as remove the flag. The chat records the date the message was sent and the user’s reading status.

Checklist for testing online chats.

📝To view the online chat testing checklist, please visit my GitHub: https://github.com/AlenaQuality/qa-testing-online-chat

Typical and atypical bugs in online chats.

Check out common mistakes to supplement your online chat testing script.

1. Problems establishing a connection – the WebSocket connection is broken.
2. There may be a problem with duplicate messages due to double user connection (using two or more browser tabs or two devices at the same time).
3. Problems sending or receiving messages. Messages may be duplicated, not delivered, or appear in the wrong order or format.
4. Problems with timely updates when new messages arrive and problems with notifications.
5. Problems with displaying date and time (format, time zones).
6. Messages may not be visible at certain screen sizes (for example, on a narrow screen, text may run out of bounds and be hidden, or long messages may not wrap to a new line).
7. Problem with messages being lost when the connection is lost. The server may not acknowledge receipt.

Share in the comments: what bugs 🐞 have you encountered in your practice? How did you eliminate them and prevent further occurrences? 🙂

Testing Recommendations.

My recommendations are as follows:

• Use WebSocket testing tools in your work. For example, Postman copes well with this task.
• Use traffic sniffers such as Charles Proxy or Fiddler. They will help you analyze WebSocket traffic.
• Enter test documentation, write detailed test cases.
• Automate testing to speed up the testing process and increase its efficiency.
• Perform regular regression testing of online chats to ensure that new changes do not lead to new defects or deterioration of existing functionality.
• Prioritize regression tests to focus on the most important chat features and scenarios.