Testing, Release Management, and Documentation Writing for a Chat Solution

The client* offers a chat that integrates into different websites and messengers. It is a universal fully-functional solution that connects to other digital products – in particular, messengers and e-commerce platforms. The chat has also got video communication features and a shopping cart – the equivalent of a virtual shopping assistant.

* We recognize the importance of protecting our clients’ privacy and follow the policies to maintain their confidentiality and security. That is why the company name will not be disclosed.

Design and Functionality

When the team joined the project, it was just a support chat a business could connect to any website. The QA specialists were to test a user’s and an agent’s side of the product. Eventually, the company started to add more design customizations and themes. And when there are different themes, there are entirely different variations of the product that require full testing. As a rule, new features came along with the new designs.

Requirements and Documentation

There was no business analyst on the project, and it resulted in some problems with product requirements. Stakeholders communicated the main ideas well. However, when it got to details and nuances, the team needed more specifics.

Tickets for development featured only general descriptions of the features, which was problematic for further development and testing. Unfortunately, this is a typical issue for many teams and products.

The lack of well-written product documentation also makes onboarding complicated. As the product grows, the team members become unable to remember all of its particularities. Moreover, a specialist leaving a project creates a high risk of losing this knowledge.

Finally, different parts of the chat, just like any other software, don’t function in isolation. Even if there is no evident dependence between them, there are always some integrations, connections on the backend, or other points of intersection between the functionalities. Thus, an explanation of how a different part works is always required at some point.

At first, our QA experts worked with the chat interface, functionality of an agent’s side and the admin panel, and integrations with different messengers and websites. Later, the product was enhanced with new features: a video chat, a shopping cart, and a subscription platform developed from scratch. Altogether, it extended the list of tasks for the QA team.

QA specialists prepared checklists, checked the functional and non-functional aspects of the software, and logged the bugs in Trello. Meanwhile, our team also carried out some non-testing QA tasks, which helped to improve the development process in the long-term perspective.

Release Management

The QA team pre-approved the build on a test environment for staging and, later, for production. Although the staging and production environments were similar, some nuances could affect the build when it went live. Therefore, a QA specialist with good knowledge of the entire system was the one responsible for the releases.

Our QA team actively participated in building this release process. The specialists also suggested ideas for release/feature rollouts. In general, the QA team played a significant role in release management: the new build wouldn’t be deployed without the QA’s approval along the entire changelog.

Project Knowledge

Initially, each team member was in charge of a particular part of the product and not involved with the other aspects of the chat. The project grew considerably over a year. Many new features and integrations were added.

At some point, the QA specialists noted that their vacation and sick leaves affected the team’s performance and the quality of provided support. Thus, they decided to advance to a “universal team,” where each would have a good understanding of the product as a whole. The QA specialists communicated the risks and benefits to stakeholders, and it was agreed to give this idea a go.

QA engineers decided to dedicate two months to studying every part of the chat solution that was new to them. To play safe, each team member started their involvement with the unfamiliar part of the project with simple tasks.

Sometimes a QA specialist, who knew it well, prepared checklists, which were based on the tickets with a big number of checks and could be later used for writing test cases in TestRail. A person followed the checklist and asked the questions if something was unclear.

Documentation Writing

Documentation writing wasn’t the priority, but having clear requirements was a huge advantage for the QA team. Therefore, the QA engineers switched to requirement writing every time after completing their testing tasks.

For a while, the specialists were working on describing already released features, with the latest chat updates staying far ahead of the documentation. Eventually, the team managed to close this gap.

When documentation writing had finally aligned with the development, the process became more organized. Two specialists were writing the documentation, the QA Lead was to check it, and meanwhile, one more QA engineer was preparing a build for an upcoming release.

The team also participated in designing logic and requirements for the features developed from scratch, such as subscriptions on the client’s platform.