“So I am wondering, if faced with that situation again, how would you approach it in a more flexible way, but still being able to limit testing scope? Like, would you try to figure out what extra requirements (such as usability) might be needed when discussing at the beginning? Or would you just keep an eye out for potential issues regarding things like usability, performance etc while testing, and highlight them to the customer if you see anything that looks like it could be a problem? Or maybe have a checklist of “light” tests in these other testing areas and run through them in addition to the robustness testing?”

Initially I would still find out what they want up front, to determine their scope. This would always be my priority in testing.

However, during testing, I would make more of an effort to discuss anomalies outside the agreed scope.

For example, even though Usability is ‘out of scope’ I would say something like: “I noticed the screens looked really odd, is that how you want them….”

I think time and money are always factors in deciding what you can or can’t test, I think generally, I would try and keep the communication verbal, as its quicker and cheaper than writing bugs.

The key would be to put yourself in the position where you are able to discuss bugs outside the scope with your client during the project as opposed to leaving it to the end.