& 4 & c & b & a & c & a & \xmark & \xmark & \doTCC & \doTCC\\
                & 5 & b & a & b & c & a & \xmark & \xmark & \doTCC & \doTCC\\
                & 6 & b & b & a & b & b & \xmark & \xmark & \doTCC & \doTCC\\
-               & 7 & c & b & b & a & b & \doTCC & \doTCC & \doTCC & \doTCC\\
-               & 8 & b & b & b & a & b & \doTCC & \doTCC & \doTCC & \doTCC\\
+               & 7 & c & b & b & a & b & \xmark & \doTCC & \doTCC & \doTCC\\
+               & 8 & b & b & b & a & b & \xmark & \doTCC & \doTCC & \doTCC\\
                & 9 & a & b & b & b & a & \xmark & \xmark & \doTCC & \doTCC\\
                \hline
 \end{tabular}
 
 As always, $100\%$ completeness is not feasible, therefore test cases are
 carefully selected to cover the most interesting parts of the TCP specification
-to ensure a test suite.
+to ensure a complete but feasible test suite.
+
+To further increase the coverage of the test suites tests are randomized. The
+tests which test the handling of \emph{bit errors}, changes in the \emph{packet
+order} and \emph{dropped packets} randomize where they introduce an error. The
+test suite runs these tests multiple times to increase the likelihood that they
+discover a fault which is only present when an error occurs in a certain
+position. 
 
 To further decrease the number of tests needed test cases are divided into
 equivalence partitions and the combination of cases as described in