The great example of interaction between QA and development teams is a Publisher’s QA.
The Publisher is a very important and necessary link between the development team and the QA team. For the publisher, the most critical aspect of the game is not only interesting idea, but also the possible profitability. The Publisher’s testing can be considered as an acceptance testing. No matter at what stage of a product creation the Publisher joins the process, testing is important, and it is always done when the project goes through milestones, greenlights, decisions on its release, and further on when updates are released.
By conducting all the necessary tests, the Publisher can completely understand what decision to make about the future of the product. Such testing could define, is it possible to regulate finances more flexibly, decide how many releases are necessary (if it’s an already launched project), etc. The scope of acceptance testing is more predictable, than in-house team testing. It’s clear what to test, so the process doesn’t become endless.
Publishers mostly use acceptance testing because it lets the party that invests its resources into the project to conduct independent and objective control.
The money was lost because of some bugs that could not be detected by automatic or even smoke testing.
Example from our experience:
Our client who developed hyper-casual games made 1-2 releases a day with minor patches. And although we, based on our experience, strongly advised against this strategy, the management of the developers considered these recommendations excessive.
A small hotfix, which has been left unnoticed because of release without proper testing, decreased the rating on the market and all the metrics. This hotfix broke one of the game’s key mechanics. This bug has not been detected by smoke testing, while full testing was not performed.
Marketing activities were implemented, and the publisher lost about $20k, and the additional indirect expense was the activity of the support team that was working all weekend to sort user requests.
After this happened, all releases were examined by the QA4Games testing team.
The indie studio sent the release of their game to different publishers. After two rejects, the studio received feedback from the third publisher, which indicated that the game mechanics are totally unclear because of many problems with the game. The studio reps sent the game to our system for testing, and after fast fixes of all major, mostly compatibility bugs, they submitted the build, and the publisher specified what must be improved and changed to move forward. They spent just $790 and got a contract with a publisher. We are happy that we were able to help to successfully launch their product and hope that we will continue our cooperation.
If you’re a publisher, recommend that your contractors use our services before submitting and for approved games to make sure they will be accepted.
If you’re a developer, be sure to test your product before sending it to a publisher. It’s a small investment that guarantees you a competitive edge.
Start with qa4games, you wont regret it