140 likes | 396 Views
Course Notes : Examining the Specification. Computer Science and Software Engineering Auburn University. Specification. Requirements document – what the software will become Can be of many formats and detail levels - programming project/problem assignments
E N D
Course Notes:Examining the Specification Computer Science and Software Engineering Auburn University
Specification • Requirements document – what the software will become • Can be of many formats and detail levels - programming project/problem assignments - quality measurement is based on this • Specification is testable; can be used to find bugs before software is developed [Software Testing, by Ron Patton, Sams Pub. 2001]
Testing Fundamentals • Black box testing – what is supposed to be done functionality - does not concern how the software accomplish the work - outside view of the software - input-output relationships
Testing Fundamentals (cont’) • White (clear) box testing – how the software does its job - look into code details • Static Testing – testing a software without running it - examination - review
Testing Fundamentals (cont’) • Dynamic Testing – running the program • Testing specification - static black box testing - specification is not a program static - goal: to find bugs early
High Level Review of Specification • First Step: Stand back and view it from high level • Better understanding of the Spec – why and how
High Level Review of Specification (Cont’) • Pretend to be the customer - find out who they are, e.g. research & interview - gain familiarity of the application field - customer expectations, quality is measured in terms of these expectations - try to understand the spec
High Level Review of Specification (Cont’) • Research existing standards and guidelines - why standards and guidelines? . terminology and conventions . Industrial/government requirements . Hardware/software interfaces - make sure correct standards & guidelines are used or applied
High Level Review of Specification (Cont’) • Review and test similar software - similar systems of feel and look efficiency - competitors’ products - issues to review . Scale: bigger, smaller, similar, etc. . Complexity . Testability: can you test such software . Quality/reliability - use the software
Low Level Specification Test • Specification Attribute Checklist - A good, well-thought-out specification: . Complete . Accurate . Precise, unambiguous, and clear . Consistent . Relevant . Feasible . Code-free: what, but not how . Testable
Low Level Specification Test (Cont’) • Specification terminology checklist - avoid problem words . Always, every, all, none, never: absolute . Certainly, therefore, clearly, obviously, … . Sometimes, often, usually, … . Etc., and-so-on, and-so-forth: no way to test . Good, fast, cheap, efficient, … : not quantified . Handled, processed, rejected: task not clear . If … then … (forget else)
Is Specification Testable? • Yes! • Sample usage scenarios - For example, the user will … - All aspects of the scenarios must be covered.
Examining Specification Summary • Subjective process - not a step by step process • Higher level review - to flush out oversights and omissions • Low level techniques - to assure all details are defined