6 Tips for Successful game testing

"A precise measure would be worth 1000 experts ' opinion. "--grace Murray Hopper This remark should be the most incisive overview of A/b test. It concludes why many game studios want to use A/b test to assist in the design and development process--that is, not stopping to guess what's going to work, but really figuring out the result. Anyone who has experienced the design process should know that there are better ways to make these decisions. This approach is to use the real data provided by the player in A/b test. Ab-test (from submitedge.com) but that's just part of the test idea. We must also know where to start. So this article helps developers better improve their business by providing 6 successful test tips. We must focus on some really important elements, namely, user retention, conversion rate, and profitability. It may sound like a no-brainer from a simple start, but it's worth noting – if you want to bring the test culture into your own team, you need to look for ways to get results quickly and with proven methods. This means taking a "tendentious" approach to quickly validate ideas rather than creating a huge and complex structure before testing. Fortunately, it is not difficult to do this. No matter what method you take, you can easily complete a simple test. The biggest drawback here is that you may be afraid to "change the game", but in any case the game will change in some way. We can mitigate fear by testing some elements of the less controversial player experience (but with great impact). This includes the delay of the first time a spot ad is presented in front of the player. We can quickly identify the impact of this change based on CTR, user retention, and other KPIs. An alternative guide role in the tutorial. I've seen the use of different roles in tutorials have different effects. Do not struggle at the design meeting, as long as the test is not over! Whether to render the registration page (if appropriate). Is it wise to let them register a game in order to deepen their relationship with the players? Or does this cause the player to lose? Please find the answer. When we start experimenting with some simple tests, we may need to invest extra time to get some really meaningful stats (game bang: If you're using a A/b test platform, it's not a problem), but it's worth it. So don't be paranoid about cutting corners. Delete Delay issues we want to encourage developers to test frequently and quickly. Because if a single test takes a lot of time and requires code modification, it will affect the creation of new applications and cause us to face higher failure test costs, which greatly affects the ultimate benefit of the test. The long test will only lead us into a risky, costly and time-consuming situation. Fortunately, we can easily solve this delay problem. The point is that we have to stop the engineer from participating.。 Because if every test requires an engineer to rewrite the code, perform QA, and so on, we can't do anything. In addition, engineers have more important things to do. By separating the test framework from the engineering cycle process, we can create a short-term test loop that is run by the product manager or marketing team. To do this, we need to create a "data-driven" game that really understands and agrees to open data points for testing. When we get to this point, testing is as easy as changing a number in a datasheet. Better yet, when we create a reasonable variable, the environment to change it becomes as simple as creating the initial test. We can see that the test results have a quick impact and turn to the next challenge. This approach also allows us to temporarily block the elements of the game that are not included with the test, thereby reducing the risk of the project. "Remove switches" sometimes cause problems. These problems arise when we encounter "failure" and create an agile and automatically adaptable data-driven culture. So be sure to reduce the impact of failure and draw lessons from negative outcomes. Your system must help the team get rid of the idea of "fear of failure", and the simplest way is to "remove the switch". You want to be able to completely control it while the test is running, and to prohibit testing at some point without waiting for an engineer's input or later to apply the release. Your test should cover the entire core gaming experience. The latter is the default, but it does not mean that we cannot perfect it, and we have to make sure that the delete switch can bring the player back to this default state at all times. The good news is that, based on the correct A/b Test QA program, you will find it much less necessary to use the "remove switch". But mastering this idea can help you experiment better, and that's the attitude you need to succeed in your test. Orphaned variables that sounds normal. But in designing tests it is easy to forget the basic principle that only some positive results are received but it is not clear why we can succeed in some situations. It is worth emphasizing that in designing tests we must ensure that only one object is tested. One example of how easy it is to forget this principle is to provide specific content to a particular player group – the effort to test the effect of changing the price of a particular commodity. We may want to "support" the test by inserting ads between the relevant players ' groups. But when it does, it turns out that we're testing two things at the same time--price changes and the use of information inside the game. But we never even discussed the design and content of the information. The correct way to do this is to present the ads to all groups, offer two prices and then identify which is more appropriate for the game's internal purchases. We can determine the effectiveness of price changes if there is an increase in the internal purchase of the game, although this is still a test of whether to spot ads. Similarly, when testing content changes, such as the description of a product, we need to focus on something more specific andThere are repeated changes. From this we can see that some of the descriptions are more effective than others. This is a very helpful method. Check the longitudinal impact when testing, you need to predetermine the criteria for success. This step is very important. At the same time we also need to define transformation events, such as the completion of tutorials or special purchases, which are closely linked to the test itself, so we need to take the time to examine the longitudinal effects of the test. I mean we can learn more about the way variables and control groups behave over time. After a moment's meditation you will know why the "comprehensive examination" is so necessary. We are perfectly able to design a test that uses aggressive game internals to push players to make specific purchases. If this offer is deceptive, it is not difficult to guess that the retention and long-term benefits of the user will fall-even if the core test results are positive. With this in mind, we need to always focus on the "overall business" experience of various variables and control groups. You must always be aware of what you are looking for and make a note of any KPI that has a negative impact. If we look at a variety of parameters in multiple tests, it is clear that in the near future we will be able to achieve truly meaningful results. Change is the variable we expect, but on this basis it is meaningless. Setting ourselves up for specific KPIs that we want to change will reduce the risk of "wrong". Ab-testing-diagram (from breezi.com) distinguish between new users and existing users select a user group to test sometimes also requires a certain plan. It is convenient to set the test framework and target the test to a small group. You may want to target the test to a user in a particular area, or exclude some users from the test (game state Note: For example, your most loyal user). You always want to be able to test new users individually. That is, you want to test to find out what users think when they first play the game. Let's say you're testing the layout of the game spots (i.e., the crossover with other applications in your network). As part of the test, we are changing the key layout in these spots to drive higher clicks. The problem with this approach is that existing users will use the existing UI, and because they have been hit by commercials, their "acquired sexuality" will affect the final test results. Just as existing users will default to click on the wrong location, or will be frustrated by changes in the UI. So you can only get some false results, that is, existing users with emotional click. Instead, you should select new users who have never seen the UI to test them so you can get an accurate evaluation of the UI performance. This is the "first effect" in psychology. So you should create a test framework that targets only the new user.