NFT Art toys Online platform
Implement QA Testing to increase user retention
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.
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.
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.
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.
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.
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.
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 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.
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.
Kotelov effectively organized the QA testing process on our project and assigned a tester to implement it. There were always a proactive position and suggestions from the guys to improve processes.