Preface:
Hello, everyone, I’m Yifei. Before we start today’s sharing, I’d like to ask you a question: have you ever heard the saying in movies and TV dramas, especially suspense ones: what you see is not necessarily true, what you see may not be true and so on. The more defects you see, the more defects you see in the software? Hey ha, feeling so mysterious, let’s walk into this article.
The more defects found, the more defects in the software?
This is a relatively common phenomenon. Test engineers will rack their brains before finding defects, but after finding one, they will find many defects one after another, which is quite a personal sense of achievement. The main reasons are as follows:
– Reusing code and copying code makes programmers prone to making the same mistakes. Class inheritance results in the error that all subclasses contain the base class, and copying the same code over and over means that the defect may also be copied.
– Programmer fatigue can lead to some continuous writing of more functional defects.
It is common for programmers to work overtime, so it is easy to write more bug-prone programs. And these continuous latent defects are exactly where test engineers come in. “One defect leads to another” is not an objective law, but a common phenomenon. If the software is well written, this phenomenon is less common. Testers just have to be serious about testing the program.
Can all software defects be fixed? Do all software bugs have to be fixed? Technically, all software bugs are fixable, but it is not necessary to fix them all. What the tester needs to do is to be able to correctly judge when software perfection cannot be pursued. For the entire project team, it is important to cull each software defect and determine which defect to fix based on the risk. The main reasons for this phenomenon are as follows: – Insufficient time resources. In any given project, it is often the case that developers and testers are not available, that regression testing time is not budgeted for in the project, and that changes to defects may introduce new defects, so changes to certain defects must be abandoned under the pressure of deadlines. – Some defects occur only in special cases and can be fixed in future upgrades for commercial reasons. – Not a flaw of a flaw. We often encounter functional issues that are treated as defects that can be dealt with at a later time. Finally, it is up to the software testers, project managers, and programmers to decide whether or not a defect should be fixed. People in different roles should think from different perspectives to make the right decision.
Iii. How to write the test report submitted to users?
As testing becomes more important, it is inevitable that development teams provide testing documentation to customers. A lot of people ask, “Can we give our work test reports to our clients?” The answer is no. Because provide internal test report, may let the customer lose confidence, even negate the project. Test reports are generally divided into internal test reports and external test reports. Internal report is our project document in the test work, reflecting the implementation of the test work, here is not much discussion, readers can refer to the relevant textbooks. Here mainly discuss the external test report writing method, general external test report to meet the following requirements: – according to the internal test report to write, generally can be excerpted; – Serious defects should not be reported to customers. Even if the defects have been modified, there is no need to let customers know about the defects in development; – Some defects may be listed on the report, but they must be intermediate and they must be fixed; – The contents of the report should be as true and reliable as possible; – Review the entire test report carefully and try not to negatively impact the project, especially the performance test report. In summary, external test reports should be written carefully.
Iv. Principles of software testing:
1. Report software defects as soon as possible
The earlier a software defect is discovered, the more time is left in the schedule to fix it. Priority should be given to the functional testing of the APP. The earlier it is discovered, the sooner it can be repaired, and the subsequent tests will not be blocked.
2. Description of valid software defects
Short: only explain facts and demonstrate, describe software defects in the necessary details single: each report is for only one software defect
Obvious and generic: A special case of a software defect that is described in simple steps that are easy for users to understand has a better chance of being fixed.
Reproducibility: To be taken seriously, software defect reports must demonstrate reproducibility – that predetermined steps can be taken to bring the software to the same state in which the defect reappears.
3. Don’t make comments when reporting software defects
Testers and programmers tend to be antagonistic. Software defect reports should be about the product, not the person, and only state the facts. Avoid schadenfreude, grandstanding, personal tendencies, ego, and blame. Tact and euphemism are key. Must be good at communication and cooperation.
4. Follow up software defect reports
Worse than not finding a critical software defect is finding one, reporting it, and then forgetting about it or losing it. Being responsible for the project is a must for every test engineer.
5. Mark software defects with critical priority
Solve problems of high severity and priority first
6. Software defects include the following rules:
The software does not achieve the functions specified in the product manual;
There are errors in the software that are not specified in the product specification; Software functions beyond the scope specified in the product specification; The software does not achieve the objectives not specified in the product specification but should achieve; Software testers find difficult to understand, difficult to use, slow to run, or bad for end users.
The biggest cause of software defects is product specifications, followed by design. The goal of a software tester is to find software defects as early as possible and make sure they are fixed.
5. Write at the end:
After reading the friends, remember to give me a thumbs-up oh, your thumbs-up is my more inexhaustible power, pen core.
