Reading: Thoughts on a girl's growth journey from software test engineer to supervisor

Insert picture description here

Today I read an article from the Internet in which a girl shared her successful experience: the struggle from a software test engineer to a supervisor. After reading it, I have a lot of feelings. I hope to share it with you and hope to bring you some hope and encouragement. She used to study economics and trade. Because of her strong interest in the testing industry, she studied software testing engineering at a Beijing school after graduation. In less than a year of work, she has been promoted from tester to test supervisor. She has accumulated many bits and pieces of experience in studying and working, so she will write down the experience of this year to share with everyone.

Original text:

Entering the testing industry: Interests, knowledge
, to be honest, I don’t have a long time doing testing work. After finishing the software testing engineer course, it’s now more than a year. However, I am willing to study and work by myself The accumulated bits and pieces will be shared with you.

I entered the testing industry entirely because of interest. Interest generates enthusiasm for learning and work. It is really true. From the time I chose to enter this industry, study and work, from tester to test supervisor, I am happy, fulfilling and have a sense of accomplishment.

I think that after deciding to enter the testing industry, we must make more preparations and accumulations in this area. First, we must have a solid theoretical basis for testing. This knowledge is not only to be learned when learning, but also in future work. Continue to improve. Second, there must be certain industry knowledge. When looking for a job after graduation, some do mobile phone testing and some do outsourced testing. What I do is an ERP product. Everyone knows that ERP (Enterprise Resource Planning) is an enterprise resource planning system, which refers to a management platform that is based on information technology and uses systematic management ideas to provide enterprise decision-makers and employees with decision-making operation methods. I was exposed to ERP before I studied the test major, so I developed in this area when I graduated looking for a job.

When it comes to finding a job, I think that meticulously crafting a resume is one aspect, but also flexible interview skills. Sometimes you have to apply what you have learned in life to the interview. I remember that when I went to the interview for the first time, it happened that I just saw an interview-related program on TV the night before the interview. As a result, it was used by me when I went to the interview the next day. It was when I asked about salary. I think this is a problem that many people, including myself, find it a headache during interviews, because if you say too much, it won’t work; if you say less, it won’t work. At this time, you have to use some skills.

At this time, you can first tentatively ask what the other company's rules are when recruiting this position? After you understand this, you can measure the relative salary ratio based on your own technical ability. In addition, it depends on the strength of the company. Another point is the general treatment of this position in the industry. In this case, when you state your salary requirements, if the company you are applying for is smaller, but there is still room for development and you want to try, the other party will consider the possibility It’s because you have a general understanding of the company’s strength that made such a condition, not your own technology is not good; if you see that the company’s condition is still relatively good, it is a company with certain strength, at this time, you You can raise your own worth appropriately.

My application went smoothly. I applied for the first day and went to work the next day. I remember talking for about two and a half hours during the interview, and I passed the interview in one go. What I am also proud of is that I am the only one in our company who has become a regular employee within two months.

New arrivals: familiarize yourself with the environment and blend in as soon as possible

When entering the company, you must first be familiar with the company's environment. In some large companies, they may give everyone time to familiarize themselves with the environment and arrange some corresponding training. The company I entered at the time was relatively small and did not have any relevant training. At first, our department manager brought some relevant materials and documents to the network manager to configure the working environment. However, a small company has the advantages of a small company. It will quickly let you get involved in the work and assign tasks to you.

Therefore, you must become familiar with all aspects of the company's environment, especially the personnel environment, within one to two weeks. I think interpersonal relationships are also an important aspect of the entire company. To exaggerate, it is even more important than your own job. Because mastering technology is a question of your IQ, and interacting with people is not so simple, because our interests and hobbies may vary greatly, and our personalities are also introverted and extroverted, so we interact with people after we enter the society and enter the workplace. It really tests a person. If you have a good interpersonal relationship in the company, the coordination of all aspects of the work will be smooth, and the progress of the work will be smooth.

