What job should I look for if I like playing games?
There are too many jobs to find, but as a game tester, I will definitely only introduce game testing.
Moreover, the more games you play, the deeper your understanding of games, and the more you like to delve into the characteristics of games, the more suitable this industry is for you.
There are many introductory tutorials on game testing on the Internet, but after my observation, I feel that these are not like getting started, but more like the path of a great master.
According to my understanding, this article writes about the simplest skills needed to get started with game testing. There are not many things, after all, getting started~
What is playtesting? What are the responsibilities of a game tester?
Literally, put the game to the test.
The responsibility of game testing, in simple terms, is to find bugs. To make sure the game is running properly, make sure the game performs as it needs to.
However, the specific situation still depends on the company. Different companies and different games have different requirements for testing. For example, some games place great emphasis on performance, as long as there is a problem displayed, they must be repaired, while games like Netease’s “Wild Action” have serious model wear, but they are rarely repaired, because others don’t care about it.
What skills do you need for game testing?
The skills mentioned below are must-haves! No company will be an exception!
Unless the company is really special.
0. Understanding "version" and "iteration"
is written as the 0th knowledge point because I think this is not a knowledge point, but maybe some people don't know it.
Version: Anyone who plays LOL has heard the phrase "one generation of gods, one generation of Galen". The version is the output that is actually delivered to the user. That is to say, after this update, the user can see of.
Iteration: iteration and version do not conflict, they can be together or separated. Iteration is a fixed-cycle development rhythm, which has nothing to do with players.
1. Understand the departmental composition of a project
Generally, it is composed of four departments: "planning-art-program-testing".
The planning is responsible for the gameplay, rules, data, etc. (the gameplay and rules will be written in the requirements, and the data will be written in the configuration table. A configuration table is actually an Excel table).
Fine art as the name suggests.
The program is coded, and they are responsible for functional problems.
Testing is your job, responsible for finding bugs and ensuring the integrity of the function.
Keep these in mind for now, and the third article below will explain the problem of raising bugs.
2. The use of version management tools and Unity
Don't be afraid of entry-level, these two are very simple, and the company will teach them. But it is not convenient to go into details here, because the details of each company are different.
So here is a brief explanation of what they are.
Version management tools: such as SVN, GIT, etc., what are their functions? ——Programs, planning, etc. put their codes, configuration tables or other changes on it, and after you log in, you can pull their changes to the game locally—that is, every time you pull, what you get is latest games. And when you find a reproducible bug (that is, the bug can appear stably), remember to pull it to the latest to ensure the accuracy of the test.
Unity: What is unity, you can find it on Baidu. But for game testing, it is equivalent to a relatively complete emulator (the emulator should understand? It is something that allows you to play mobile games on the computer——! My article can be said to be very small blunt). But as for how Unity runs your game and what functions Unity has, this is actually designed by your program, and every company is different.
3. The use of bug management tools and bug bill of lading
Bug management tools are used to manage bugs. There are many such tools, so I won’t give examples.
The general process is:
- find the bug
- record the bug
- submit the bug to the corresponding person in charge
- the person in charge will solve it and then transfer it to you (transfer test)
- you test the bug again (return bug)
- call back or pass (bug If it is not repaired, it will be transferred to him, and if it is repaired, it will be passed).
When you find a bug, who do you report to?
First of all, you have to judge whether this bug belongs to "planning", "art" or "program".
Mention configuration issues to the planner, for example, write 999 on demand, and you find "666" displayed in the value, indicating that the planning configuration is wrong, so bring it up to him and ask him to change it; submit function issues to the program, such as write click on
demand Just send 999, but you find that the value displayed is "1000", indicating that the program has rounded up, so ask him to change it; (Why do you have to ask
two different people for two questions that look similar? Good! Think about it~~~3~ 2~1~The answer is revealed)
(Because 999 shows 666, there is a high probability that the planning is wrong, so I typed the wrong number when configuring. It is basically impossible for 999 to be misread as 1000 Yes, the high probability is that the program has rounded up, so it needs to be mentioned to the program)
Art issues should be raised to the artist, for example, you find that he has drawn one less hand for the character (it is actually rarely mentioned to the artist, because The performance is so obvious that they usually find out before we test it).
Of course, in addition to "planning", "art" and "program", some companies or project teams also have other options when raising bugs, such as "audio" and "operation" (operation is the mailbox, activity-related modules )wait.
4. Look at requirements and write use cases
Requirements and use cases are more difficult.
Requirements are in the charge of planning, and simple requirements can be tested with a little glance, while complex requirements generally require writing use cases.
There are generally two situations for requirements, one is to add a new function, and the other is to update an original function.
You need to be careful when looking at the requirements. Some requirements are not written perfectly, so if there is something you don’t understand, you can directly ask the planner to explain or supplement.
The pictures in the requirements are for reference only, don't just look at the game and the picture and say it's a bug. Because the requirements are put forward first, it is normal for the pictures to look different from those in the game, especially for the needs of new functions, it is basically impossible for the pictures and games to be the same. Optimization depends on the situation. Sometimes the pictures and the game are the same. Of course, the main thing is to look at the text.
As shown in the figure below, this is a requirement written by myself as an example:
-
The above "12.0" represents the version number. The requirements are usually assigned to the team members by the test team leader. When the version changes, he may assign the wrong one (sometimes the title is the same but the version number is different. , assigning you the version requirements that you don’t need to test now). Therefore, you need to check when you get the demand, and ask in time if you have any questions.
The following "emoji package optimization" is naturally the title, telling you what this requirement is for.
Article 1—Change the avatar to a black boy: Then you only need to check whether the profile picture is a black boy. If the action is not written in the requirements, then you have to check whether it is reasonable, and ask the planner in time if you have any questions.
Article 2 - Change the text to white: Similarly, you only need to see if the text is white.Of course, just to be on the safe side, you still need to ask the planner when you encounter strange places. For example, although the text is all white, why is it all written "pig pig pig pig pig"?
As for who is planning this demand, there are usually two ways to look at it.
The first, of course, is to ask the team leader.
The second is to see who checks and accepts the requirement. Usually, after the requirement is developed, it needs to be planned and accepted first. After the acceptance is completed, it will be transferred to the test and handed over to you for testing.
When you find that there is a problem with the test results, ask in time, if you should raise a bug, you should modify the requirement document if you should ask the planner to modify the requirement document.
If the test results are OK, then click "Finish" - of course, there are still different regulations for different companies. Some require you to report to the team leader first, or ask for planning again.As for use cases, you don’t need to look up any definitions, just give two examples and you will understand.
Generally speaking—preconditions, steps, and expected results—these three are necessary, and the others only depend on the company's requirements, for example, some also need id or something.
Preconditions are the preconditions for you to do this step. For example, if you want to click on equipment, what can you do if you are not in the backpack interface, and what if there is no equipment in the backpack?
The steps are the operations you need to do, that is, what you want to check.
The expected result is how it should behave after you have done this step.
Of course, if the expected result does not meet, sometimes it is not necessarily a bug. It may be that the plan has quietly changed the requirements and has not had time to tell you. At this time, whether to raise a bug or not needs to be judged according to the situation (don’t worry too much, you will naturally judge after working for a while, if you really don’t know what to do, just ask in the group).However, before looking for a job, I still suggest that you try to write a use case yourself. This kind of thing looks simple, but there may be a lot of problems when you get started.
In addition, talk about the most important thing in testing - seriousness, carefulness, and attention to detail!
It also seems to be the simplest thing, but IMHO, basically no one can do it for newbies——!
After reading this article, can you find that I have written the words backwards in a few places?