| After you complete the high-level review of the product specification, you'll have a better understanding of what your product is and what external influences affect its design. Armed with this information, you can move on to testing the specification at a lower level. The remainder of this chapter explains the specifics for doing this.[1] [1] The checklists are adapted from pp.294-295 and 303-308 of the Handbook of Walkthroughs, Inspections, and Technical Reviews, 3rd Edition Copyright 1990, 1982 by D.P. Freedman and G.M. Weinberg. Used by permission of Dorset House Publishing (www.dorsethouse.com). All rights reserved.
Specification Attributes Checklist A good, well-thought-out product specification, with "all its t's crossed and its i's dotted," has eight important attributes: Complete. Is anything missing or forgotten? Is it thorough? Does it include everything necessary to make it stand alone? Accurate. Is the proposed solution correct? Does it properly define the goal? Are there any errors? Precise, Unambiguous, and Clear. Is the description exact and not vague? Is there a single interpretation? Is it easy to read and understand? Consistent. Is the description of the feature written so that it doesn't conflict with itself or other items in the specification? Relevant. Is the statement necessary to specify the feature? Is it extra information that should be left out? Is the feature traceable to an original customer need? Feasible. Can the feature be implemented with the available personnel, tools, and resources within the specified budget and schedule? Code-free. Does the specification stick with defining the product and not the underlying software design, architecture, and code? Testable. Can the feature be tested? Is enough information provided that a tester could create tests to verify its operation?
When you're testing a product spec, reading its text, or examining its figures, carefully consider each of these traits. Ask yourself if the words and pictures you're reviewing have these attributes. If they don't, you've found a bug that needs to be addressed. Specification Terminology Checklist A complement to the previous attributes list is a list of problem words to look for while reviewing a specification. The appearance of these words often signifies that a feature isn't yet completely thought outit likely falls under one of the preceding attributes. Look for these words in the specification and carefully review how they're used in context. The spec may go on to clarify or elaborate on them, or it may leave them ambiguousin which case, you've found a bug. Always, Every, All, None, Never. If you see words such as these that denote something as certain or absolute, make sure that it is, indeed, certain. Put on your tester's hat and think of cases that violate them. Certainly, Therefore, Clearly, Obviously, Evidently. These words tend to persuade you into accepting something as a given. Don't fall into the trap. Some, Sometimes, Often, Usually, Ordinarily, Customarily, Most, Mostly. These words are too vague. It's impossible to test a feature that operates "sometimes." Etc., And So Forth, And So On, Such As. Lists that finish with words such as these aren't testable. Lists need to be absolute or explained so that there's no confusion as to how the series is generated and what appears next in the list. Good, Fast, Cheap, Efficient, Small, Stable. These are unquantifiable terms. They aren't testable. If they appear in a specification, they must be further defined to explain exactly what they mean. Handled, Processed, Rejected, Skipped, Eliminated. These terms can hide large amounts of functionality that need to be specified. If…Then…(but missing Else). Look for statements that have "If…Then" clauses but don't have a matching "Else." Ask yourself what will happen if the "if" doesn't happen.
|
