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.

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

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.

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:

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.

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

WebSocket Testing Features.

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: