The new company has weekly sharing sessions. This week it is my turn. I have worked for many years, and I am still in the middle stage of socialism. I need to improve my progress. If I want to continue on the road of testing, I need a lot of in-depth understanding. Come on, I want to mark the content I shared here. It can be used as a reference for newcomers or people like me. From the source of the bug, the level of the bug, and the common risks of testing, etc.
1. The source of bugs
Grace Murray Hopper, the founder of "Bug", reports Grace Murray Hopper, a computer expert working for the U.S. Navy and one of the first people to incorporate human language into computer programs. And the name "bug", which represents a computer program error,
was taken by Heber. One day in 1945, after Heber programmed the Harvard Mark II with 17,000 relays, her work was ruined by a moth that flew into the computer and caused a short circuit. In the report, Heber used adhesive strips to stick moths, and used "bug"
to mean "an error in a computer program", and the term "Bug" has been used to this day.
The original meaning of the word Bug is that "bug" or "bug"
corresponds to Bug, and people call the process of discovering and correcting Bug "Debug", which means "catching bugs" or "killing bugs". Unfortunately, in Chinese, there is still no exact vocabulary corresponding to "Bug", so we can only directly quote the word "Bug".
Although some people use the word "bug" instead of "Bug", it is easy to cause ambiguity, so it cannot be promoted.
Two: Defect level (category)
The level of software defects can be described by severity and priority;
Severity: Measures the degree of satisfaction of the impact of defects on customer satisfaction, divided into
1, fatal errors, which may cause abnormalities and crashes of this module and other related modules; (eg: accident level)
2. Serious error, the problem is limited to this module, causing the module to malfunction or exit abnormally;
3. General error, part of the module function fails;
4. Suggested modules, testers propose improvements to problematic modules Suggestion (UI level/user experience, etc.)
priority: the urgency of the defect to be fixed;
1. Immediate solution (P1 level): the defect makes the system function almost unusable or the test cannot continue (smoke test fails). Repair immediately;
2. High priority (P2 level): the defect is serious and affects testing, and needs to be prioritized;
3. Normal queuing (P3 level): the defect needs to be queued for repair normally;
4. Low priority (P4 level): defect It can be corrected when there is time;
Remarks: During the sharing process, some developers mentioned that they have doubts about P1: the test cannot continue. I hereby explain that if the test fails, it means that the smoke test fails, then the subsequent tests cannot be carried out, so The level is P1.
3. Responsibilities of Software Test Engineer
It is to actively discover and expose the risks and defects of the product, and cooperate with team members to solve the risks and make disaster recovery solutions.
Remarks: Do a good job in the disaster recovery solution, but it can’t meet the standard for the time being. Officially, generally larger companies will have a pre-release and disaster recovery system. If there is a problem after going online, they will do a rollback operation
4. Common risks of software testing
1. Requirement risk (product requirements are not clear, understanding of product requirements is not accurate or not in place, resulting in errors in the test scope, some requirements may be missed during the test, etc.) 2. Risk of test cases (test cases
or Incomplete design of test points, ignoring boundary conditions, abnormal input, etc., incomplete coverage of requirements, some cases will be missed intentionally or unintentionally, etc.) 3. Defect risk (some
defects are occasional, difficult to reproduce, and easy to be missed ;Defect tracking is not proactive enough, defect records and timely updates are not done well , the same defect may have different causes, and online production problems caused by ignorance of this point, etc.)
4. Code quality risk (poor code readability , poor refactorability, lack of annotations and other reasons lead to many defects and increased difficulty in modification; in addition, there are insufficient system architecture design, resulting in insufficient scalability, poor performance compatibility, etc.) 5. Test environment risk (test
environment Different from the production environment configuration, the test environment has a large cross-effect, and the test result error caused by the insufficient amount of test environment data)
6. Test technology risk (relatively poor technical level leads to slow test progress, insufficient accuracy of test results, and project release Date extension and other issues)
7. Regression testing risk (due to insufficient regression testing time before, we adjusted the testing time and regression time node to avoid missed testing due to time problems and incomplete regression testing) 8. Communication and coordination risks
( Regarding demand: there was less communication with the product before; about defect communication: no need to communicate alone, communicate in a problem group to improve efficiency; communication of demand changes is not timely; feedback of test results is not timely, etc.) 9. Risks in the R&D
process (Including a series of processes from product requirements review, R&D design, code submission, test release, etc. The irregular and uncoordinated process may cause many problems; for example, the development submits the code without informing other members, and the release does not have pre-production Environment, production
problems cannot be rolled back in time, etc. There are a lot of rotten situations. The process does not need to be executed in a rigid manner, but it is absolutely impossible without the process)
10. Other unpredictable risks
(some emergencies, force majeure, etc. also constitute risk factors, and are difficult to predict and avoid. For this situation, it is often impossible to solve it for a while. It is recommended to make a backup plan and disaster recovery mechanism, or use grayscale Release and other measures.)
PS: The above are the risks and reasons that may occur during the testing process, some of which are unavoidable, such as defect risks; some risks can be avoided theoretically, such as demand risks, communication risks, etc.; Some risks are difficult to completely avoid due to time and cost considerations in the actual operation process, such as regression testing risks.
The existence of these risks should be avoided as much as possible, and backup plans and disaster recovery mechanisms should be well established, procedures should be standardized, responsibilities should be clarified, and risks should be reduced to an acceptable range as much as possible.
5. During the testing process, consider the time for developing and repairing defects, and the time for testing and verifying problems.
(The new company has not been used to the previous release time, which resulted in bugs that should not have appeared online during the last release. It was brought up in the sharing meeting, and everyone knows it. I hereby remind my peers to raise questions boldly. Come out, in order to avoid problems after going online, who will be responsible for this problem)
6. About the release time
If some companies are doing overseas projects, the release time must be well controlled to avoid operations such as unavailable users
If you are learning automation testing, I recommend you to study this video
[A full 200 episodes] A collection of super-detailed advanced tutorials for automatic testing of Python interfaces, which truly simulates the actual combat of enterprise projects