& 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