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. \u201cShould\u201d can mean a lot of things, but it doesn\u2019t mean \u201crequire.\u201d There is nothing worse for a tester than not knowing if a function *must* be present or not. Instead of \u201cshould,\u201d I\u2019d much rather hear \u201cmust do this\u201d and \u201cmust not do that.\u201d<\/p>\n
Words like “should” leave testers hanging under a cloud of uncertainty\u2014you don’t know if it was intended as a “must” or as a “nice-to-have.” Words like \u201cshould\u201d are begging to be ignored, and you don\u2019t have to beg much to be ignored by a programmer (meant in a nice way).<\/p>\n
If you have done your job and traced all of the testscript steps back to the Requirements Document, then you know how troublesome \u201cshoulds\u201d 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\u2019s begging to be ignored? The programmers probably left it out of the functionality anyway.<\/p>\n
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 \u201cpass\u201d or \u201cfail.\u201d The takeaway requirement from this entry: You Must Not Say Should.<\/p>\n