There is also the need to become familiar with the company's test environment, operating system, development language, and platform as soon as possible, and then to understand the company's products and master product-related knowledge. For example, our company is a system such as a distribution group and finance developed by ourselves. When you want to understand the company's products, you can ask the product R&D department or the design department for some related documents, get involved in the industry as soon as possible, and get familiar with the test items you want to do. To be honest, I am studying economics and trade, not computer, so I was a little dizzy at the beginning, I just took the product and fumbled there by myself, and wrote a product instruction by myself. For such things, there may be special matching options in large companies, and in small companies, you may have to learn products by yourself. However, I think this is a great exercise, and you have discovered another aspect of your potential.

Test Plan

Writing test plans is like what we learned in class, test plans, test cases, and start our testing process. This is the time for specific applications. When writing a test plan, you should ask the R&D department to detail design documents, product specifications and requirements survey instructions (product instructions) such related documents. If you are in a large company, his design department will write product instructions or some test protocols. There is also his development plan, because every step of your test is carried out according to the development progress, and the development plan is essential. Finally, according to the above documents, from time, content, resources, tools used, and manpower arrangements, such a simple test plan has been formed. Like a small company, he is very concerned about who finishes the work on which day. For a relatively complete document like the kind we used to learn, it is necessary to work around in such a small company, because they do not have many The manpower and material resources do not have much time to read such documents. Writing test cases must first be written according to the characteristics of the product. Before the product is formed, you certainly don’t know or know the characteristics of your product, but you can roughly figure it out based on its framework, and write it into the document as much as you can think of, and then test it. Continuous improvement in the process.

If you suddenly find a better test case during the execution of the test, you must add it in time. If you do not add it, it will be a big loss for you, because you may still need such documents in your future work. , Or the person who takes over your work in the future, he may see this document, which will be of great help to his future work. In large companies, there are dedicated test designers to write these things, and in small companies it is the test supervisor or tester.

For our company, I do everything from test cases, test plans, and test execution. At first it was because the company was relatively small and I did it myself. I originally hired an assistant for me, and it took me about a month or two. My personal feeling is that unless you are very skilled in recruiting, familiar with all aspects of the industry and testing technology, you can get started with it. If this is not the case, recruit a fresh graduate who doesn’t know much about the testing industry, and the small company has fewer manpower, you don’t have time to train him, and you have to work and don’t have that much energy. Go and teach others hand in hand.

Be considerate when designing test cases and don't repeat them. As far as my work is concerned, making ERP products is to pay attention to the excuses of each module and data testing. There are many interfaces. For example, the sales module and the financial module will overlap during testing. This should be paid attention to. The industry is relatively strong. Next, let's talk about execution testing. To be executed in accordance with the test case. You can't say that you have done test cases and you don't read them when you work. This will not help your work. Because if you execute according to the test case, you basically do it according to your own ideas, so you know exactly where you are. The biggest advantage of this is to reduce repetitive work and improve work efficiency. I think this is very important whether it is a small company or a large company, or the work itself.

Then, it is best to record the test day, the purpose is to know where to test yourself, so as to avoid duplication of work. As far as I am concerned, I keep a test diary every day when I am doing tests. One is to record how many bugs I found today and where is the work? What work has been done. I found it very interesting to record the test day. How many bugs are detected every day, although I recorded it on the bag management tool, I still want to record it.

When I first came into contact with this execution test when I went to work the first day, I remember very clearly that I found 65 bugs. I think this shows two problems. One is that I work very hard, and the other is that there is a problem with the R&D department. So, don’t think that R&D is very powerful, very awesome, you will be a little embarrassed.

At the beginning, our company was also the three main pillars of Lenovo, Founder, and HP, but I did not feel embarrassed, although they were very arrogant. Basically small mistakes can be brought up, they think it is not a bug at all. But you can bring it up when you arrive at the seminar, technical exchange meeting, or evaluation meeting, because this is the most basic and necessary job for you as a tester, and it is also your serious and responsible attitude towards your work. Communicate with developers. This is very important to testers. I mentioned this before. Everyone is not doing things independently. They need to cooperate with each other in their work, especially the testing work. If there is a problem, you need to communicate with the R&D staff in time. If you can't even communicate well, then there is no way for your testing work to proceed. In this, you have to adhere to your own principle, that is, right things and wrong people, because if this product has problems, it has bugs, so someone must be responsible for modifying it. You can't say that the other party is the department leader and you dare not stick to the questions you raised. The second is to stick to other test principles, which are some of the knowledge we have when we study theories. Because, the curriculum design when we study is set according to the project, and many things basically coincide with the actual work. As the person in charge of the test, I set myself a basic workflow during the test work, which is now being implemented as the department's rules and regulations. That is, after entering the bug, I will describe the bug below, whether the developer wants to modify it, why it needs to be modified, and what is the approximate time. If you urge the other party in this way, it will help the progress of the work. Otherwise, if the work is not completed, there will be mutual excuses. After the bug is found, the developer is urged to modify the bug. Also pay attention to bug management tools. You must use bug management tools well, and you must also urge developers to use bug management tools well. Because many developers are still lazy. He will tell you at the time that there are any bugs. Can you just show it to me on my machine?

