Defect type not discussed

[llayman]

Defect type not discussed

[WilliamNichols]

I will take this

From: Lucas Layman [mailto:[email protected]]
Sent: Wednesday, September 07, 2016 5:16 PM
To: ai-se/phaseDelay [email protected]
Cc: William Nichols [email protected]; Assign [email protected]
Subject: [ai-se/phaseDelay] Defect type not discussed (#43)

• Finally, looking at Fig.6 and defect type distribution, wouldn't be relevant to explore any possible effect of defect type on the results in Fig. 13? As defect severity is absent, may be defect type has some influence. It could be that certain categories of defect can be corrected any time during the project, it could even be that these defects, in particular, are delayed for later (because they are easy to repair) … It is indeed a mystery why certain defects have been fixed immediately (as reported in Fig. 12, how many in total?) and others were delayed for later (as analyzed in Fig. 13, how many in each cluster and in total?).

Bill, can you perhaps offer some response to this?

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/43, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHOyVFw9QadPVdPHJz56DTcFJoNYVOfFks5qnymBgaJpZM4J3XXX.

[WilliamNichols]

I am recording my notes here before I adjust the text or respond to reviewers.
I need to remind myself what figure 13 meant.

Some defect types are more likely to be associated with design and others with coding errors. Coding errors are typically localized and are easily fixed once discovered. However, discovery in test can sometimes be time consuming.

It is indeed a mystery why certain defects have been fixed immediately (as reported in Fig. 12, how many in total
Defects found in reviews and inspections are typically coding errors or defects that do not propagate across many modules. Once found, the fix is usually very fast. However, when discovered in test, only the symptom, and perhaps the trigger, is initially known. The source of the error in the code must still be discovered. We record "find and fix" as a single measure, once a defect is known to exist, all effort to discover the root cause in the code and change the code is logged to "find and fix"

Defect type may have some influence, but fix cost is likely to be related to discover phase and type will have some correlation with the discovery phase. THis could be the subject of a later study if we can frame the research question more precisely.

[WilliamNichols]

a tentative reply is as follows
Reply Reply 2.4
This insightful comment gets at a reason to record defect types. That is a type of analysis projects should perform routinely for process improvement. Some types of defects are associated with specific phases (for example syntax with code, and interface is a design issue often found in Build and integration test). There is, however, no indication in projects we've been involved with to delay fixing defects. On the contrary, most simple defects are simple if found and fixed early in inspections, yet become expensive if discovered in test.

Defects fixed immediately fall into two categories,

1. those found in a review or inspection, or
2. secondary defects injected during test activities when fixing another defect.
   ,,,,,,,

comment
we could some sort of defect analysis by type and phase, but I am unsure what we would be looking for. I expect that interface and functional defects will appear later. This appears to be another instance of the reviewer not fully understanding our data. Perhaps some additional text is called for.

[WilliamNichols]

Should we add something to "future work" to supplement my response to the reviewer