Don’t you hate it when people say that you “should do this” and “shouldn’t do that”? I do, especially when they are saying it in a Requirements Document. “Should” can mean a lot of things, but it doesn’t mean “require.” There is nothing worse for a tester than not knowing if a function *must* be present or not. Instead of “should,” I’d much rather hear “must do this” and “must not do that.”
Words like “should” leave testers hanging under a cloud of uncertainty—you don’t know if it was intended as a “must” or as a “nice-to-have.” Words like “should” are begging to be ignored, and you don’t have to beg much to be ignored by a programmer (meant in a nice way).
If you have done your job and traced all of the testscript steps back to the Requirements Document, then you know how troublesome “shoulds” can become. Do you include “shoulds” and “should-nots” in a testscript? If you are lazy like most smart people (slightly kidding), then of course not! Why bother including a “should” statement that’s begging to be ignored? The programmers probably left it out of the functionality anyway.
The point of this semantical shibboleth: Make sure every Requirements statement will map to a piece of functionality that must be present, and will map to a testscript that you can mark with a definitive “pass” or “fail.” The takeaway requirement from this entry: You Must Not Say Should.