Blog

Online gaming is booming, and the demand for online games will be persistent in upcoming years. The global gaming market was valued at USD 173.70 billion in 2020, and it is expected to reach a value of USD 314.40 billion by 2026. One of the important growth factors is, perhaps, the pandemic, since multiple lockdowns made people stay at homes and turn to game platforms to pass the time. But it also created unexpected load growth on gaming servers all around the world.
Obviously, in such circumstances the QA sector of load testing for online games is increasing, too. In this article, we will outline what is load testing in games, why it is an absolute must to performance test games on a regular basis, what types of performance tests are applicable in the online gamedev industry.

What is k6? Who is it for? k6 is a popular open source tool for load testing built for engineering teams. Born as a startup, k6 was acquired by Grafana Labs in 2021, perhaps for its ability of integration with a really large number of third-party tools. In this article, we will lay out our experience of working with k6 and our opinion on how to make the best of using it.

Mobile games require performance testing before they hit the markets, otherwise a game built for a high-end device can get complained about by thousands of users and cause financial and reputational losses. Luckily, most key market players do realize it and run performance and load tests on a regular basis, during development, before every next release, etc., so the testing process becomes a necessary routine.

A wise man once said, Only those who do nothing make no mistakes. That is why we devote this post to mistakes often made in load and performance testing projects. This post was written not only for managers who are up to their first testing project, but also for leading engineers who have had many of them and have many stories of their own to tell.
The focus of this text is on performance testing, although there obviously may be many mistakes in any part of a complex IT project.

In Part 1 of this tutorial, we had a close look on how to update your load testing environment to make load testing results automation possible. Instead of preparing your load testing report manually for days, with the environment discussed above, your data structure will depend on you, not you on your data structure.

In Part 2, we’ve tackled a problem that engineers in every load testing company complain about, — namely, how Grafana slows down the system, — and several other quick fixes to your Grafana dashboards. We plunged into multiple databases and data sources, retention policies and tag filters.

Finally, in this part we want to enable you to automate your test reports using all the infrastructure you have hopefully designed after reading through parts 1&2.