Today’s work has given me a deep understanding of why the term “full stack” has been particularly popular in the past two years, and almost every training institution is using full stack to promote their courses.
A truly excellent test function engineer is not a single one. You can find many bugs in its own function, or you can be very familiar with the process in the existing business. This is of course one of the strong functions of the test function engineer. But I always feel that because of the position of the test function engineer, in addition to completing the testing work that should be completed, raising BUGs, and writing use cases, external communication actually occupies a large part of the work category.
If I were an all-round engineer
Just like today, the function of the front-end page that I optimized in the later stage of the test project, in addition to the basic style and display, also needs to verify the interaction in various situations. Front-end engineers or back-end development engineers discuss current problems, help them identify the problem, or tell them the current problem in a way that they can understand, so that they can better locate the problem.
In fact, strictly speaking, junior test engineers only need to write use cases, demand requirements, raise BUGs, and help development to verify the generation of BUGs. That is enough. But if, in the face of different positions such as back-end development engineers, front-end engineers, product managers, etc., communicate with them in a way that they can understand, and quickly help them locate the problem, the level of testing, or the depth of testing, to a certain extent Has been greatly improved.
Just like this afternoon, when I was confronting a BUG with a colleague on the front end, if you read my previous article, you should know that I said that the code was changed by development. That’s right. The front-end changed the data structure, which caused problems with the back-end data reading. To be precise, the front-end changed the data structure and transferred to the database to the back-end colleague, and finally another colleague was responsible for reading out the data.
And when I talked directly to the front-end development colleague about the data on the page, he actually didn’t know what I was talking about. If he asked his leader to connect with another back-end colleague, the leader would know about the problem. If you connect with this front-end colleague, he should understand it all at once.
This should also belong to them to digest and communicate by themselves. However, if you want to know more about the realization of functions in the test, you can do it yourself, or take the initiative to communicate, and find someone to solve this bug. And after doing it yourself, you will find out how much you know and how much you need to add. It is also a way for testing to grow quickly.
And why do I say, let the front-end leader and the back-end development colleagues dock? Because if I guessed correctly, when the front-end leader and front-end colleagues explained to him to change the data structure, he directly asked him to change the data structure instead of telling him where the business was. And why the front-end leader understands what I said is that after I asked the leader to connect with the back-end colleague, I found the problem, and the front-end leader also understands the business well, so the way of communication is very fast.
Therefore, sometimes when communicating with testers, they will find that if the product manager can discuss the usability and user experience, the back-end development can discuss the code and database, and the front-end development can discuss the partial implementation of JS or the front-end. Then this tester is really an all-around tester.
However, I should not dig deep enough for the specific implementation of this BUG, and I can ask the back-end development why I need to modify it with database values. How they did it, they will tell me.
And today I still find a problem, that is, to make good use of Zen Tao tools, and directly refer to Zen Tao if there is a problem. This is the most efficient for development and testing. They fix the bug and directly assign the BUG back, and then test it. After the test, perform regression, so that the test can also ensure its own efficiency. What will affect your progress is that the BUG is not described clearly, or you need to assist in the development and reproduce the BUG, and the way to reduce the assistance in the development and reproduce the BUG is to attach the error message or the returned parameters to the BUG description, which can reduce The cost of communication. This is the point that I need to pay attention to later.
Today’s insights are shared here. After that, there are new insights, Xiao Orange will continue to share them.
