Project Goal

Implement QA Testing to increase user retention

Project features:

• Huge amount of active users
• Setting up QA Testing process from the scratch
• NFT-project

How it was:

The in-house development team was equipped with developers but lacked QA expertise and specialists. The product was rocketing and the need to quickly set up top-notch QA testing aroused.

What our team did:

Analytics and testing flow set up

Even before we actually signed the contract with the client, we described all the bugs that we found during the pre-project study, and also recorded a video of the incident so that the client could see how we would find and file bugs in Jira. Afterwards, the testing implementation structure was distributed by sprints.

Test-cases

Before we came in to the project, the testing was carried out without specific scenarios. Part of the bugs just slipped through and a huge part of the possible user actions were not taken into account.

TestRail Implementation

With introducing TestRail we structured all the documentation. And now we have got to see all the failed check-lists and test-cases during smoke and regression analysis testing. As a result, we minimized the amount of possible bugs at the release stage.

Implemented a service for recording bugs “Bird eats bug”

Introduced “Bird eats bug” service to speed up the process of the bug’s issue identification via recording bugs with a console display, system and network information.

Redesigned the testing process by introducing new stages

Improved the Kanban board for testing, we singled out 3 columns: testing, testing pass and ready to prod. New flow is the following: all the tickets after the development stage automatically fall into the “testing” column. After successful testing, the ticket enters the “testing pass” column. If any defects or bugs were found, the ticket is sent back to the development team for revision. When a sufficient number of tickets has accumulated in the column “testing pass”, the tickets are retested before the release.

Smoke testing

We carried out a smoke test to check whether the main functionality works on the project. As well as to transfer the build back to the development team in case of obvious bugs. This way there is no more need to waste time on a deliberately defective version.

Regression testing

Regression testing is always performed before a release, it shows how the new functionality affects the previously developed one, and in general, it checks the overall functioning of the system. After successful regression testing, tickets are placed in the “ready to prod” column. And only after that the release stage begins.

Project issues and 502 error NFT

Every day, ChikoRoko service rolls out a new NFT at the same time. Hundreds of thousands of users open their apps to pick it up. At such moments, we often caught 502 errors due to overload. The customer solved this problem by optimizing testing resources. Undoubtedly, the introduction of load testing is the next mandatory step. The customer, not devoid of self-irony, created an NFT with a reference to the memory of this bug.