First throw out my 2 points of view:
1. Missing tests are not necessarily the fault of testing. But when a problem occurs, the test should not refuse to shirk responsibility at the first time, but should first solve the missing test problem.
2. It is very important to deal with the missed test in time, but it is more important to avoid another missed test.
In order to explain this issue more clearly, I will discuss it through the following aspects:
1. Analysis of the reasons for "missing test"
2. How to solve the problem of "missing test" in the first time
3. How to avoid "missing test" caused by innocent people
4. Suggestions on how to avoid "missing test" again (key points)
5. How to ensure test efficiency on the basis of eliminating "missing test"
6. Recommended learning videos related to eliminating "missing test"
1. Reason analysis of "missing test"
In recent years, there have been several " missing" incidents in the Internet circle:
In the 2011 Taobao One-Yuan Gate event, the estimated loss of a single merchant ranged from a few hundred to millions;
2014 Dota Legend Mother's Day event, 20,000 gold coins turned into diamonds (worth 2,000 RMB), this benefit will be pushed throughout the server;
In 2015, the Ctrip paralysis incident caused Ctrip’s pre-market share price to plummet by 11.67%;
At the beginning of 2017, the Onmyoji "Yeyuanhuo" incident, invincible physical strength, unlimited dungeons, and top-level materials, how many big R nightmares;
In the 2018 King of Glory test mail event, the Android QQ area was awarded the "Tianmei History's Strongest Benefit", and the four permanent props of Hero Shen Mengxi, Baseball Wizard, Hero Li Xin and Searing Blade can be used at will;
In the Pinduoduo coupon incident in 2019, it was rumored that the bug caused Pinduoduo to lose 20 billion overnight.
.....
So, must the missed test be the fault of the test? In fact, it is not the case. There are many reasons for the missed test. For example, there will be such situations:
① The requirements specifications are not clear, which leads to the rough writing of test cases. Product and Testing Responsibility.
② If the requirement specification is changed but the test is not notified, the test case is not updated in time, and the product is liable.
③ Incomplete coverage of test cases, omissions in scenarios, the main responsibility for testing, product and R&D (participate in use case review).
④ If the test case is not strictly followed during the test, the test is responsible.
⑤ Insufficient time. After the project team reached an agreement, only some high-priority module tests were performed, resulting in some function points being ignored during the test process. Then the project, R&D, product, and testing are all responsible.
⑥ The test environment is limited, resulting in missing defects.
⑦ New bugs introduced by developers when solving bugs, etc.
It can be seen that the above situations will cause abnormalities in the system after it goes online, and not all of them are the responsibility of the test. Products, R&D, projects, and test environments may all be held accountable.
Therefore, no matter how careful the test is, it is impossible to avoid missing tests, and it is simply impossible to prevent.
Therefore, it is obviously unacceptable to put all the "missing tests" on the test body. The key is that the testers need to find enough evidence to protect themselves.
But after a bug occurs, don't just blame it directly, which makes people feel like avoiding the problem. The first priority is to deal with bugs and minimize the impact on users; as long as the impact on users is not large, even if there is a responsibility, the consequences will not be too serious.
How to deal with bugs in the first place?
2. How to solve the "missing test" problem in the first time
Compared with the responsibility of "missing test", we should pay more attention to how to solve the problem of missing test. How to deal with it? Generally divided into the following 2 steps:
①When a problem occurs, refuse to shirk responsibility, and solve the user's use problem as soon as possible. Tests should be recorded as soon as a problem occurs, confirm the scope of the impact, and find a way to recover as soon as possible. Priority is to ensure that user usage returns to normal.
② Shorten the problem repair time, and push the repaired version to users as soon as possible. Confirm the steps to reproduce the problem, and urgently coordinate R&D personnel to fix it.
3. How to avoid the "missing test" of being innocent
The "missing test" problem has been solved, but the pot of "missing test" will be all caught on the test body. This is obviously unacceptable, and the testers need to find enough evidence to protect themselves.
Therefore, we must make a summary of the bugs that appeared after the test, organize a reflection meeting after the event, and trace the cause of the accident. Through the traceback to determine the cause of the problem, the responsibility for the problem is basically clear.
The problem backtracking is generally analyzed from several aspects such as the introduction stage of the bug, the cause of the bug, and the reason for the omission of the bug . For example:
1) If the bug is introduced in the requirement stage, and the requirement itself is missing/description is unclear, then it is mainly the responsibility of the product personnel, but the design, development, and test personnel are also responsible if they fail to review the problem
2) If the bug is introduced in the development stage, and the tester did not consider it when designing the use case, then it is mainly the responsibility of the tester, but the test case is also used after development and product review
3) Bugs are also introduced during the development phase. If the bug is due to the introduction of a new bug during the development and modification of the bug, it happens that the use case has been tested before and will not be retested. The main responsibility for such omissions lies in the development and modification of the bug. Controlling the scope of influence is a must for development, but testers can fail to do code care
4) Or after the product personnel change the requirements, they just tell the development to change, but they don’t give the test synchronously, resulting in missed tests. This means that there is a problem with the project development process, and the project manager should take the main responsibility.
It can also be seen from the above examples that there are many possible reasons for the occurrence of bugs. Generally speaking, the project team will not deliberately emphasize who should take the main responsibility. For the unity of the team, in most cases, the product, development, and testing share the responsibility.
Tips: The content of this chapter is reproduced from: After software testing, there are still bugs. Is it the problem of the testers?
4. Suggestions on how to avoid another "missing test" (emphasis)
Never step on a pit twice, and never fall twice in a pit. How to avoid missing test? Here are 6 suggestions for you:
① Standardize the work process and formulate standards. It can actively promote the project team to reach an agreement on the cognition of the project workflow, clarify the project schedule, strictly follow the project plan time, and prohibit changing the requirements or adding new requirements after the requirements are lacked. Avoid the problem of untimely or out-of-sync information synchronization. If it is necessary to change, it must be approved by all members of the project meeting.
② Standardize the test plan and do a good job in Plan B. The plan should clarify the test scope, test method, and access and exit standards; at the same time, the possible risks in the project process should be considered, and Plan B should be done well.
③Unify the use case writing specification and select the regression use case. It is possible to unify the writing standards of team use cases, clarify priorities and get the approval of the project team. Use cases with P0 priority can be used for regression testing to ensure that the functions are available (generally, those that affect the normal use of functions are all P0).
④ Strictly implement use cases and refuse fuzzy acceptance. Use cases can be uploaded to the same platform for management, and records are made directly on the platform during execution to avoid omissions during execution or incomplete execution caused by "lazy" testers. Moreover, use cases that fail to execute can be associated with bugs, and finally output reports. At this time, the acceptance criteria can be specified to the extent that there are no omissions in the execution of use cases, no defects are left over, or the resolution rate reaches XX%, and it can even be specific to the resolution rate of each level according to the priority and severity. For example: Severity S0, S1 level resolution rate 100%, S2 level resolution rate 98%, etc.
⑤ Refuse verbal requirements and refuse to raise verbal bugs. All work docking needs to have records in text form, including test submissions, bug submissions, and online notifications. Don't think that everyone has a good relationship, just say something. When an accident comes, you can take another look at whether the good relationship is still useful. Keeping records in written form is not only to protect yourself but also to restrain all parties, and to be responsible for your own words and deeds.
In addition, the test can also promote the formulation of the project's online strategy. For example, it can promote the grayscale release strategy, clarify the grayscale range, select some customer groups with better tolerance to join the grayscale list, and conduct a grayscale trial before going online. If there is an abnormality within the specified time, it can be rolled back and repaired at any time; if there is no abnormality reported within the specified time, it can be pushed in full.
If it is to avoid "missing test" accidents, it is of course not allowed to blindly reduce the test efficiency.
Judging whether a test team is strong or not depends on at least two dimensions: whether it is fast (efficiency) and whether it is good (no missing tests).
A strong testing team should be fast and good.
Therefore, I also give some work suggestions to the majority of testing students, how to improve the quality and efficiency of the team while improving the quality of testing (eliminating "missing tests").
5. How to ensure test efficiency on the basis of eliminating "missing test"
(1) Make good use of platform unified management (use cases, bugs): You can use some easy-to-use platforms to promote the use of project teams. The data on the public platform is clear and transparent, which is convenient for all parties in the team to check the progress of testing and bug resolution at any time.
(2) Make good use of tools to improve the test: You can use some test tools to make up for the monitoring that cannot be done by humans. For example, you can use the packet capture tool during the test to monitor all requests and responses to prevent The problem of bug retention caused by unclear reproduction methods can also provide a preliminary positioning for R&D, help R&D shorten the troubleshooting process, and improve the efficiency of bug resolution.
(3) Standardize the writing standards of use cases, and the team will reach a consensus. Here it is necessary to clarify the title format, preconditions, operation steps, expected results, and the most important thing is to clarify the priority of use cases.
(4) Introduce automation to make testing more efficient. As we all know, automated testing can improve efficiency very well, so after our regression use cases are clarified, this part of the regression work can be realized through automation, and finding a "tool man" to work 24 hours a day without sleep, wouldn't it be possible to update within the effective time? Fully tested.
(5) Look at the code more and understand what R&D thinks. After work, I suggest that you look at the R&D code more. If you don’t understand it, you can let the R&D explain the general idea, but I believe that the simplest if else can still be understood. If you find the logical processing relationship in it, you can understand that it is necessary to develop and implement a certain function. Considering which scenarios, combined with user usage scenarios, you will know where there may be problems. You can focus on testing during testing, and the efficiency will be higher.
If you want to become a tester who understands programming better, I recommend viewing the following video tutorial:
"Take you to play python2021 version in 10 days"
6. Recommendations for learning videos related to eliminating "missing tests"
Looking back at the reasons for "missing tests", we found that everything related to testers is related to test cases. If the test case coverage can be more comprehensive, more detailed, and better executed, the probability of eliminating "missing tests" will be greatly improved.
So recommend a few study materials and test cases for everyone.
If you need video learning materials, you can click on the link below:
2. "Functional Test_6 Days Dark Horse Manual Test 2021 Edition"
3. "Introduction to testing_3-day dark horse manual testing theory + 6-day practical complete sharing_suitable for 0 basics"
4. "In-depth understanding of software testing 4-day video"
5. "Black box test case design method"
6. "White Box Test Case Design"
7. "Common Packet Capture Tool Charles Test Combat"