Bugs that are hard to modify

Many years of testing experience often finds that some bugs cannot be fixed smoothly. These bugs often have four steps:

1. It was finally solved in the detected version, but it took more than a week in the middle.

2. Planned solutions will be implemented in subsequent versions.

3. I decided to never fix it, but it turned into a potential bomb and was forced to fix it in subsequent versions.

4. I decided to never fix it. So far it has not been fixed.

I have made a big statistics on our projects recently. The statistics on the defects with medium severity and above are about 50% of the four trends, and 20% of the two and three types respectively, the last one accounts for about 10%.

 

The negative effects of unmodified bugs include:

1. Most of the time I finally had to make a change. I was forced to make the change, and the project team was exhausted. I could not do well in the leadership and customers.

2. these bugs have accumulated to a certain number, and we find that the system is almost out of service. We need to reconstruct the system on a large scale. The reconstruction process should not be too painful, in the end, we may have restarted (we have seen N such cases ).

3. the longer it takes, the more difficult it is to change. A recent case is that a project uses a lower-level component to catch up with the progress, at that time, it was identified that the underlying component features of the lower version were missing. The tester proposed a functional bug and the project team decided to endure it. One delay is two years. The results project is successful and becomes more and more important. More and more systems are interacting with it, but the lack of features of this underlying component becomes more and more painful. At last, I had to fix the problem (replacing components of a later version). However, I found that the code coupling was too tight, and it was not enough for a month or two. Large-scale reconstruction is still a challenge.

4. Daily comparison with systems with too many faults is a chronic poison that kills the anger of all stakeholders. When your subconscious thinks that what you are doing is a mess of shit, Is there Mao passion? Think about the window breaking effect and immediately respond.

 

How can we reduce the long-term legacy of a large number of bugs? I have the following suggestions:

1. Improve built-in quality. This sentence is very advanced and has rich connotations. From the aspects of software architecture, development process, and various technical applications, we can find countless improvement points to avoid too many legacy bugs in the system, start with a book. Extract the Most Important Spirit from the inside: The earlier the bug is detected, the less resistance the modification encounters.

2. Regular bug cleaning. This is actually a test task that should be put forward and should be made a routine activity of the project team. In fact, if you do well, there is still a lot of fun and the effect is also very good.

3. If it is a large system or project group, many bugs are cross-Project Teams. At this time, the organization-level mechanism should be established and, if necessary, be linked to the assessment system. In this way, some important bugs are solved.

4. Some bugs have to close one eye. About 10% of the stubborn problems will happen. Difficult to modify, limited scope of impact. The most effective way to this type of bug is to dig mine. I will insert a flag above it to let the user stay away from him, OK? Sometimes it is very artistic to handle these bugs. O & M, customer service, pre-sales, and after-sales personnel have to keep an eye on them.