Talking about the practice of software defect management

stay 《 Talk about the value of software defect management 》 In the article , The article shares the process value and result value of software defect management , And introduced What practices can play these values . that , What can these practices look like in practical work ？

One 、 Practice of defect management

Pictured 1-1 Shown , The picture shows nails App The defect process data pushed by the message robot . The information displayed in this information includes ： current time 、 Version delivery countdown time 、 edition Bug total 、 To be repaired Bug Count 、 Repaired for verification Bug Number and view the details of the link entry . Why should designers push these contents ？ As the title of the push content says ： Defect tracking , The direct purpose of this message push is to track the project Bug Processing progress of , And timely synchronize with all project members in the project work group . that , What are the reasons for the design of this defect tracking message ？

chart 1-1 Love angle measurement _ Defect tracking _ Good morning!

First , The message contains current time , This is to allow the message content to have a point in time identifier , For later review .

secondly , The message contains Countdown to version delivery , Why do we need this information ？ Let's imagine , Without this information , Many people are not sensitive to project delivery time , The expected assumption is , Through this countdown information , Team members can be increased to Bug The urgency of handling . Of course, there is another design , That is, the countdown information is also a filter item for whether to trigger the push of defect tracking information , We don't need to drive defect tracking data every day at the beginning of the project , We will set a threshold , This value can be set to 7, That is, when the delivery of the version is only a week away , The defect tracking task starts .

Again , The message shows the Bug total , You can have a general understanding of the project quality . then , The message shows To be repaired Bug Count and Repaired for verification Bug Count , Which needs to be repaired Bug Information is to tell developers ： You still have so much bug It's not repaired yet , It's only a few days before the version is delivered , We have to hurry ！ Repaired for verification Bug The message is to tell the tester ： Development has changed these Bug 了 , It needs to be verified as soon as possible ！

Finally, in the message group @all, Let everyone pay attention to and evaluate risks in time .

Last, last , Namely Check the details This little design of , In order to facilitate team members to quickly view Bug Details of , Check the details A jump link is designed here , Click on Check the details , You can jump to the details page of the defect platform , If the platform link allows , You can jump directly to the defect details list of the current project .

After sharing the first design of defect tracking , Let's look at the picture below 1-2, Messages and diagrams designed here 1-1 What are the differences ？ Let's first compare the push time of the message , you 're right , One is when I first started working , One is about to leave work . Progress messages pushed before work , Provide us with the information before starting work today Bug Processing progress , And the progress message pushed at the end of work , Can provide us with today's Bug Processing progress .

In the figure 1-2 in , Apart from showing Bug total 、 To be repaired Bug The sum has been repaired to be verified Bug Beyond number , Data showing the changes of these indicators today are also designed .Bug Increase in total and to be verified Bug Decrease in number , The working progress of the test is fed back from the side , To be repaired Bug The reduction of , It reflects the progress of development .

chart 1-2 Love angle measurement _ Defect tracking _ On the evening of

The design of morning and evening message content in defect tracking is shared above , Next, I'll share the design ideas analyzed from the developer dimension . Let's take a look at the content of this designed message push ： current time 、 Version delivery countdown time 、 To be repaired Bug total 、 Developers to be repaired Bug Number and view the details of the link entry .

Comparison chart 1-1 Sum graph 1-3, There are fewer To be verified Bug Count , Added Developers to be repaired Bug Count , What is the reason for this design ？ adopt Current iteration to be fixed Bug Count , We already know the current To be dealt with Bug total yes 12, Suppose developers have 6 people , Project members may think so ： There are two days left ,6 Development changes 12 individual Bug, There should be no risk . however , When we observe the defect handling progress from the perspective of developers , We will find that ,Bug It turned out to be focused on individual development ！ There is also a development that needs to be repaired Bug The situation of , The degree of risk can be imagined , It's a high risk ！ therefore , This is the time , In addition to reminding the corresponding development to speed up the modification Bug Outside , It should also remind the development leader to keep abreast of the situation , If necessary, coordinate other development resources in time to assist .

chart 1-3 Love angle measurement _ Defect tracking _ Development dimension

The practical content of the value of defect management process is shared above , The following is a brief introduction to the practical content of the result value of defect management . Pictured 1-4 Shown , This message pushes the statistical data of the defects of the whole version , The message contains ： Version cycle 、 edition Bug total 、 Different serious registration Bug Count , Compared with the previous version Bug Changes in total and 、 Fatal and severe types Bug The proportion of 、 Compared with the previous version, fatal and serious types Bug Changes in proportion 、 A link entry to briefly evaluate the overall quality data of the project and view the details .

chart 1-4 Love angle measurement _ Defect tracking _ replay

The contents of the exhibition can be summarized as two points ： First, the defects of this version , The second is the comparison of defects between this version and the previous version . Through the number of defects in this version and the proportion of defects in each dimension , We can analyze the final quality of this version of the project . Through the defect comparison between this version and the previous version , We can analyze the changes in the project quality of this version , And find out the key parts that lead to the change of the whole project quality , Repeat and continue to improve .

Two 、 summary

In defect management , The presentation of defect process data and result data is not limited to these dimensions and forms shared in this article , It can also be seen from the urgency of defects 、 Summarize the content from the dimensions of daily change trend of defects and defect discovery stage , And put the content in a line chart 、 Push to the team group in the form of histogram and pie chart . As for which form to push the defect data of which dimensions , This can be flexibly adjusted in combination with the current status of defect management .

Original address ：《 Talk about the practice of software defect management 》

Author's brief introduction ：Chaofan, One of the members of astrometry , Focus on the experience sharing of software quality assurance .

Relevant citations ：

《 Talk about the value of software defect management 》

《 Talk about software defect management 》

《 Talk about software system testing —— Problem solving 》

《 Talk about project quality assurance —— Collaborative process optimization 》

More , Pay attention to WeChat public number Love angle measurement , Every Monday morning 9 spot 05 branch , Continuous updating .