Software testing/Glossary

Anomaly

In software testing an anomaly is everything that differs from expectation. This expectation can result from a document or also from a persons notion or experiences. Also an anomaly can be a feature or an usability problem, because the testobject may be correct regarding the specification - but it can be improved. Another possibility for an anomaly is that a tester executed the testcase wrong and therefore the expected result is also wrong.

see here for more info.

(see IEEE 1044-1993: Standard Classification for Software Anomalies., page 1, The Institute of Electrical and Electronics Engineers, Inc., New York, USA, 1994, ISBN 1-55937-383-0)

For the United States Department of Defense (DoD) an anomaly in test is an event that occurs outside the scope of the test, but affects the test. For example, a lightening strike knocks out the power or a tester uses the wrong test plan. Unexpected test results which indicate a system weakness are called deficiencies. Initially, all unexpected results are viewed as deficiencies until analysis shows they are anomalies. For example, if power is suddenly cut off to the entire neighborhood resulting in an abnormal end to testing, analysis must show the power outage was not caused by the system under test before it is labeled an anomaly.

See DoDI 5000.02: Operation of the Defense Acquisition System and many service-specific instructions on deficiencies; there are no DoD documents on anomalies because they are of no value by DoD definition.

Software

Is more than just source code. There belongs also: programs, procedures and documentation, and data for the concerning processing on a computer system. We (the tutors of this course) count also any testware.

(see IEEE 610-1990: The collection of computer programs, procedures and data, together with possibly associated documentation necessary to understand, install and use it.)

Testware

Including any kind of products, which is helpful for testing. Especially persons from the testing field produce these:

test plans, test cases, test reports, anomaly reports, input files/scripts for test tools, ...

They all should be reusable and therefore managed by configuration management.