“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.
“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.
“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.
“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
“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.