Anomaly in Software Testing

What is Anomaly?

An anomaly reflects the occurrence of any sort of deviation from the available or desired or expected standards and specifications. These anomalies may be seen, both in both living and non-living things. For example, in human beings, an infant born with six fingers on one or both the hands, may be seen as an anomaly. Similarly, a system or an application is programmed to convert English texts into French text, whereas, it actually converting it into Spanish text, is a type of anomaly, which has prevailed in the system.

Now coming to the software testing, an anomaly shows the difference between the actual results and what was desired or expected to be. These types of anomalies may be seen, not only in the functioning of a software product, but also in the design document, software requirement specification(SRS), user stories, use cases, or in any such thing from different user's perspective. Moreover, any feature or functionality or anything, which needs further improvement, may also be seen as a kind of anomaly, which needs to be corrected.

So basically, anomaly is nothing, but a defect, occurred in a software product, and there could be any possible reason, behind these, such as misinterpreting the specification and requirement, wrong execution of the test cases, implementing wrong user stories, etc.

Testing is an efficient and proven technique, which is used, in the direction of removing or reducing these sorts of anomalies, from a software product.

Data Flow Anomalies:

Data flow anomalies are used to indicate the programming error in a software product. Usually, this type of anomaly is identified and revealed, during the execution of White box and Black box testing technique.

These anomalies are represented, with the help of a multiple pairs of alphabet, which are used to depict a particular sequence of action or event. Generally, 3 alphabets are made into use, namely 'd', 'k', & 'u', where 'd' means defined, 'k' is for killed, 'u' is for used.

Below given is the description of the possible combination of these alphabets, along with their degree of severity or impact, on the basis of which, these may or may not be categorized under anomaly.

Possible Combination Description Consequence
dd Defining a data object repetitively. Harmless but may be vulnerable.
dk Defining a data object and killing it, without making its use. May be a defect, due to poor programming logics.
du Defining a data object and implementing it for the use. No issue.
kd Killing a data object and then again redefining it. No issue.
kk Killing a data object, again and again. Harmless, but may contain a bug/defect.
ku Killing a data object and thereafter using it, as such it will have no variable to store. Defect
ud Using a data object and then redefining it. No issue.
uk Using a data object, and then killing it. No issue.
uu Using again and again, a data object. No issue.

Anomaly Report:

Anomaly report or a bug or defect report, is used to report and provide necessary data and information of the detected anamolies, to the development or the project team, and usually consists of the following elements:

  • Defect Identifier: A unique ID, for each identified defect.
  • Defect Description: Provides the detail about the defects.
  • Status of the Defect: Current status of the defect.
  • Steps to reproduce the defects.
  • Severity.
  • Priority.
  • Defect Reported Date.
  • Test Environment.
  • Attachments, such as sheets, screenshots, etc.
  • Comments, if any.

ThinkSys Advertisement
ThinkSys Advertisement
ThinkSys Advertisement


ThinkSys Advertisement


App development ad thinksys