Thesis Meeting | Jan 13, 2024 - 2:30pm - Teams

[samm82]

Regrets: @JacquesCarette

Update

I've been working on #128, but pivoted to the bunny trail of #34 for a change of scenery, and will finish up the Methodology section with fresher eyes. #129 is ready for review (the first part of Methodology) since it is pretty self-contained and a significant change, but it can also wait for the rest of the chapter to be done if that makes more sense!

Counting Discrepancies

For counting discrepancies, I assume that the "more trustworthy" source is the one that is correct (see this comment). When this isn't the case, or when the ground truth is a supplementary source that isn't used for terminology research, I've added it as a comment in my discrepancy files and excluded it from consideration for discrepancy counting. I recently "formalized" this to comment in a consistent format, but I don't know how much I should explain this in my thesis (if at all). I can explain this with examples during our meeting if that would help! 😅

"Core" Examples

In #34, I found some candidates for "core examples" that we could include in the intro/seminar (@JacquesCarette might have thoughts on this since he reviewed my intro more recently; #126):

• The term "fault" is "overloaded with too many meanings, as engineers and others use the word to refer to all different types of anomalies" (Washizaki, 2024, p. 12-3)
• The term "defect" may be used as a "generic term that can refer to either a fault (cause) or a failure (effect)" (IEEE, 2017, p. 124; 2010, p. 96; OG 2005) "when the distinction is not important" (Bourque and Fairley, 2014, p. 4-3; OG IEEE, 1996)
• Captured in my thesis as a discrepancy: The differences between the terms “error”, “failure” and “fault” are significant and meaningful (ISO/IEC and IEEE, 2010, pp. 128, 139–140; Washizaki, 2024, p. 12-3; van Vliet, 2000, pp. 399–400), but Patton (2006, p. 14) does away with them, saying “there’s no reason to dice words” and to “just call it what it is and get on with it”. These terms, along with “defect”, “problem”, “incident”, “anomaly”, “variance”, “inconsistency”, “feature” (!), and “a list of unmentionable terms” are abandoned in favour of the chosen term “bug” (pp. 13–14).

I think this also has the potential to be split into a new "subset" of testing (like what I've done for recovery, scalability, performance, etc. testing) but don't know if it's worth it; will report on this in #34!

[samm82]

I've added the aforementioned clarification on counting discrepancies to #93 and the formalization of "error", "fault", etc. discrepancies as an example for the intro as #132.

More generally, @smiths (again! 😅) pointed out my tendency to leave the reader to figure things out on their own, instead of being explicit in my presentations of evidence (including in the issue agenda above!) More specifically, he suggested I directly present my conclusions, which should usually be done before presenting supporting arguments, so the reader doesn't have to guess why I'm including information, what I mean by it, and whether I am condoning, condemning, or simply commenting on it. I added this specifically to #132 and #128, and will try to keep it in mind as I continue to work on other tasks!

All items will be tracked elsewhere, so this issue can be closed.