1. Good communication
I believe everyone has seen various jokes on the Internet that complain about programmers' incomprehensible style. While laughing, they thought deeply. As a test engineer, is this not the case? Usually communication skills become a huge gap between test engineers and other cooperative departments, and also become the biggest bottleneck for the growth of test engineers. Do you often encounter the following situations:
- "Have you tested this function? Why are there still bugs after testing?"
- "I just finished taking the test, why did I change my requirements again?"
- "Why did xx secretly submit something again? Can you tell me in advance for testing?"
- "Is this functional prototype still used in such detail? Do you understand this is common sense?"
- 。。。。。。
With all this going on, a certain test engineer fainted in the corner crying.
Faced with these explicit or implicit laws of the jungle, how do we achieve survival of the fittest?
An excellent game test engineer has to solve many difficulties outside of testing work, and communication is the first priority. When you encounter problems, you need to communicate more and take the initiative to communicate. The most taboo thing is to lower your head and work hard. As a result, you spend a lot of time and find out that you are doing something wrong at all, and you have to start all over again. This not only wastes your own time, but also delays the construction period of the entire project. The probability is greatly increased.
Communication is a two-way street. We cannot blame all problems on the unclear needs of the cooperation department or the developers' lack of rigorous consideration. When encountering problems, we must also reflect more on whether we have communicated well. The author once encountered a situation where testers sat next to developers and did not bother to ask questions when they encountered problems. They just lowered their heads and worked behind closed doors.
Ask questions when you encounter them, and don’t assume that what you think is what you think.
2. Responsibility
Do game test engineers have holidays? I have to sadly admit that there is no vacation, not even a night for deep sleep. . .
In fact, I only want to talk about two words in this section: responsibility .
No matter how late it is, whether we are having dinner or watching a movie with our girlfriends, after a phone call, we will go back to the computer without hesitation to solve the problem. Maybe some people think we are abnormal, maybe some people ask us why we work so hard, I don’t know. Faced with the guilt of family and friends and the sense of responsibility for work, we chose the latter.
There is no lofty reason, no touching story, no personal heroism. It is just because we choose to do it well. This is our responsibility.
3. Continuous efforts
"You are over 30 years old, have a family and children, and your kidneys are weak. Can you still compete better than young people?" This is a topic that a group of our old testers often talk about at gatherings. Yes, testing work is indeed a physical job sometimes, especially when the project is about to go online. It is common to stay up for days and nights. What’s even worse is that the new people joining the work now are all born in the 90s. Looking at this group of people living in a lively and energetic way Colleagues couldn’t help but express various emotions.
However, the old man is still ambitious and has great ambitions.
We are still persisting. The testing work itself involves a lot of repetitive work. When we chose this career, we also chose to persist. Persist in doing the work you are responsible for, insist on expanding the depth and breadth of your own testing, insist on learning new testing technologies, and insist on passing on your knowledge and experience.
Persistence is the cornerstone of our testing work.
Many people are wandering at the door of giving up and continuing. The test is too hard, but they grit their teeth and pass it.
Looking back at the blood and tears on the road, they are the embodiment of glory and dreams.
4. Be proactive
"This is not my job, why should I do it?" I often hear this complaint. When the total amount of work remains unchanged, if someone does less work, someone will naturally do more work, and vice versa. It is difficult for any individual to accomplish one thing alone in the Internet industry. Most of it requires teamwork. To recognize this fact, we must try to understand the things we cooperate with and the people we cooperate with, so that our entire team can operate efficiently. .
5. Have confidence in yourself
"Can this version be released?"
"Don't worry, it's no problem."
This is the most pleasing piece of music I have heard, and it is also the most domineering moment for the test engineer. At this moment, I seem to see the light of God. This is the confidence of an excellent test engineer.
This confidence comes from our detailed testing over and over again, and from our careful and diligent efforts under great pressure.
We don’t need to be respected by everyone, and we don’t need to be understood by everyone. Whenever a version is released, it is enough to have this confidence.
6. Calm mind
In the face of efficiency and thoroughness, we sometimes face a dilemma. As soon as some testers find a problem, they immediately go to the development team to ask them to modify it. This phenomenon cannot be said to be bad, but they just feel that they are not calm and calm enough. Personally, I think that after discovering the problem, we need to test it several times to ensure that it can be reproduced and record the reproduction steps in detail. At the same time, we try to expand and think about whether the same problem exists in other modules and verify it. It may be more appropriate to make sure that these tasks are completed before discussing the problem with the development team. Draw inferences from one instance and classify them into categories, which is very beneficial to the efficiency of the entire project.
7. Keep pace with the times
The technologies applied in each project are different, and even for the same project, new technical solutions will be continuously added as the project cycle develops. Of course, there are also various changes in work processes, which may often trouble us. After all, it is very difficult to change a person's habits. How do we view and adapt to these changes that may occur at any time? First of all, we should not resist. Changing old habits will indeed make us feel uncomfortable and even cause emotional fluctuations. What we need to think about is can we prevent these changes? If not, how should we adapt? Or do we have a more reasonable change plan? Makes the whole project a little better.
It seems to me foolish to resist unnecessarily without thinking about how to make change more reasonable. Second, we should open our minds and dance with change. Change is eternal, and we should learn to continuously expand and improve ourselves during change, so that we can become the beneficiaries of change.
Practical cases
Optical theory is useless. You must learn to follow along and practice it in order to apply what you have learned to practice. At this time, you can learn from some practical cases.
If it is helpful to you, please like and save it to give the author an encouragement. It also makes it easier for you to search quickly next time.
If you don’t understand, please consult the small card below. The blogger also hopes to learn and improve with like-minded testers.
At the appropriate age, choose the appropriate position and try to give full play to your own advantages.
My path to automated test development is inseparable from plans at each stage, because I like planning and summarizing.
Test development video tutorials and study notes collection portal! ! !
