Q258: Du und deine Giftfinga!

Mittwoch, Bär(Pair)-Testing-Session mit FRAFU.

Eine Software-Acceptance-Test muss her. FRAFU hat noch eine Anpassung zu einem RFC nachgeliefert.


Software-Acceptance-Test. Schönes Wort. So heißt bei uns die Teststufe bei der ich versuche DAS DING zu brechen. Also Last.-, Robustheits- und GAU-Tests. GAU? Damit ist der gemeinste anzunehmende User gemeint. Also der, der DAS DING in einer Art und Weise benutzt, die in keiner Doku steht.

Da mach ich dann z.B. einen Upload mit 50000 Parent-Child-Calls und schau dann wie sich die grafische Darstellung rekursiv in den Arsch beißt. In solchen Situation freu ich mich dann wie ein Nackerpantscherl wenn mir der Entwickler erzählt dass es bei ihm mit 20 Calls aber eh funktioniert hat. „Wer bitte testet mit 50000 Calls mit solchen Referenzen?“ – Na wer wohl?

Nun ja, ich schau mir DAS NEUE DING also an und kapier es nicht. Das Requirements-Doc schau ich gar nicht erst an. Stichwort: Agiles Requirements Engineering. Da spendier ich einfach dem FRAFU einen Kaffee und lass mir DAS DING beim Bär(Pair)-Testing erklären. 

Meine erste Frage warum das neue Feld so benannt wurde und daher nicht selbsterklärend ist,  beantwortet er mit: „De hassen olle so!“. Nicht dass der Name schlecht gewählt ist, mich verwirrt einfach in der Feldübersicht die Beschreibung dazu. Das passt nicht zusammen. Als Endanwender, und aus dessen Sicht schau ich mir DAS DING ja auch an, frage ich mich: „????“.

Nach a bissal hin und her kommt von FRAFU ein: „Jo waummas so siecht host recht! I werd des korregian!“.

Danach erklärt mir der Erz-Rapidler die neue Funktion. „Wenn in dem Feld ein Wert steht dann wird der Button angezeigt über den dann die neue Funktion verfügbar ist. So wie jetzt.“ – „Aha, das heißt aber auch wenn ich den Wert wieder entferne dann wird der Button nicht angezeigt?“ – „Richtig, du host das kapiert!“ Toni Polster würde sagen: „Blitzgneissa!“

Ich mach natürlich gleich die Probe aufs Example und siehe da, es funktioniert. Aber nur wenn das Feld noch nie mit einem Wert belegt war. Also ein initial leeres Feld zeigt den Button nicht an. Ein Feld das bereits einmal gefüllt war (Funktion wurde aktiviert) und dann wieder geleert wurde (Funktion wurde deaktiviert) zeigt den Button trotzdem an. Obwohl es ja im Prinzip leer ist.

FRAFU wird natürlich gleich unrund: „Du und deine Giftfinga! Bei mia is gaunga! I schau ma des gleich aun!“ Drei Minuten später hat er den Bug gefunden. „Hob nur auf Null ogfrogt. Schaaaß!“ Ein klassischer Grenzwert-Bug also.

Zwei Minuten später sitzt er gemeinsam mit Sitting Bull vor dem Rechner und erklärt ihm beim Bär(Pair)-Checkin, das ist unsere Art von Paircoding nach DEM Codefreeze, was er gemacht hat. Nach dem nächsten Deployment kann ich das Ganze retesten und mit „Works as defined“ abhaken.

Zu letzt erweitere ich die Q.,sche-Fehler-Taxonomie um den Zusatz:

- Neue Felder immer mit initialen Null-Werten testen als auch mit bereits einmal verwendeten Feldern.


Wem ich wohl meine Taxonomie zum lesen gebe?