« Seven Deadly Agile Sins| Main | Arches, Arches, Everywhere »
It's not Just Testing
Lately when we talk about making sure our code is done well, we talk about various types of testing -- unit, system, stress, integration, performance, etc.
But it's not just testing. Everybody knows (or should know) what a code walkthrough is. Here are some other creatures in the quality closet. You may never use these, but it's good to have them handy and know what they are.
- Audit - (1) (IEEE) An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. See: functional configuration audit, physical configuration audit. (2) (ANSI) To conduct an independent review and examination of system records and activities in order to test the adequacy and effectiveness of data security and data integrity procedures, to ensure compliance with established policy and operational procedures, and to recommend any necessary changes.
- Code Inspection - (Myers/NBS) A manual [formal] testing [error detection] technique where the programmer reads source code, statement by statement, to a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards. Contrast with code audit, code review, code walkthrough. This technique can also be applied to other software and configuration items. Syn: Fagan Inspection. See: static analysis.
- Code Review - (IEEE) A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Contrast with code audit, code inspection, code walkthrough.
- Review - (IEEE) A process or meeting during which a work product or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review, test readiness review. Contrast with audit, inspection. See: static analysis.
- Software Review - (IEEE) An evaluation of software elements to ascertain discrepancies from planned results and to recommend improvement. This evaluation follows a formal process. Syn: software audit. See: code audit, code inspection, code review, code walkthrough, design review, specification analysis, static analysis
- Validation - (1) (FDA) Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes. Contrast with data validation.
- verification (software) - (NBS) In general the demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle. See: validation, software.
- Defect Taxonomy - Once a problem leaves the iteration and the team, a defect taxonomy is the most important thing an organization can have. It is:
A defect is a structural property of a software document of any kind (e.g. requirements description, test plan, source code, configuration file), namely a deviation from the nearest (i.e. most similar) correct document that makes the document incorrect or locally incorrect.
A taxonomy is a system of hierarchical categories designed to be a useful aid for reproducibly classifying things.
A defect taxonomy is a common set of well-defined buckets for the organization to put problems into. It gives meaning to logging defects in the first place. Without one, logging defects has no purpose, with an overly complicated one, logging defects becomes an impediment instead of an accelerator.
- Bug - A software bug (or just "bug") is an error, flaw, mistake, failure, fault or "undocumented feature" in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.
- Error - Error refers to a difference between actual behavior or measurement and the norms or expectations for the behavior or measurement. The concrete meaning of the Latin word error means "ramble" or "misconception", although the metaphorical meaning "mistake, misapprehension" is more common.
- Exception - A useful way to signal that the routine could not execute normally, for example when its input arguments are invalid (a zero denominator in division) or when a resource it relies on is unavailable (a missing file, or a disk error). In systems without exceptions, the routine would need to return some special error code. However, this sometimes is complicated by the semipredicate problem, in which users of the routine need to write extra code to distinguish normal return values from erroneous ones.
- Defect - Any type of undesired result is a defect.
A failure to meet one of the acceptance criteria of your customers. A defective unit may have one or more defects.
'A defect is a failure to conform to requirements' (Crosby, 'Quality Is Free'), whether or not those requirements have been articulated or specified.
The non-conformance to intended usage requirement.
Leave a comment