“Exception Handling” faults that are due incorrect exception handling: either missing exception handling or handling an exception improperly that puts the system in a bad state leading to a failure. This fault type is closely related to the next two types, however, if the fault concerns exceptions, this category should be used.
“Missing evaluation” when an evaluation or change in variable is missing. (eg. bracketing for a max value before continuing)
“Missing case initialization” when the obviously missed case can be resolved by initialization of something, eg. adding a value representing the case to an array.
“Processing” faults: Something was implemented, but the implementation is incorrect. This can range from simple miscalculations, to incorrect output of a method, to wrong method usage, to wrong library usage, that puts the system in a bad state leading to a failure.
“Native overflow” Integer, float, etc overflows. (If the int that is overflowing is used as index for accessing an array it should be considered in “memory” category.
“Method (override) missing” Eg. When a subclass behaves incorrect because the method from superclass is not doing what is supposed to happen in case of this subclass, or a constructor is missing.
“Re-implementation” Design stays the same while the internals are re implemented. (eg. implementation using regex is re-implemented to custom parsing implementation) (Runaway recursions have their own subsubcategory)
“Wrong evaluation” Wrong calculation, evaluation, etc.
“If condition incorrect” If the conditional statements of an if condition are bound together with wrong operators, or by wrong evaluation. (if there is an additional condition this belongs to missing case)
“Data missing / not propagated” When data isnt propagated or wrongly propagated, or wrong data propagated. eg. Method signatures changed to propagate data to where it is required.
“Scope wrong” Scope of a variable, method, or class is incorrect. Eg. a static member variable is changed into a instance member variable)
“Call order incorrect” if calls are in wrong order (eg. callbacks and listeners)
“Wrong/incorrect algorithm” if the used algorithm is the wrong one, or if the algorithm is incorrect. (eg. “runaway recursion” can also be considered a subset, if the algorithm based on recursion is replaced by another implementation of the same algorithm)
“Dependency” faults are introduced by changes in a foreign system so that the software can be build, but behaves unexpected. Examples could be recent changes in API or behaviour of underlying OS or utilized libraries that lead to a failure. Please note that the failure has to be introduced by a change in the external/foreign system. Failures caused by not adequately dealing with behaviour of the original external/foreign system fall into other categories.
“Other” for all semantic faults that do not fall into any of the aforementioned categories.
“Order violation” faults are caused by missing or incorrect synchronization, e.g. an object is dereferenced by thread B before it is initialized by thread A.
“Atomic violation” faults result from lack of constraints on the interleaving of operations. This happens when atomicity of a certain code region was assumed but failed to guarantee atomicity of in the implementation. Please classify a bug only as atomic violation, when it is not an order violation or race condition.
“Missing synchronization” Synchronization is missing on a piece of code, Eg. missing @Synchronized on a method, or similar
“ConcurrentModificationException” Using improper datatypes for concurrent access, eg. concurrently accessing HashMaps that would result in exceptions in contrast to race conditions.
“Not atomic” operation on a datatype that is not thread safe, opening the possibility of race conditions. Eg. incrementing java int in multiple threads.
“Parallelisation” if something is slowing/lagging a thread, and the fix is to have it run by a more appropriate executor, or vice versa, if something multithreaded has to run in a single thread due to some constraints.
“Lock not released” Contrary to a deadlock, there’s no two threads deadlocking on each other, but a method or resource cannot be acquired anymore because the lock was not released on exit. Eg. exception handling within a locked code block without a finally statement leaving the lock acquired while the thread was thrown out of the code block.