Statement: The content of this document is mainly from the book "Software Debugging the way of cultivation", Paul Butcher, belongs to the reading notes. Welcome Reprint!
-----------------------------------------------------------------------------------------------
Defects can occur at any time, from code completion to code post-release carries!
No matter what kind of software you develop, you need to create some processes through which you can tell your software what's wrong and how it should be repaired!
1. Defect Management System
Both simple and comprehensive process management, but the purpose is the same.
- Ensure that defects are not omitted.
- Include all relevant information by providing a standard format for defect reporting!
- As a review trail, you can make sure that we know what flaws in each version are unresolved.
- It can also be used as an important source of information for software releases to set defect priorities and determine which to resolve first.
- Provide an effective means of communication for stakeholders to ensure that relevant information is provided accurately when passing between teams
- As a management tool, provides the current status of the project
2, how to write a good report on the defect
A good defect report is more than a few, because we have no way of knowing what information is relevant and which is irrelevant.
- The report should be specific, clear and detailed.
- The report should also be minimized and unique. such as the report 10,000 words, whether it can be reduced? Which version is defective and is there any other version?
3. Streamline processes-improve defect report quality by reducing adverse conditions
If no one takes the time and effort to reflect the problem to you, you will not be able to identify these flaws or fix it!
- Clearly explain how to report defects. Improve multiple options: email, direct chat, online communication, and more!
- Be as simple as possible: Ask the user to perform as little as possible, or it may not complete
- The template is not too rigid: Make sure that each locale has reasonable options, such as "none of the above". Respect for privacy: users ' data belongs to them, not to you, to comply with the relevant privacy policy.
4. Effective communication
Cleverness is a necessary condition for a software engineer, and most of them have good grades in school, but that does not guarantee that we will not make mistakes. In the field of application customers rely on their expertise and may understand better than you do, so when there is a clear misunderstanding, remember that you may have made a mistake!
- Imagine what will happen from the user's perspective, and your goal is to separate their observations from their interpretations.
- The only way to communicate with non-technical people is to be patient and explain why these details are important and to persuade them to gather relevant data through the necessary steps.
- Publishing your defect database, although it may be scary to see your "explode", is a huge benefit.
- To improve feedback and receive bug reports, you need to respond positively and support them to continue.
- Visit users and visit them to learn more than any bug report.
5. Collaborate with support personnel
Technical support, QA, customer engineers, technical account managers, etc. can be improved during the commissioning process!
- Consider working with a QA team colleague in the diagnostics phase
- To ensure that the customer team can help us solve the communication problem, you should be able to determine and ensure that all relevant information has been identified, avoid nit-picking and some related details, and consider requiring them to perform a specific process to improve the quality of the defect report.
- Occasionally do customer support, to show respect for the customer, to avoid being blocked by the user
- Because of the different perspectives of QA, they need to guard against the development team's preconceived "complicity", but also easy to overdo! For example, there is a deep gap between a company's development and QA team that the author works on, and the information that QA can get is a compiled binary, and the only information that the development team can get is "pass" or "fail."
< reading notes > Software debugging: Debugging from the big picture-discovering problems with the code
