Bei MySQL laufen rund um die Uhr automatisierte Testsysteme. Seit Jahren löst jede Änderung am Quellcode des MySQL Servers diverse Testläufe aus. Der Server wird automatisch auf allerlei Testmaschinen kompiliert und es wird die komplette Testsammlung ausgeführt. Am Ende steht man vor einer Matrix mit einigen tausend oder zehntausend einzelnen Testergebnissen. Aus den Daten werde im nächsten Schritt Zusammenfassungen generiert, die dem Entwickler helfen sollen die Nebenwirkungen einer Änderung frühzeitig zu erkennen.

Kontinuierliches Testen findet auch im Connectors-Team statt. Und es führt regelmäßig zum Streit. Vor jedem neuen MySQL-Release läßt der QA-Abgesandte alle Tests, deren er habhaft werden kann, auf einer Platform gegen den MySQL Release-Kandidaten laufen. Der weitere Verlauf des Freitagabend, es ist immer ein Freitag, weil die Testsysteme das Wochenende als Rechenzeit bekommen, ist monotoner als ein schwarz-weißer Stummfilm. Irgendein Test schlägt immer fehl. Wie im Fernsehen kommt es zur Wiederholung: welche Version vom Treiber soll getestet werden, welche Tests sollen benutzt werden, warum gibt es Testfehler und welche sind relevant?

Es gibt rund 20,000 Permutationen aus PHP-Test (ca. 560) und MySQL Buildplatformen (über 40). Ich habe keine Ahnung welche davon mit welcher PHP-Version, welchem MySQL-Server und welcher Codeversion auf welcher Platform welches Ergebnis liefern. Diese Antwort ist dem QA-Abgesandten zu wenig. Er fordert deshalb so lange an den Tests zu arbeiten bis alle Tests auf allen Platformen mit allen nur erdenklichen Randvariablen durchlaufen egal wie groß der Aufwand ist. Der Wunsch nach 0-Testfehlern scheint extrem ausgeprägt: ich habe erlebt wie Tests deaktiviert wurden, nur um die 0-Testfehler zu erreichen.

Weder ist es immer ökonomisch sinnvoll zu versuchen alles zu testen und stets 0-Testsfehler zu erreichen noch ist es eine gute Idee ungewünschte Tests zu deaktivieren. Die Grenze des Testens ist erreicht, wenn die Kosten für Bugfixes unter denen des Testens liegen. Das deaktivieren eines Tests, um 0-Testfehler zu erreichen ist falsch, da auch die Gleichheit eines Fehlers eine sinnvolle Information ist.

Andrey ist im Urlaub, Johannes war mit PHP 5.3 beschäftigt – Zeit für mich Testergebnisse in eine Datenbank einzulesen und die 0-Testfehler-Regel auszutauschen gegen eine Fuzzy-Logik, welche Testläufe vergleicht. Was interessiert es den QA-Abgesandten einer Randbedingung (MySQL Server, PHP Version) wie die Tests sich verhalten solange sie sich nur gleich verhalten, wenn die Randbedingung geändert wird. Er braucht das Delta. Siehe iframes (gefakte Testdaten).