As a game function tester, when I occasionally talk to my friends about work, they will say: "You are good at your job. You usually play games and do your work while playing." Sometimes in order to avoid others understanding this, I simply say I am engaged in game development. At this time, someone will say: "It's just writing code, right? Your output looks pretty good!". At these times, I am often helpless, because many times before, I actually didn't say it. Be clear about what professional capabilities you have as a functional tester .
The threshold for functional testing seems to be very low. It seems that anyone can apply for this position, but I know in my heart that not everyone can do this job well. So what capabilities are required for functional testing, and why can we do this job well? This problem has troubled me for many years, until I came to NetEase. Through continuous learning from colleagues around me, reading articles shared by outstanding colleagues, and through continuous exploration and thinking at work and in my spare time, I seemed to have a little enlightenment. I would like to share my understanding of the functional testing position and how to become a better game tester .
As a functional tester who has been engaged in functional testing for many years, I believe that if you want to do a good job in functional testing, you must improve yourself from both hard and soft strengths, so that you can maintain stable performance and handle daily functional testing work well.
01. About hard power
I remember that when I was working for two or three years, students from other industries once asked me, is it difficult to do game testing? What do you need to know? I still clearly remember how I answered him at the time, and it’s funny now that I think about it: It’s not difficult to do the test, as long as you love playing games and know how to use a computer. Now if someone still asks me this, I will definitely tell him patiently what abilities I think are required for game function testing:
1. Write test cases
Writing test cases should be regarded as a basic skill for testers to get started, but it is also an important ability throughout the entire career. It is like the zamabu when learning martial arts. The more solid you practice the basic skills, the better you will be in the future. Being more proficient and writing test cases better will not only improve the quality of our testing, but also save testing time and improve our testing efficiency. It will also help improve our testing thinking and facilitate collaboration with other colleagues. cooperate.
But we usually encounter two big problems when writing test cases. One is the time cost. This problem may be more obvious in already launched projects. Due to the rapid version iterative development, there is often no time left for testers. In fact, there are not many. Many people follow up on more than one function. It is no exaggeration to say that almost all QA of online projects have experienced the situation where even the testing time of the function is squeezed. So in response to this problem, as a functional test we How should I do it?
I suggest you start from the following aspects:
The first thing to do is coordination and communication. We can first communicate with the project manager and relevant responsible persons to confirm the release time and priority of the functions, etc., to see if we can gain more time for the writing of test cases; secondly, we must clearly understand the importance of our own work
. Sort out the work you are currently doing, avoid the more important ones, and see if some work can be put back appropriately to leave sufficient time for writing use cases for the current higher-priority functions; the last step is to streamline and condense the use cases
. If the previous two points cannot ensure that there is enough time to write test cases, then don't insist on writing test cases. You can combine the functional documents with your own understanding of the version content and some of your own experience to output a brain map. List the more important test points.
The following figure is the three most important elements in my opinion. First, we need to ensure the integrity of the process without paying too much attention to the details. Secondly, numerical related content is a testing point that must be paid attention to. Finally, when players participate in activities or participate in functions, Storage of data changes, both normal and abnormal situations need to be taken into consideration.
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
I also want to emphasize that whether it is a test case or a test point, do a self-review of the use case/test point. Considering the time cost issue, you basically don’t have to think about use case review. My personal suggestion is to develop the habit of self-review. After each writing, take some time to read what you have written from beginning to end. In fact, many times We can find some missed important test points. After all, the possibility of us writing the use case perfectly in one go is still very small.
The second big problem in writing test cases is the maintenance cost. This problem may be more common in all stages of game development. Many functions or gameplay of projects that have not been launched require continuous planning and polishing, so it is very likely that a function will never be released. From the initial planning to the final launch, N versions have been modified in the middle, and even after the development and testing are completed, there may be disruptive changes. For projects that have been launched or are about to be launched, each function may undergo major optimization or iteration through internal testing or online feedback, as well as continuous iteration and updating of versions. In this case, the maintenance cost of test cases is obviously a big problem. There is nothing we can do about this situation.
First of all, we must do a careful demand analysis to reduce demand loopholes as much as possible, thereby reducing subsequent functional changes. For example, when doing short-term activities, I will always raise it at the tripartite function meeting on how to deal with future players after the activity. When disposing of consumed props/currency, is the system automatically recycling it or is the player actively decomposing it? This prevents the planning from changing the requirements during the development process because the situation was not taken into account, causing us to maintain the written use cases; secondly, when writing test cases, the splitting of modules should be as clear and independent as possible. For example, many newcomers prefer to write use cases like this:
If the planner wants to change the gameplay rules or completion conditions or participation methods, etc., then to maintain the test cases, you need to constantly change it in the above activity process. It is very likely that if you change this one, you will miss something else. One piece. But if we can split the activity process into more details, such as "participating in activities", "activity rules", "activity settlement", "activity delivery", and dividing the modules more clearly, then when we encounter demand changes, we You can modify the use cases of related modules faster and better; finally, according to the "time management-important and urgent four quadrants" principle, the maintenance of use cases is an important and non-urgent matter. Do not be overly obsessed with maintaining use cases and consider the scope of the impact of the changes. , the test time left for us by the changes, we can consider the scope of use case maintenance as appropriate, or record the content that needs to be changed, and then find time to maintain the use cases afterwards. Even some changes with little impact do not require us to maintain the use cases.
2.Bug tracking capabilities
Bug tracking ability is one of the most important abilities for game testing. Many people feel that half of the work is done when they find the bug. The remaining half is to wait for the developer to correct the bug and verify it. In fact, this is not the case. . From discovering bugs, submitting bugs, locating the causes of bugs, following up and promoting bug fixes to final bug verification, this is a complete closed loop, and every step is a test of our personal abilities.
Have you ever wondered why some bugs can be discovered by others but not yourself? Why is it that the bug fixes followed by others are very efficient, while the bugs followed by oneself become worse and worse with each fix? Let’s take a look at each step to help you better track bugs.
(1) Bug found
First we need to familiarize ourselves with the function settings. On the basis of carefully reading the functional documents, having an in-depth understanding of the functional settings and doing a good job of document analysis will help us better complete the design of test cases, preparation of test environments, supplement of test data, etc., for example, when I want When testing a function that compares combat power with other players, after becoming familiar with the function settings, I can clearly understand which development data needs to be displayed when comparing combat power. Then I will definitely not simply use the gm command directly. Upgrade character data, because many systems and development gameplay of this kind of data have not yet been opened, and some comparison test points of development system data will definitely be missed. At this time, it is necessary to simulate the data of online top players to ensure as much coverage as possible Go to all the function points in the game that have an impact on combat power;
Secondly we should strictly enforce the use cases. We need to ensure the complete execution of the use cases during the testing process. At the same time, we can check and fill in the use cases in a timely manner during the testing process, so as to improve our test coverage as much as possible and better discover bugs. Some people may become passive and lazy after working for a period of time and are unwilling to strictly implement use cases. Some people may skip the execution of some use cases because time is urgent and have a fluke mentality. Covered test points may often cause serious bugs after going online, which is not advisable.
(2) Submit a bug
We should be as standardized as possible when submitting bugs. Standardized bug submission helps developers better understand bugs and fix bugs faster. It also allows us to verify more clearly after bug fixes, avoiding time reasons and forgetting the environment, conditions and performance of the bug at that time. Important information.
(3) Locating bugs
The ability to locate bugs is often mentioned during social recruitment interviews, because the ability to locate bugs can well reflect a QA's problem analysis ability, problem positioning ability and logical reasoning ability, etc. It is a reflection of a person's work ability and experience. Good bug locating ability not only allows us to clearly understand the causes of bugs, so that we can draw inferences from one example and discover other potential bugs, it can also provide us with good communication guarantees with developers, and can also greatly increase the speed of bug repair, thus Improve our testing efficiency. Now I would like to share my opinions and experience on how to quickly and accurately locate the cause of bugs.
First of all, recording the test steps, test environment, test data and test results in detail is a necessary condition for us to locate the cause of the bug. No matter how experienced and capable you are, if you lack this information, it will be difficult or even impossible to locate the cause, especially Some bugs with complicated steps to reproduce and occasional bugs. Therefore, when encountering a problem, we should try our best to recall the complete operation steps. If necessary, we can take screenshots and record the screen to clarify some important factors and data in the test environment, because before the specific cause is located, any environmental factor The data in the test and the test may be breakthrough points, and reasoning and analysis can be carried out based on some performances of the test results.
Secondly, we need to use log or debugging information to locate the cause of the bug. Commonly used examples include: printing out some key parameters in the code logic of the test content; it doesn’t matter if you don’t understand the code, developers generally record logs of some key parameters; we can also use the protocol testing platform to view the process of some operations The information sent and received by the client can be used to analyze whether the data transmitted by the server is incorrect or a problem with the client itself; we can also use some online logs to try to reproduce the bugs encountered by players, thus helping us quickly To locate the cause of the bug, by analyzing the player's behavior log data, we can determine what operations the player performed before and after the problem occurred, thereby narrowing the scope. Together with the analysis of the player's behavior data, we can try to guess the cause of the bug, so as to finally achieve Regarding the recurrence of online bugs and locating the causes of bugs, in short, we need to continuously improve our own capabilities and learn to use some data and tools to help us quickly and accurately locate the causes of bugs.
Finally, we can make reasonable guesses through the accumulation of experience. For example, an accident occurred in a certain game. Some development systems did not deduct the consumed materials when upgrading. Through observation, we found that these upgrade materials occupied two grids in the backpack, and were sorted out. When backpacking, it obviously complies with the merging rules but will not be merged. It is speculated that there is a high probability that there is an abnormality in the prop itself, which causes the upgrade to not deduct materials. Further analysis of these materials found that the upgrade materials for the affected functions all have new gameplay that can be opened on that day. It was speculated that there was an abnormality in the materials produced by this function. After further communication, it was found that the new gameplay is a cross-server activity. The props obtained by this gameplay have been logically changed when this function was launched. This gameplay is prohibited in cross-server status. The obtained reward props are placed in the warehouse. At this point, we can roughly locate it through step-by-step conjecture and reasoning. Due to the modification to prohibit the placement of props obtained in the cross-server state, the props are abnormal, which in turn triggers subsequent problems. Of course, we are not making baseless random guesses. We can understand the implementation logic of the function by communicating with developers, which will help us make reasonable inferences and guesses about the cause of the bug when we encounter problems. We can also summarize similar problems we have encountered in the past, which will give us inspiration to make inferences and conjectures when we encounter similar problems again. You can also learn from other colleagues and read the sharing of some classic bugs, learn to summarize the causes of classic bugs, and boldly guess the causes when encountering similar problems.
(4) Follow up and promote bug fixes
In fact, what best reflects this is our subjective initiative, which I will discuss later in the soft power section.
(5) Bug verification
Many people must have experienced changes due to bug fixes. Although the problem point itself was verified to be ok, some other related content had problems after it was released online. After the bug we submitted is fixed, many people may only conduct a simple verification of the bug itself when verifying, and those who are slightly better may think about whether it has affected other related functions. Here I would like to talk about my understanding of bug verification.
First of all, the verification of the bug itself is definitely necessary, but the so-called verification of the bug itself may not be comprehensive by some people. To give a simple example, for a certain function interface in the game, if you quickly click the close button when the interface is opened, the interface will be closed before loading is completed. When you open the interface again, the interface will be messed up. So when this bug is fixed, will some people simply verify the same reproduction steps to see if there will be interface confusion? But considering that the problem is caused by the incomplete loading of the interface, I may also verify that the connection happens to be disconnected and reconnected when the interface is opened, the scene is switched when the interface is opened, and the automatic pathfinding and NPC are completed when the interface is opened. After interacting, etc., you may also think about whether there are similar problems with the loading of other interfaces. Therefore, the verification of the bug itself is not limited to the verification of the operations in the reproduction step, but must have certain extensions and analogies.
Secondly, the verification of coupling functions. As a large and complex software, games have many coupled functions. The functional logic may be related, it may be some common interfaces or interfaces, or it may be some underlying logic modifications, etc.
There are three verification methods I recommend here. One is to communicate with the developers and consult the functional modules and related logic that the current modification may affect, so as to conduct effective targeted verification; the other is to experience the game in depth. If you are familiar with the gameplay and each functional module, you can have a clearer understanding of the relationship between the modules. Then when verifying the bug, you will think of the relevant content that may be affected, and reduce the missed testing of coupled functions; the third is to communicate with colleagues in the group, Especially for calls to some common interfaces and modules, the relevant QA will know more clearly whether there is any correlation. You can send relevant change information to the group to remind colleagues who may use the module to return to the relevant content in a timely manner, thereby reducing coupling. Missing functionality. The above can only be used to minimize the missed testing of other problems caused by bug fix changes and provide more comprehensive and accurate verification. Interested students can learn about precision testing.
The last step is to verify the impact on the overall function after the bug is fixed. For example, when testing the copy, the boss is designed to add a layer of damage buff every once in a while, but due to a bug, the layers of damage buff do not overlap. Then after the bug is fixed, we need to verify the feasibility and difficulty of clearing the dungeon again. What I want to say here is that some bugs have a great impact on the integrity of the function or part of the process. After these bugs are fixed and verified, the integrity of the entire function or part of the process needs to be further verified. This requires us to be familiar with functional design, clearly analyze the impact of each problem on the whole, and clarify the correlation between the logic in the function, so as to conduct timely and effective verification of other related content in the process when verifying bugs.
In short, bug tracking ability is one of the very important abilities of functional testing. We need to continuously improve our own abilities, constantly summarize and accumulate, actively share, communicate and learn, and constantly try to use more platforms and tools, so as to continuously improve our bug tracking Efficiency and quality to ensure the quality of our version.
3. Risk awareness
As a software tester, especially a game tester, you need to have a strong awareness of risks. Maybe because we ignore a certain risk, the company will suffer huge property losses. This kind of case also happens in the game industry from time to time, so what should we do? How about improving your risk awareness? And how can we avoid risks? Here are my thoughts based on my personal experience and understanding:
(1) Improve risk awareness
Regarding improving risk awareness, I think we can start from the following points:
① Gain an in-depth understanding of game play and player behavior. In order to discover potential risks and raise them, we must conduct an in-depth analysis of the gameplay and understand the players' behavioral habits. Only then can we combine the players' possible behaviors and gameplay to discover possible problems. For example, we all know that there are studios in many games, so if our gameplay is designed to obtain tradable props by participating in daily activities, we must avoid a studio that earns money by earning props and disrupting the in-game economy. risks of. We can also understand player behavior through game forums, some social software, etc., so as to better integrate game play design, discover and propose risks in advance.
② Learn and become familiar with the development process. This is mainly to help us avoid release risks. For example, during the development process, we may first develop the core gameplay and functions, and then gradually improve other content. Then when the testing time is not so abundant, we can use the test left shift strategy according to the program development process. After they have submitted After the core gameplay and functions are completed, we intervene in advance to pass the interface test and test the core logic first to avoid being unable to release on the scheduled date due to lack of time. For another example, during a three-party function meeting, the planner wants to achieve a certain performance in a certain way, but this method may occupy more memory, may easily generate redundant data, and may also involve data synchronization refresh frequency issues, resulting in data synchronization delays. risk. If we are familiar with these development logics, we can explain it clearly to the planner, and at the same time communicate with the program to come up with a better implementation method that can also meet the planning needs. This requires us to continue to learn and be familiar with the implementation of some common functional logic, some data synchronization, refresh logic, etc. in our daily work, so that when we encounter similar problems, we can promptly raise risks and make improvements.
③ Strengthen the summary of your own work experience and share learning with colleagues. The same problem has occurred in other projects, so when your own testing work encounters similar situations, you must consider whether the risk also exists. In addition, we can also pay attention to information from the same industry. On the one hand, we can learn lessons from serious accidents that have occurred in other games. On the other hand, we can master the latest testing theories and methods in real time, so as to improve our risk awareness in many aspects.
(2) Avoid risks
Regarding how to avoid risks, I think we can consider the following points:
① Avoid from the demand. Many times, the plans proposed by the planners have certain risks, which requires us to be familiar with the game and related mechanisms, raise the risks early, and provide alternatives. For example, we all know that data changes in cross-server situations are prone to problems in data storage. When planning and designing cross-server activities, we can make suggestions for the acquisition and deduction of some props and return them to the original server for settlement, thereby avoiding cross-server data storage. risks of.
② Eliminate collaboration risks. We can decide which people’s functions to test by analyzing whether the current work content is a lot, whether there is a habit of procrastination, and the number and frequency of bugs that have been generated in the past. Special attention should be paid to communicating more and urging development when testing functions. Progress, which people need to invest more effort when testing their functions. For example: a planner often likes to copy and paste when arranging tables, resulting in repeated field configurations in different rows of data, then test the functions he follows up. At this time, you may need to plan well and make time to write the table and check it, or check the relevant configuration manually to ensure the accuracy of the configuration.
③ Adequate test plans and timely reporting and communication to eliminate release risks. There may be many influencing factors during the testing process that prevent us from completing the test and releasing it on time, such as poor quality of the test version, some demand changes and new requirements during the development process, cross-department collaborative testing but the other party is not actively cooperating, etc. For such problems, we need to estimate the risks in advance and make a test plan. For some problems that affect the test progress, we need to proactively coordinate and communicate, and report them to the leaders of various departments in a timely manner. When encountering problems, we need to solve them and reduce external factors. Impact on test progress.
④ Log embedding. Almost every function will have some important operations, changes in important data, and some behaviors that can easily cause misunderstandings among players. It is recommended to keep log records, not only to monitor whether some important data changes abnormally, but also to monitor when players report problems. Verification and confirmation can also sort out player data after a problem occurs to facilitate partial rollback processing. It can also help us analyze player behavior and reproduce some bugs that are not easy to reproduce.
⑤ Log monitoring. It is not enough to pre-embed logs. We also need to monitor logs. On the basis of monitoring logs, we need to throw alarms for some abnormal situations so that we can know online abnormal situations in a timely and accurate manner. . Generally speaking, we can consider log alarms from three aspects: First, independent log alarms. For example, when we monitor the Log of the copy clearance time, we can set the minimum expected clearance time. When the clearance time appears online and is less than this minimum Alarm when the value is exceeded, and then analyze whether there is a bug in this situation when the alarm occurs; second, associate log alarms, for example, we can monitor whether the player's consumption exceeds a certain proportion of the recharge amount by associating the player's recharge and consumption log Scope, and then promptly further analyze whether the player has problems such as buying gold, exploiting loopholes to make illegal profits, etc. when an alarm occurs; the third is data statistics alarm, for example, for a certain server-wide restricted delivery in the game, the statistical setting of the total acquisition amount of the player For example, for some special placements in the game, the comprehensive probability statistics obtained by players can be set to alerts, etc., and then when an alarm occurs, it can be further analyzed in a timely manner to see whether the total amount of placement is wrong and whether the placement probability is wrong.
⑥ Make function switches. The function switch can turn off the function in real time when an accident occurs on our line, respond quickly and stop the expansion of the problem, and stop the loss in time. It is an important first-hand protection when potential accident risks occur.
⑦ Grayscale release. According to the characteristics of the function itself, some functions can be released in grayscale. Grayscale release can expose potential problems in a small area. After grayscale release, the scope of our focus can be narrowed to the grayscale server. When problems occur online, The scope of impact is small and the processing cost is low. It is a better strategy to avoid risks.
⑧ Make an accident plan. When we have done a good job in the previous steps, and it is also difficult to avoid no problems at all, then for some more important functions, such as cross-server PVP, full-server events, etc., we need to take action in advance to address possible risk points. With a good accident plan, if an accident occurs on the line, we can face it calmly and facilitate our handling of the accident. Minimize the impact on activities/competitions due to accidents.
In fact, in addition to the three important hard skills mentioned above, there are many more hard skills required for game testing, such as compatibility testing, performance testing, protocol testing, database related knowledge, network basic knowledge, etc. In short, when we When testing different functions, some specific hard skills may be used.
Although you may not be familiar with compatibility testing, you need to know that before a new project is launched or an existing project releases an expansion pack, you must make an appointment with the special testing team in advance to do compatibility testing; although you may not be very good at doing performance testing, But you need to know that when testing large-scale multi-person activities, you need to find relevant test colleagues to communicate the requirements and do some performance testing; although you may not be good at interface testing, you need to learn to use the protocol testing platform to verify some important interfaces ...In short, we need to be fully familiar with every aspect of the testing work, make good use of various platforms and tools, and at the same time give full play to the strengths of different colleagues, work together, improve test coverage as much as possible, and ensure version quality.
02. About soft power
In addition to hard power, as a game tester, you also need to have some soft power so that we can cooperate with other team members to promote the smooth progress of the testing work. Under the conditions of the same hard power, people with different soft power will show different work Compared with hard power, efficiency and results can be improved in a relatively short period of time through systematic learning. Soft power is not so easy to change. It requires us to persist consciously for a long time and develop good habits to improve. The following soft skills are what I personally think are very important in functional testing.
1. Communication skills
Communication skills are very important in testing work and almost all jobs. We are a team, we have colleagues who live together, and we have different functional departments that need to work together. So communication skills are like the bridge between us. How to achieve accurate and efficient communication so that each other’s needs and wishes can be perfectly conveyed to each other. , will greatly affect the efficiency and results of our work. Regarding the daily communication work of QA positions, I personally think that there are some unique problems that need our attention:
(1) Cross-functional communication requires the use of simple and understandable language
When communicating, we need to use simple and easy-to-understand language and try to avoid using overly technical terms or ambiguous words, especially when communicating with colleagues from different functional departments. Some people may feel that a certain term is inappropriate when communicating. The most basic knowledge of QA, but maybe the person you are communicating with is not QA, and you know nothing about QA knowledge. Simple and easy-to-understand language can ensure that the content or opinions expressed can be understood. At the same time, we also need to pay attention to the impact of tone and expression to ensure that our expression is respectful and friendly.
(2) Avoid conflicts and reduce ineffective communication
When communicating, we should stay as calm as possible. We should give priority to expressing that we understand the other party's point of view based on listening more and empathizing, and then express our own views and opinions. When there is a disagreement, we should remain objective. Attitude, patiently express the reasons for different opinions and possible consequences, instead of causing language conflicts, wasting communication time, and thus causing an ineffective communication.
(3) Learn to control the situation and improve meeting efficiency
In many meetings, we often encounter this phenomenon. The meeting that could have been completed in a short time ended up taking a long time. At the same time, the participants did not feel that they got more useful information due to the extension of the meeting time. information. In this case, we often need to learn the ability to control the situation, minimize communication and discussions that deviate from the theme of the meeting, and reduce overly detailed issues that do not need to be discussed in the meeting. As a QA, I believe that most of you have been troubled by this problem during tripartite function meetings, so you might as well try this: First of all, you need to know clearly what the theme of the meeting is, what problems need to be solved or what communication consensus is reached, and what can be left behind. Communicate details privately after arriving at the meeting; secondly, always remember the topic during communication, and do not go off topic or be led off topic; finally, when others deviate from the topic or discuss in too much detail, find the appropriate entry point and speak boldly Point out problems and correct the direction of the meeting, proactively control the situation, reduce redundant communication, and refuse to deviate from the main track of the meeting.
Finally, before ending the conversation, summarize the key points of the discussion to ensure that both parties truly understand each other's views and opinions and confirm the consensus reached, rather than assuming that they have understood each other. This situation is also very common. For example, in a three-party function meeting, the planner expressed the functional requirements. Maybe the QA and developers understood them differently, but they did not summarize their respective understandings, and they defaulted to thinking that the requirements were very simple. , it is easy to understand, everyone should understand it the same, but when the function was proposed and tested, it was discovered that there was a lot of ambiguity, and the final delivery results also deviated greatly from the planning requirements.
2. Be proactive
Functional testing is a position that requires teamwork. If there is a lack of initiative, no matter how capable a person is, he can only passively perform work, passively wait for testing, passively wait for bug fixes, etc. When you are passive in everything, your testing efficiency will definitely decrease, the testing progress will not be smooth, and the testing quality will not be ideal. So how should we give full play to our subjective initiative and make ourselves proactive at work? I suggest you start with the following points:
First of all, clear goals, ranging from following up on a large function to timely following up on a detailed optimization. If we lack initiative in our work, we can first ask ourselves, what is the goal of my current work and when will it go online? , and work backwards to figure out when I should finish writing the use cases, when I should complete the testing, and when I should perform regression. Through dismantling it bit by bit, I can clarify the small goals of each stage. In short, only when you know what your goal is, you will find ways to achieve it.
Secondly, when we have a goal, we must make a plan to achieve it. A more comprehensive plan will definitely take into account what to do when encountering blocking problems. This can encourage us to be proactive in the process of achieving the goal. To advance one by one and eliminate blocking problems, and finally achieve the goal.
Again, appropriate feedback. An employee who only knows how to give feedback may not necessarily be an excellent employee, but an excellent employee must know appropriate feedback. The feedback here includes upward feedback (let the leader know in a timely manner what you have done, how you are doing, and whether there are any What problems did you encounter and how did you solve them), positive feedback (getting recognition for what you have done), everyone hopes to be recognized, and we can get some positive feedback through upward feedback or positive communication between daily colleagues. In order to stimulate your own enthusiasm, you must know how to claim credit, take the initiative to claim credit, and claim credit reasonably.
From another perspective, we need to break through boundary thinking. Maybe sometimes our thinking is too limited and we only see the things in front of us and lack thinking about the overall situation. For example, some people will only submit bugs after discovering them, and then ignore them, thinking that they have discovered bugs and submitted them anyway. In the end, if the function cannot be launched in time, I will say that the developer did not fix the problem in time. As everyone knows, when this kind of problem appears to you many times, then you need to reflect on yourself. Why can the functions followed by others be stable before going online and can be returned calmly and calmly? Why can the functions followed by others be tested in time and launched on time? Why is it that the functions followed by oneself are always in a hurry the day before release and the functions are still very good? Unstable. This is what I mentioned in terms of hard power, regarding bug tracking capabilities, the ability to follow up and promote bug fixes. The entire development process and testing process are intertwined. If you do not follow up on the progress of a certain link or promote it, the direct consequence will be that the overall process lags behind.
There is another understanding of boundary-breaking thinking. One of the rules of promotion in the workplace is that you can only be promoted to a higher rank by doing things at a higher level first. Only if you open up the situation and break the boundaries of ranks, do things at a higher level, and show that you have a higher rank. Only with your abilities can the company be assured of promoting you. In short, maintaining a high level of initiative at work can help you complete tasks better, improve work efficiency, enhance teamwork skills, and improve your sense of self-worth. We should proactively seek opportunities to improve our skills and knowledge and be willing to take on additional responsibilities to make the entire team more successful.
3. Innovation ability
There is a point of view in the book "The Art of Software Testing" that I very much agree with: "Software testing is a very creative and intellectually challenging job." I think that special software such as games are more complex than Dozens of times or hundreds of times that of conventional software. The creativity required to test such a software also far exceeds the creativity required to develop the software. If game testing is compared to painting, then hard power is the painting skills we need to paint, and innovation ability is the beautiful painting created by our unrestrained thinking based on our painting skills. So how does innovation ability help functional testing? I think the following aspects are more important:
(1) Promote the improvement of testing processes
Like all industries, the testing industry is also an area that is constantly developing and changing. We need to constantly explore new testing methods and tools. If we, as a tester, lack the ability to innovate, we will fall into a fixed testing mode and be unable to adapt to new testing needs and challenge. People with innovative abilities can constantly try new testing methods and tools, promote the improvement and optimization of testing processes, and improve testing efficiency and quality. Now more and more companies are beginning to adopt agile testing methods, putting forward higher requirements for testing work. More and more companies are beginning to require "cost reduction and efficiency improvement", and more and more competing products are competing for "product quality". "If we lack the ability to innovate, we will not be able to adapt to the workflow and requirements of agile testing. If we have the ability to innovate, we can improve testing efficiency and quality by exploring new agile testing methods and tools, thereby promoting the improvement and improvement of the testing process. optimization.
(2) Discover potential problems
One of the purposes of functional testing is to discover potential problems and ensure the quality and stability of the version. If we lack innovation ability, we may not be able to find some hidden problems, which will lead to serious accidents after the version is released. Testing with innovative ability Engineers can often discover some difficult-to-detect problems by using innovative thinking and designing new test plans. For example, when some colleagues are testing some complex functions, in order to verify the correctness of the interface transmission parameters and locate the cause of the bug, they use the protocol testing platform to monitor the interface data during some important operations. I think this is an innovation and may This colleague's technical ability is not yet up to the level of interface testing, but he can make reasonable use of tools and explore new and effective ways to verify potential problems. This is innovation.
(3) Improve testing efficiency
Innovation capabilities can help us improve testing efficiency. As the scale of game products increases, mobile games are no longer as simple as they were N years ago. Testing methods are constantly being updated, and the complexity of testing work is also increasing. If game testing lacks innovative capabilities, it may not be able to effectively cope with the complexity of testing work, resulting in low testing efficiency and worrying test quality. This requires us to have the ability to innovate and continuously explore new testing methods and tools to improve testing efficiency and reduce testing costs, thereby better ensuring version quality and even accelerating the release rate of versions.
For example, before a major version of an expansion pack is updated, we can use automated testing tools and scripts to perform regression testing on most of the more stable functions in the version to improve testing efficiency.
Another example is the protocol testing platform and code dyeing platform launched by Leihuo in recent years. I think these are innovations. Although these testing theories themselves are not invented by us, turning them into tools and platforms has also greatly improved protocol testing. coverage, lowering the threshold for code coloring. We need to keep up with the times, strive to be familiar with and master the most cutting-edge technologies, and explore the application of AI technology in daily work to improve testing efficiency and version quality. Just like NetEase's values, going from 0 to 1 is innovation, and so is going from 1 to 1.1.
In short, in our daily work, we must be good at and dare to explore new ideas, new methods, and new technologies based on the existing ones, and innovate anything that will help improve testing efficiency or test coverage, etc. that will help improve the version. A method or tool for ultimate quality.
4. Learning ability
Learning is a way for a person to learn and master new knowledge and skills. In this modern society where technology in all aspects is developing rapidly, learning ability is undoubtedly a very important ability. Why do I think learning ability is a very important soft power for game testing positions? Maybe for some traditional industries, the speed of technology innovation and method updates are not that fast, but for games and even the entire software industry, it is another story. scene:
First of all, game testing is a very complex and diverse field. We need to constantly learn and master new testing technologies, tools and methods in order to adapt to changing product and testing needs. For example, in response to the agile development implemented by more and more companies, test shift left has become an important testing solution from a certain time. Only by constantly learning new methods can we better collaborate with the development team. In addition, with the rapid development of cloud computing, big data, artificial intelligence and other technologies, as game testers, we also need to constantly learn new testing technologies and methods, such as cloud testing, performance testing, security testing, etc., to adapt to the ever-changing Testing requirements. Of course, a person's energy is limited, but even if you are not proficient in these testing methods, you at least need to continue to learn to understand, become familiar with, and deeply understand their necessity.
Secondly, learning ability is also an important factor in game testing to improve work efficiency and quality. We need to constantly learn and master new testing tools and methods to improve testing efficiency and quality. For example, regarding "precision testing", I had never been exposed to this concept before reading the relevant sharing. Although I had experienced online bugs caused by failure to perform precise testing, I also had a headache on how to avoid this type of problem. problem, but before knowing this concept, I didn’t know how to avoid such problems. But after reading the relevant sharing, we can have ideas and directions to break this curse and avoid this problem through precise testing. Bugs such as online problems caused by missing test content caused by changes.
In addition, good learning ability can also help us better cope with challenges and problems at work. In our daily work, we will more or less encounter some problems, such as the construction of test environment, the design of test cases, and the analysis of bug causes. Etc. Only with good learning ability can we learn and master problem-solving methods and techniques in a timely manner, thereby improving our own problem-solving abilities and efficiency.
After understanding the importance and necessity of learning ability for our tests, how should we have good learning ability? The following are my personal suggestions:
(1) Maintain curiosity and exploration spirit
As testers, we should always maintain curiosity about new technologies and new methods, actively explore and learn, and constantly master new testing knowledge and skills.
(2) Invest time and energy
Each of us should devote a certain amount of time and energy to learning, and make full use of learning resources and environments, such as experience sharing platforms, salons, etc. Don't just talk about learning, you must invest to gain something.
(3) Make a study plan
If you don’t know your learning direction, I suggest you set a long-term goal based on your shortcomings pointed out by your supervisor in each year’s performance, split it into several short-term goals, and study in your spare time or with colleagues. Communication, etc., through learning to constantly make up for your own shortcomings and eliminate shortcomings.
(4) Practice and application
We need to apply the learned knowledge and skills to actual work, so that learning can improve our actual work efficiency and gain a sense of accomplishment, which in turn promotes our motivation to learn. I have a deep understanding of this. When I was in my last company, most of my daily testing work was just dot and dot. At that time, I was interested in learning code, but due to the environment, I didn’t know how. It is applied in actual work, so although I occasionally learn it, my coding ability has basically not improved. After coming to NetEase, it provided a good table checking framework that allowed me to easily get started writing table checking scripts. I saw many excellent colleagues analyzing the causes of bugs and doing code reviews by looking at the code. These all urged me to keep trying to read. Code and analyze code, so as to improve your coding ability to a certain extent. This is the importance of combining learning and practical application.
03. Conclusion
In fact, whether it is black box testing, white box testing, or automated testing, each of our colleagues is a functional tester. Some people become better and better in their working lives and learn to go deeper through code reviews. Intuitively check for loopholes in code logic, learn to save time by replacing a large amount of repetitive work with automation, learn to use table checking to replace manual inspection of configuration errors, and learn to use borrowed code dyeing to check test coverage and discover Missing test points, etc., by learning a variety of testing methods to assist functional testing, improve testing efficiency, improve test coverage, and ultimately achieve our common goal and improve the final quality of the version.
I remember what was written in the book "Exploratory Software Testing": "Human beings are not perfect and will inevitably make mistakes. So software created or invented by humans naturally inherits this characteristic." Software is like this, so software testing is derived. In this position, the same is true for software testing. Since it is done by people, none of us can guarantee that the content we have tested is perfect, that is, none of us can guarantee that there is nothing missing in our test content, but as long as We strive to explore and continuously improve our soft and hard power. I believe that each of us can become an excellent functional tester.
Finally, I would like to thank everyone who read my article carefully. Looking at the increase in fans and attention, there is always some courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly!
Software Testing Interview Document
We must study to find a high-paying job. The following interview questions are from the latest interview materials from first-tier Internet companies such as Alibaba, Tencent, Byte, etc., and some Byte bosses have given authoritative answers. After finishing this set I believe everyone can find a satisfactory job based on the interview information.
