Those die hard Bug, eventually going on now? [Software development] Testing - Test Hogwarts School

This article TesterHome large coffee community test, test Hogwarts School of invited guests @sktraveler reflect a classic quality management of old paper for reference study.

Famous enterprises in the first-line channels + push the process
of software testing Download channel

Ultimate Bug's four to

Years of testing experience, it is often found in such a phenomenon: there is always mention of the bug can not be fixed smoothly. These tend to have 4 to bug:

1. finally be resolved in the version found in the middle but it takes more twists and turns.

2. planned to be fixed in a future release.

3. Decides never repaired, they become potential **, forced fixed in a future release.

4. Decides never repaired, so far it has not been repaired.

We did a big project done statistics, the main statistical moderate and above severity of the defect, four to bug: The first accounted for about 50% of the second, three, 20% each, and the last species account for about 10 percent.

Bug fixes have not been the negative impact

1. Most of the time had finally changed and is forced to change, the project team tired, leadership and customers there are not better off.

2. The bug accumulated to a certain number, the faster the system can not be found, and have large-scale reconstruction, the reconstruction process will not be too painful, the last chances to reinvent the wheel ('ve seen such n such a case).

3. The longer we wait the more difficult to change them.

A recent case is: a project to finish the work, using a lower version of the underlying components, then identify the characteristics of the underlying components of low version of the missing, testers proposed function bug, the project team decided to put up with. It dragged on for two years.

The results of the project was a success, and more important, more and more with other systems, but the underlying components missing short board features more and more pain.

Finally, the work had to be repaired (high version of the component replacement), but found that due to the tight coupling of code, not the month for two months can get things. Large-scale reconstruction is now pushed to again become a problem.

4. day and night every day as opposed to too many problems with the system, the morale of the team is to kill chronic **. When your subconscious think they are doing something that is a mass of shit, but also to talk about the passion? Think "broken window effect", we can immediately understand.

How to reduce the large number of long-term legacy Bug phenomenon?
The following are some suggestions:

1. To enhance the quality of the built

This sentence tall, content is also very rich, you can find a myriad of lifting points to avoid the bug too many legacy systems from all aspects of the software architecture, development process, a variety of technical applications, expand really want to say a book. Extracted from inside the most important one spirit: the sooner the bug was discovered, the smaller the resistance encountered modification.

2. Regular bug sweeping

In fact, this is what the test should be offered to, and should let this child become routine activities of the project team. In fact, if done, still a lot of fun, and also very good.

3. The well-organized mechanism

If it is a large system, or a program, a lot of bug is a cross-project team, this time the mechanism of organizational level we need to build up, when necessary, needs linked with the assessment system. This has a number of important bug in order to be offered the final settlement.

4. Construction of the fence warning ultimate Bug

Some bug really have an eye, close one eye, about 10% of the ills so. Die hard, and limited influence. The most effective way for this type of bug is: Lei dig hard, I inserted a flag on top of it, allowing users away from him a little, OK? Sometimes the bug to deal with these very artistic, operation and maintenance, customer service, pre and post sales, had little long in mind.

"Reference": https://www.cnblogs.com/sktraveler/p/3698151.html, slightly deletion .