Maybe I’m just an oversensitive, subtle and thoughtful kind of guy, or attuned to ambiguity, or unempathic, or unimaginative, or a git, or plain old-fashioned thick, but being precise and clear with language is a skill that I value highly and strive to achieve.

With questions, I find that I’m unlikely to assume the context if it’s not already present or given. So, for example, I probably would not have a simple answer to “should the product do X?” Are we discussing a version of the product in the field or the product in development? Is it my personal opinion you’re after? My user-head opinion? If so what kind of user? Perhaps it’s what the spec says or said once upon a time? Maybe X is a reasonable result under certain circumstances but not others? Are you implicitly telling me that the software does do X and you’re not sure whether it’s right? Or that you think it might be intended to do X, and it doesn’t? Or asking whether we need X in the product?  Maybe you’re engaged in a thought experiment and have a new set of potential applications for the product in which X is the jumping off point?

Statements are no easier. If I was to I hear “I’m not sure about feature Y” I’d want to understand whether the uncertainty  is a measure of the confidence of the speaker in the work they’ve done (perhaps they aren’t sure they tested sufficiently broadly or with sensible test data, or at the right scale) or in Y itself  (perhaps the AUT is clearly unstable in some respect) or both or something else altogether.

I’ve got particular bête noires (“seems to work“, gah!) and recently one showed up a couple of times in the space of a few days from different people,  but fortunately not anyone at work. “The application will never Z” is how it went,  in the context of a discussion on the kinds of testing that might be necessary for an application they had no experience of using, with the coda that we thus didn’t need to test for or around Z.

Never? If you mean that you think Z is unlikely given all the information that you have, say so. If you mean that the requirements don’t mention Z, then say so. If you mean that Z is not a valid input or output, then say so. If you mean that an action required to achieve Z is forbidden by the environment in which the application is (intended to be) deployed, say so (but let’s ask whether it’ll ever be deployed otherwise). If you mean that you’ve spoken to the developer and he says that the code path that represents the Z scenario rejects the input with sensible error handling, say so. If you mean that you have been testing this application and haven’t observed Z, say so (but let’s discuss the coverage). If you mean that you can’t think of a setup in which Z could be observed, say so. If you don’t understand why I might be banging on about provoking the product to produce a Z (as precisely as I can) don’t try to cut the conversation off by saying it’ll never happen and instead please just say so.