Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

|
//

Zahlengläubigkeit

26.8.2010 | 3 Minuten Lesezeit

So ungefähr sieht meines Erachtens nach ein typisches Albtraumszenario eines Performance-Testers aus: Eine neue Version eines Testobjekts findet den Weg in meine Hände. Nach etwas Herumkonfigurieren, um das Ding ans Laufen zu kriegen, führe ich einen kurzen, ersten Testlauf durch. Irgendjemand – Entwicklung, Architektur, Projektmanagement, wer auch immer – bekommt davon Wind und ist neugierig auf die Ergebnisse. Ich versuche es mit einer Verzögerungstaktik: „Es ist der allererste Lauf. Die Testumgebung ist noch gar nicht vollständig aufgebaut. Wir müssen noch mehr Tests durchführen. Erst müssen wir die Zahlen bestätigen, bevor es irgendeinen Sinn ergibt, sie zu diskutieren.“ Mein Gegenüber gibt nicht auf und bohrt weiter. Er sei sich aller meiner Bedenken bewusst und wolle nur seine Neugier befriedigen. Letztendlich gebe ich nach und liefere die Zahlen, was ich schon kurz darauf zutiefst bereue. Mein kleines Fitzelchen an Information hat wie eine Lawine in Null-komma-Nichts eine gigantische Größe erreicht und kommt wie ein Bumerang zu mir zurück.

Fälle wie dieser sind oftmals die Folge einer übermäßigen Zahlengläubigkeit. Wenn etwas getestet und quantifiziert ist, vertraut man gerne den Ergebnissen und verlässt sich auf diese, ohne die konkreten Umstände zu berücksichtigen. Selbst ein allererster Messpunkt wird häufig gewichtet und auf eine Art und Weise diskutiert, als läge eine ausgefeilte und vollständige Testserie zugrunde. Sind die Zahlen schlecht, führt dies manchmal zu hektischen und gar sonderlichen Aktivitäten wie z.B. Eskalation, Krisensitzungen und eventuell sogar Maßnahmen seitens des Managements. Sind die Zahlen unerwartet gut, könnte eine voreilige Entwarnung die Folge sein.

Sogar der Performance-Tester selbst kann für solche Fehler anfällig sein. Ich kann hier aus eigener Erfahrung sprechen… Entweder, weil er ein bestimmtes Ergebnis wünscht oder erwartet, oder aus schlichter Routine heraus, kann er in Versuchung sein, seine gerade selbst ermittelten Zahlen zu schnell zu glauben. Anwendungssysteme und ihre Konfiguration sind oftmals sehr komplex, so dass man leicht kleine Änderungen mit möglicherweise großen Auswirkungen auf die Testergebnisse vergessen oder übersehen kann.

Dieser anscheinend unerschütterliche Glaube an die Gültigkeit von Zahlen kann noch viele andere ungünstige Folgen haben. Oftmals wird schon ein einzelner Datenpunkt hoffnungslos überanalysiert, indem z.B. mögliche  zukünftige Performance-Verbesserungen extrapoliert werden oder die Effekte auf ein n-Mal größeres System und so weiter. Falls dann weitere Tests diese Erwartungen nicht erfüllen, setzt manchmal eine hektische Suche nach der vermuteten versteckten Ursache der „falschen“ Zahlen ein, anstatt zu bedenken, dass man von Anfang an unvergleichbare Dinge verglichen hat. Ebenso werden manchmal bereits korrekt berichtete und archivierte Zahlen wiederentdeckt, aber ihr Kontext vergessen, was zu ebenso falschen Interpretationen, Schlüssen und Maßnahmen führen kann.

Meist ist es kaum möglich, erfolgreich gegen diese Zahlengläubigkeit zu argumentieren, darauf zu beharren, dass weitere Tests zur Bestätigung nötig sind und dass große Schwankungen ganz normal sind. Performance-Messungen als Teil der Qualitätssicherung in der Anwendungsentwicklung sind keine exakte Wissenschaft. Da die oberste Priorität normalerweise ist, „etwas ans Laufen zu kriegen“, sind die Vorbedingungen eines kontrollierten Experimentes wie in der akademischen Welt nur selten gegeben. Die Ergebnisse solcher Experimente werden aber oft genau so betrachtet und behandelt.

Als Performance-Tester sollte man sich bewusst sein, welche möglichen Auswirkungen die berichteten Testergebnisse haben können. Testen, besonders Performance-Testen, soll Unsicherheit durch Wissen ersetzen, aber der unvorsichtige Umgang mit Testergebnissen kann schnell zum entgegengesetzten Resultat führen. Meines Erachtens sollte die oberste Regel sein, nur Daten zu berichten, die man selbst verstanden hat, zu denen man stehen und die man verteidigen kann. Man sollte sich immer über die Belastbarkeit, Reichweite, Relevanz und Vergleichbarkeit der Zahlen im Klaren sein, die man berichtet, und diese Charakteristika ebenso berichten. Und es ist ratsam, explizit darauf hinzuweisen, falls eine Messung nur für einen bestimmten Testaufbau Aussagekraft besitzt und für weitere Hochrechnungen ungeeignet ist.

Falls eine Fehlinterpretation von Testergebnissen passiert, sollte man schnell, deutlich und mit Nachdruck die Sichtweise des Testers auf die Zahlen und ihren Kontext darstellen, um den möglichen Schaden zu begrenzen. Zahlen, die einmal in der Welt sind, nehmen gerne ein Eigenleben an. Wie bei Gerüchten ist es praktisch unmöglich, sie wieder einzufangen. Daher sollte man stets sorgfältig bedenken, was man wann berichtet.

Und ein letzter Rat: Als Performance-Tester sollte man sich immer einen skeptischen Blick auf die eigene Arbeit und auch auf die eigenen Instinkte bewahren. Andere Leute sollten Testergebnissen nicht blind glauben – und auch der Tester selbst sollte dies nicht tun.

|

Beitrag teilen

Gefällt mir

0

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.