There's a reason people in tech are notorious for answering questions with questions like "what do you mean by X?" or "that depends".
Human language is kinda vague and sloppy, but context usually fills in the blanks, and we're used to be able to clarify on the spot, but that doesn't work when we try to tell machines what to do, or when when we're putting words in documents that other people in other contexts are supposed to understand. This is, in my experience, where bugs usually occur – in the assumed understanding of constructs - the conceptual "things" we use in language, like "hour", "border", "flower", "write", "red" and "sound". In other words, things go wrong when we
think that everyone must mean the same thing, when
we think something is clarified enough.
The first step in uncovering these bug-generating mistakes is becoming aware of them and getting creative about alternative meanings, and that's part of why it's so much fun being a tester.
In this talk I will present some of my "favourite" constructs to challenge, and some useful cues to help you notice that a construct you're using should be investigated closer.
Key Takeaways:- A structured way of using construct validity as an attack vector for finding bugs, even without looking under the hood, like you had x-ray vision.
- A list of very common problematic constructs, and why they keep tripping people up, again and again.
- Some phrases you may choose, to come across as less annoying, when you actually care about what others dismissively refer to as "just semantics" .
