Q107: Wie oft ist 80 in 100 enthalten?

Wegen dem SelfOnBoarding-Webservice hat DLTB den Standardkonverter angegriffen. Eh nur den Outbound-Teil, aber trotzdem. Beim Estimaten für diese Umsetzung hat’s geheißen „Is eh net vü zum umbauen…“. Das hätte ja auch gestimmt, wenn es da nicht dieses Fraggle-Gesetz gäbe. Welches? Na das: „Verlasse jede Java-Klasse die du angreifst  besser als du sie vorgefunden hast!“. Was soviel heißt wie: „Ein wenig Refactoring ist immer drinnen!“. Fähnchen Fieselschweif lässt grüßen.

DLTB hat auch refactored. Aber ordentlich. Bei der Erstellung der Teststrategie haben wir uns dann darauf geeinigt das 80% Testaufwand, der ursprünglich mit weniger veranschlagt war, in den Outbound-Test gesteckt werden sollen. Weil den Inbound-Teil hat er nur in einem unbedeutenden Teil angegriffen, der nicht Risikoreich ist. Düsentrieb fixt aber gleichzeitig einen Bug mit den Call-Additionals beim Inbound, was „eh nur eine Kleinigkeit“ ist. Also ich glaub DLTB ja fast alles, aber Düsentrieb und eine Kleinigkeit? Nein, das kann net sein. Und was ist?

Heute habe ich mit Düsentrieb die Teststrategie für den Inbound-Teil definiert. Und der hat auch ordentlich Gas gegeben was das Bugfixen angeht. Was soviel heißt wie, das soll auch mit 80% Testaufwand getestet werden. Wegen dem Risiko. So, liebe Rechengenies. Ich habe 100% Testaufwand um den Konverter zu testen. 80% Aufwand für den Inbound-Teil, 80% für den Outbound-Teil. Wo liegt da der Rechenfehler?