This is a bad habit and time-consuming. Therefore, you must urge them to use bug management tools. This is what I deeply understand, and it was also raised at two larger company meetings, and it was finally accepted by everyone. Everyone knows that generally there are more male colleagues in development and more girls doing tests. Don’t be too tough when you ask questions. You should remind him euphemistically in your daily work that everyone will generally not embarrass you too much. . Not only the work is solved, but the relationship between colleagues is also very harmonious.

Next is the preparation of the test report. We have all learned these in the employment class, which are the background, content, and pass rate of the test. And the advantages and disadvantages of the product, as well as your suggestions for the project. After all this is done, the test evaluation meeting will be held.

My personal opinion on automated testing

I personally think that automation is becoming a trend now. Nowadays, many companies, no matter whether they are big or small, whether they have used this testing tool or not, they will ask you how many testing tools you use, and will you automate testing? I also encountered this problem when I went to the interview. The first thing I asked him at the time was, has our company done other tests other than manual, whether it is performance or function? They answered no. A product that has not been tested manually cannot be replaced by tools.

Automated testing cannot replace manual. Automated testing can save time and improve efficiency. But if you don't use it well, it will increase your workload. If your needs and interfaces continue to increase, then automation won’t work. I think the company that is suitable for automated testing is one that has strict product requirements on safety and performance; the other can be maintained by a dedicated person. Companies that fail manual testing, frequently change requirements, have fewer staff, and produce changes to the product’s GUI are not suitable for automated testing.

After accidentally sorting out so many bits, I really didn't expect that I could still write very well. It is estimated that this has something to do with my work in the company besides testing. As I said, because we are a small company, I wrote some product instructions, product installation instructions, including customer service training. In addition to the test, I will also do some work that is not related to the test, such as the preparation of the test system, the OA product administrator, and the pre-sales consultant. I think this is how I exercised.
Insert picture description here
The above are some video resources I collected, which helped me a lot in this process. If you don't want to experience the feeling that you can't find the information during self-study, no one answers your questions, and insists on giving up after a few days, you can join our deduction group [313782132], which has various software testing resources and technical discussions.

Insert picture description here

More good articles to share:

What kind of person is suitable for software testing?

For the rest of my life, do not look back, do not waste, do not

Slow talk about the status quo of the software testing industry

Is it true that software testing can't be done after 35?

Is it so simple to convert functional testing to automated testing?

Knowledge to understand python automated testing(3)

Those who can stand the beating of fate are the real winners in life

About software testing! Everything you want to know is here, Xiaobai must see!

Python automated testing examples-applications in insurance testing scenarios

Skills and Methods of Making Software Test Resume

Software testing is the easiest subject in IT-related industries to get started~ It doesn’t require the logical thinking of developers, and the operation and maintenance personnel are on standby 24 hours a day. What is needed is a careful and serious attitude and a broad understanding of IT-related knowledge. The growth path of each tester from entering the industry to becoming a professional expert can be divided into three stages: software testing, automated testing, and test development engineers.

Here I recommend an architecture learning exchange group to everyone. Communication learning group number: 313782132 Some video recordings recorded by senior architects will be shared: Spring, MyBatis, Netty source code analysis, principles of high concurrency, high performance, distributed, microservice architecture, JVM performance optimization, distributed architecture, etc. These become the necessary knowledge systems for architects.

Guess you like

Origin blog.csdn.net/weixin_50271247/article/details/108599282