In Software testing, Anomaly refers to a result that is different from the expected one. This behaviour can result from a document or also from a testers notion and experiences.
An Anomaly can also refer to a usability problem as the testware may behave as per the specification, but it can still improve on usability. Sometimes, the anomaly can also referred as a defect / Bug.
The following parameters are involved in a typical anomaly report :
Defect Identifier
Defect summary
Defect description
Status of Defect
Steps to reproduce the defect
Severity
Priority
Bug Logged Date
The area where the bug is identified
Developers/Testers comments
Data Flow Anomalies are identified while performing while box testing or Static Testing. Data flow anomalies are represented using two characters based on the sequence of actions. They are defined (d), killed (k), and used (u). There are nine possible combinations based on these 3 sequence of actions which are dd, dk, du, kd, kk, ku, ud, uk, uu. The below table clearly shows which one of these combinations are accepted and which one of these are suspected to be an anomaly.
Combination | Description | Anomaly possibilities |
---|---|---|
dd | Defined the data objects twice | Harmless but suspicious |
dk | Defined the data object but killed it without using it. | Bad Programming Practice |
du | Defined the data object and using it | NOT an Anomaly |
kd | Killed the Data Object and redefined | NOT an Anomaly |
kk | Killed the Data Object and killed it again | Bad Programming Practice |
ku | Killed the Data Object and then used | Defect |
ud | Used the Data Object and redefined | NOT an Anomaly |
uk | Used the Data Object and Killed | NOT an Anomaly |
uu | Used the Data Object and used it again | NOT an Anomaly |