Background: A company that mainly makes an APP. The company's technical department has three groups: crawler group, server group and APP client group.
Fact playback:
-
1) After each operation or product proposes a BUG to the test engineer.
-
2) The test engineer will judge which group the BUG belongs to based on feeling and experience (rather than skill judgment), and will assign the BUG to the responsible colleague A of the group after judgment.
Note: Our performance is deducted according to the production BUG generated by each colleague of each team.
-
3) The development colleague A who received this BUG began to troubleshoot the problem. After half an hour of troubleshooting, I found that the BUG was not my problem, so I threw it to the test engineer, and blamed the test for not assigning a BUG that was not his. Give it to him, to waste his time, and to affect his performance.
-
4) Testing According to various investigation descriptions of development colleague A, it is learned that this BUG may (yes, may) be a problem of development colleague B of another group, so the test assigns this BUG to development colleague B.
-
5) The development colleague B who received this BUG began to troubleshoot the problem (the development and troubleshooting methods of each group may not be the same), and if it went smoothly, the final inspection found that the BUG was indeed mine.
-
6) Development colleague B starts to deal with the BUG, and after the processing is completed, the test is accepted until the BUG is closed.
The flow chart is as shown in Figure 1:
In this process, there are many hidden problems:
-
1. Acceptance When receiving a BUG assigned by a test engineer and unable to determine whether it is a BUG that I need to deal with, I will keep the BUG hanging up and not deal with it. The reason is very simple. I spent half an hour to troubleshoot this BUG. Maybe this BUG is not mine.
-
2. Develop regular test engineers, how do you prove that this BUG is mine? I just don't deal with it! And why do you always assign me bugs that are not mine? The test engineer’s response is always weak, "How do I know if this BUG is yours?".
-
3. In the process of arguing with each other, the cooperation efficiency of "test-R&D" was seriously reduced.
Solution:
Confucius said, "If your body is upright, you do not order; if your body is not upright, you can't follow the order." For the test engineer, he needs to be hard. It is imperative to improve the ability of test engineers to troubleshoot bugs.
When the test engineer gets a BUG, he can use APP to capture the package and look up the database table to troubleshoot which development engineer is responsible for the problem.
Example: There is a picture on the APP that cannot be displayed normally, and this picture was collected by a crawler engineer.
deal with:
-
1) The test engineer first finds out the HTTP request content related to the image by capturing the packet. If the image URL in the request content is empty, then the bug is likely to be a problem with the crawler when collecting data or storing data. Find out the commonalities and rules to the crawler engineer to deal with.
-
2) If the picture URL has a value, and the URL can be opened normally, but the format of the URL is not in OSS format (the server will save the external picture in our OSS environment), then the problem is the server When there is a problem when saving the picture, find out the commonality and rules and send it to the server engineer to deal with it.
-3) If the format of the picture URL is OSS and it can be opened normally, but it cannot be displayed on the APP, then the problem is that the client has a problem when displaying the picture. Find out the commonalities and rules to the client engineer. deal with.
If the test engineer can do this, the process of BUG submission and processing becomes as shown in Figure 2:
Of course, in this process, the test engineer must first improve the accuracy of his own BUG investigation, and second, he must improve his own BUG investigation process. Availability of reference for development.
Expansion:
"As a software test engineer, what abilities do you need?" There are a lot of abilities, but I think the ability to troubleshoot bugs is the most important, most effective, and most easily overlooked point.
The main responsibilities of a test engineer include quality inspection and quality control. Everyone talks a lot about quality inspection, but there are relatively few quality control items. I will also mention it here.
Quality control one: upstream work quality control
When the product is just established and the requirements are confirmed, the testers will participate, carefully review the requirements to see if the requirements are complete and whether there are loopholes. At this time, the formal development has not been entered, and the cost of modifying the requirements is for the project team. Minimal. In this link, testers can often find many required loopholes by virtue of meticulous deduction and divergent thinking, which improves the overall efficiency of the project.
In addition, after the testers have completed the test plan and test cases, they will invite developers and products to review the test cases together. In this link, since the testers have reflected each requirement in the test cases, it is equivalent to repeating After a thorough analysis of requirements, many vulnerabilities in requirements can often be found. This is also an effective link for early detection of demand loopholes.
Quality Control 2: Quality Control of Downstream Work
After the product has been tested, it is the release link, and testers can also play a role in the release link. First of all, in order to deploy the test environment and study the technology of automated deployment, testers can also automate the on-line deployment link. The deployment link that used to take 2 hours was compressed to half an hour or less, and it was more accurate and reliable.
If there are many revisions of some versions, the quality risk of launching is high, the testers will work with the product to develop a gray-scale release plan and implement it technically, so that the version will be open to a small number of users. If a bug is found, the users affected It is also relatively small. After the bug is corrected, the user range will be gradually expanded.
In addition, excellent testers will also mobilize other people in the project team to ensure the quality of the project, such as promoting development for code review; introducing a smoke self-test process, allowing developers to self-test before submitting to the test for smoke testing; pass Analyze bugs in the project team, allow development to improve self-testing, reduce the number of bugs, etc.; introduce planning, interaction, and visual inspections during the testing phase and other measures.
END
Official account: Programmer Erhei, get software testing resources (interview questions, PDF documents, video tutorials)
Good things should be shared with friends