Create Poster

[samm82]

Here are my initial ideas on how I'll structure my poster; any thoughts or ideas? @smiths @JacquesCarette Let me know if anything here isn't quite clear and I can elaborate on what I'm getting at. 😅

Motivation

• A "complete" collection of software testing approaches is useful when developing formal tools for software testing
  • For example, we wanted to analyze testing approaches to see which we could generate in our framework Drasil
  • Go through my attempts of looking for "complete" glossaries (see Section 2.7.2 Methodology of my notes)

Transition

• If there isn't a complete collection, one should be created
  • Go through my methodology for this research (see Section 2.7.2 Methodology of my notes)
  • It should be trivial to create one from relevant standardized documents, no? (emphasis on "no")

How Standardized are the Standards?

Good

• There's agreement between the definitions of data flow testing, although it's not present in some sources (e.g., SWEBOK V4)
• IEEE provides a nice breakdown of how these testing approaches can be categorized (2022, p. 22) (although this quickly leads to confusion/ambiguity)

Medium

• There's general agreement on what alpha testing is, but who performs it is ambiguous (in the Discrepancies and Ambiguities section of my notes)
• Experience-based as both technique and practice (in the Discrepancies and Ambiguities section of my notes)
• Renaming of qualities in ISO/IEC2023a (see #49) not propagated in sources SWEBOK V4 (double check this!)
• Bonus (i.e., if there's resonable space): unhelpful definitions from IEEE2017 ("evaluation", "product analysis", "quality audit", "software product evaluation")

Bad

• "empty" definitions from IEEE2017 ("event sequence analysis" and "operable")
• undefined terms in IEEE2022 (in the discrepancies section of my notes)
• general note that SWEBOK's template for review provided 40 lines, and I needed to add 23 more!

Unclear

These have the potential to require more space to "fully" explain, so unless one of them stands out, I'm planning on only including these if there is reasonable space to include one, potentially as something like a "case study"

• operational (acceptance) testing (#36)
  • include its omission from SWEBOK V4 from SWEBOK v3.0
• scalability vs. elasticity testing (#35)
  • include its incorrect definitions in SWEBOK V4
• recovery/recoverability testing (#40)
• performance testing (in the Discrepancies and Ambiguities section of my notes)

Conclusions

• A "complete", systematic glossary, taxonomy, or ontology for software testing approaches would be useful, but doesn't yet exist
• Its creation is more involved than one might think, based on discrepancies/ambiguities in software testing literature
• Hopefully, the creation of a systematic glossary like this will not only help others who would benefit from it, but also help future literature be more standardized and consistent
  • Ideally, this glossary will be able to grow alongside the literature as new testing approaches are developed or preexisting ones are better understood

[smiths]

Good start @samm82. I have some quick feedback:

• the motivation is very Sam specific. I don't think it has to be. Anyone that is trying to build formal tools around testing will run into problems with the existing literature.
• the outline feels incomplete. I think you need to say what can be done about the problem. This is where you could outline your methodology.
• you will want a conclusions section too

[samm82]

@smiths

1. Would providing a general motivation, justifying why it would be useful for others, and then giving my specific use case as an example be helpful, or should I just keep the motivation general?
2. Agreed. I guess I assumed this was implicit in my "transition" section, but that should definitely be elaborated on 😅
3. At this point, the "conclusions" I can think of are just that a systematic glossary (eventually taxonomy/ontology) would be beneficial in the field of software (especially since the existing literature is so inconsistent/scattered) which this is something I hope to contribute (in such a way that others could potentially contribute?). Should I spend more time thinking about this?

[smiths]

@samm82 I'll respond in order:

1. Yes, a general motivation followed by your specific example would be great.
2. Sounds good.
3. By conclusions, I just mean a summary of the conclusions that are implicit or explicit in the sections that come before. I mean conclusions in the writing sense where the conclusions "say what you said." I suggest this section because it is fairly standard. People will often start reading a poster by reading the conclusions. :smile:

[samm82]

I've started work on this in the poster branch. Chris says that the McMaster Underground will be able to have it printed for Monday by noon if I submit it by noon tomorrow, which I am planning to do (ideally, my first draft will be done by 8ish tonight 😅); if you don't have time to review it, don't worry! I definitely should have gotten on this earlier. 😔

Chris also asked if a 36" x 36" poster would be OK and (I'm pretty sure) got confirmation that it was. I currently have it set to 36" x 24", but it's nice to know in case we decide we need more space to work with! 😁

Minor questions, mostly directed at @smiths:

1. Am I the sole author of this poster?
2. How should I decide which references to include? Should I be citing resources I mention that I've gone through but don't directly reference (i.e., the lists in my Methodology section), or just list their names and cite them if I actually reference them? It seems like my reference list is taking up a little too much space 😅
3. I currently have my references super small to help them fit; would this be OK in my final poster, or should I avoid this if I can?
4. Should I still be using the natbib style, or would the default IEEE be better (since everything is on one page anyways)?

[smiths]

@samm82 I'll answer your questions in the order they were posed.

1. You should make @JacquesCarette and me co-authors. That is the easiest way to show who your supervisors are.
2. Only include references you actually cite. You don't have to be too aggressive with citation, since this isn't a paper.
3. A smaller font for the references is fine, but it shouldn't be ridiculously small. :smile:
4. You don't need to do natbib on this. You could save some space by using the IEEE style of numbers in square brackets.

[samm82]

I think I'm now at a point where my poster is now ready for review! @smiths @JacquesCarette There is some info that I'm genuinely not sure how to present not in paragraph form (I could probably rework the Goal section, but I think it's short enough and distinct enough that it might be OK?) I could also possibly move SWEBOK's definition of scalability testing to a "coloured box" (as we discussed in #49), but I also don't want it to take up more space than it needs to; would a different example be more visually appealing?

I'm kind banking on my "NO." being enough of an attractor that people would be interested enough to at least skim the rest of the poster. If my work was less textually focused, I would LOVE to try the "better poster" format.

[JacquesCarette]

So is it too late to comment? (I've just finished the other tasks that had deadlines... sigh)