Put into the work scene, let's first look at the testers generally call what kind of development personnel "reliable" development?

Test Engineer A: "Developer A is very reliable, he develops modules with fewer problems."

Test Engineer B: "Development B is also very reliable ah, to him the bugs he fixed very quickly."

So, in this scenario, "fewer bugs" and "quicker to fix bugs" are indicators that the developer is reliable.

So let's see, as a test engineer, what kind of qualities will be called "reliable" testers?

Test Manager A: "Test A is very reliable ah, write the use case step by step clear, newcomers to the hand can also accurately execute the use case, test work."

Product Manager B: "Test B is also very reliable ah, his test ideas are very broad, always stand in the user's point of view to put forward reasonable product optimization views."

Developer C: "The test small C is quite reliable, he mentioned the bug positioning accuracy, additional reference information is very comprehensive. People who are new to development can also easily locate the problem to fix it."

"Reliable" testers must have the following skills:

1. clear testing process, clear logic

2. wide coverage of the test, the depth of the depth of the test

3. for the positioning of the bugs is accurate, the reference information is complete

4. good communication skills

Overall, you test, you test, you test, you test, you test, you test, you test, you test, you test, you test, you test, you test, you test, you test, you test, you test, you test. >The overall message is: you test, I'm not worried!

So, how can we become a reliable test engineer?

First of all, if you want to achieve a clear test process and clear logic, you need us to have good business skills. That is:

1, proficiency in business logic: in the work, whether it is to read the requirements document, or listen to the development of the staff, the product manager to talk about the requirements, we can get to the product business knowledge. What we have to do, is in the process, actively accumulate product business-related knowledge, to master the product's function and realization.

2, to be able to discover the hidden business logic between different modules: after mastering the product features and implementation, we can carefully study the product to find out whether there is a hidden business relationship between modules that seem to be different. For example, to modify personal information, then after the modification, other modules call personal information, whether it is followed by modification together? This is something that may not be reflected in the requirements, but needs to be explored after we familiarize ourselves with the product.

3, take the initiative to expand the work outside the business knowledge: do testing, will inevitably encounter some industry knowledge, in addition to the work can be accessed, we can also actively learn some industry knowledge, for our testing work will help. For example, the financial industry, we measured the product is a stock product, then we can go back to learn some knowledge of futures, foreign exchange knowledge, or the financial industry in general industry standards, such as performance indicators, safety indicators. This is our in-depth work, are helpful.

Second, the location of the bug

Want to accurately locate the bug, we need to have some basic knowledge of the preparation. For example, a certain understanding of the operating system, a certain understanding of database principles, a certain understanding of the product architecture. Then if there is a lack of knowledge in this area, in addition to learning after work, you can also accumulate in the work. Every time we submit a bug, the developer will give repair opinions, according to these opinions we can learn some defects positioning experience.

Three, communication ability

Communication ability is not necessarily born, through the practice of the latter can also be achieved. Generally communication consists of 2 parts, i.e. sending and receiving information. When we express an issue, we need to make sure that we can express our message correctly and without ambiguity. For example, when we state a problem: "The login function does not work properly." When the developer or other tester receives the problem, he or she will ask, "What do you mean it doesn't work? Does it mean that the login failed? Or is there no response when you click the login button? Or is it that the login message is incorrect even though the login was successful?" If we put it another way, "I enter the correct username and password on the login screen, but clicking the login button prompts for an incorrect username and password." If you look at it this way, the question is clear, and there is usually no misunderstanding or ambiguity. Let's talk about reception. When we listen to someone talking about a problem or an issue, we need to make sure that we understand the information we receive correctly, and find out what is wrong with it, and then confirm it. Listening carefully is not only an ability, but also a quality. We often hear two people communicate, A said A things, B said B things, two people say is not a thing, the result is still struggling to communicate, really is the torture of both sides, wasted a lot of time to do useless.

Finally, to sum up, to be a reliable tester, fundamentally by our responsibility, careful and strong desire to learn from the internal drive to guide our behavior. Seize every opportunity to learn, accumulate experience, and improve ourselves in all aspects. The shortest piece of a bucket determines its maximum capacity.

For more on the fundamentals of software testing, you can watch this more intuitive video explanation: web link, I hope my answer can help you.