Do you feel relieved when all bugs in the Bug Tracking System are Closed. After the project is successfully delivered, do you feel that your brain has entered the "hibernation" period, surfing the Internet, chatting, and writing small programs you are interested in? But you are not willing to think about it for the previous project. Since there is still some time in the gap between projects, you can do it easily. The boss will give you something more guilty.
"Learn from the past", this old saying helps you to deliver a poor job to your boss, analyze the project process, and summarize the process. It is best to submit another analysis data, the boss will never think that you are not doing any work if you take the money, and you can also gain some benefits.
In the development phase, we 'd better find the Bug record. The Bug management system has recorded all the symptoms, categories, modules, and causes of bugs. Although almost all Bug management systems provide reports and classification and summarization functions. However, there may not be many projects that analyze the information carefully.
Bug Scope
After analyzing the Bug correction process, you may find that the vast majority of bugs are related to a few key code files. For example, I have a module, a total of 25 code files, and three external files, both of the 80% bugs have been modified on the two code files. That is to say, the performance of a Bug may be different, but tracing the cause is mostly within a very limited scope of code. However, these codes are not the key part, but are not very important. The reason is that the key code (such as database operations) is run multiple times during programmer development, has been verified, or has been encapsulated in a uniform manner, including in Fremework, with high reliability, the probability of a Bug is low. Non-key issues are often detailed issues, such as Focus movement, control alignment, representation formats of special data types (time, currency), fonts, colors, etc, the calculation or accuracy of some values is incorrect. In these details, a module is concentrated on several items, or the module I mentioned above, and the Bug of 70% is a problem of moving focus and expressing format.
Causes of bugs
There are several reasons for the emergence of bugs: code implementation and design are inconsistent; pure implementation errors or omissions; design and implementation of a certain point are omitted at the same time, no one puts forward, it was not found until the test was conducted; it was not a Bug because it did not comply with the project specifications, but the tester and implementer had different understandings.
The inconsistency between the design, code, and test is often caused by the absence of a uniform standard between the three for implementation and test of modules, so I think there must be a document (no matter what you call it) as a reference. If there is any misunderstanding or inconsistency, you can find the answer here, if not, add the missing parts.
In addition to the inconsistent standards mentioned above, the problems encountered in the implementation phase are mainly caused by the programmer's own simple errors or carelessness, omission of a specific detail, or even though the implementation, but it is not completely correct. For the latter, it can be because of the special functions of a module and code writing problems. It can also be because of the functions used in multiple modules, but they are not encapsulated in a unified manner, the result is the difference in implementation methods and the increase in the chance of bugs. In the second case, you should first consider encapsulating this function, calling it in a unified manner, and writing down the document.
For testing, the test points can be divided into common parts (Focus, Font, control size, date, and currency display format) while maintaining consistency with the design and implementation ), the non-General part (except the general part, the function that the module itself needs to implement), the normal situation, the exception situation four categories, conduct the test.
The above analysis is based on the results of unit tests, and only for one module, there are great limitations, but I believe it is very helpful for the development of subsequent projects, development and testing will become more targeted. On the one hand, bugs can be reduced, and on the other hand, testing efficiency can be improved.
You can cope with the boss, but you cannot cope with yourself. "Seriously" only makes you more efficient and easier.
I hope you can share more experiences.
