Die Top-Ten der methodischen Fehler im Software-Testing: Platz 9

Platz 9: Performance- und Lasttests kommen zuletzt
Im Vergleich zu den meisten gängigen Teststufen bringen Performance- und Lasttests wichtige Informationen im Bereich der nicht funktionalen Qualitätsmerkmale zutage. Besagte Tests haben zwei „Nachteile“: Zum einen sind sie kostenintensiv – d. h. hier ist der Einsatz von dafür speziell entwickelten Testtools unabdingbar, da manuelles Testen ausscheidet – und zum anderen bedarf es fundierter Kenntnisse und Erfahrung zur richtigen Auswertung der von den Spezialtools gelieferten Daten.

Oft sind bei Software-Unternehmen weder die Werkzeuge noch die mit der Fachkenntnis ausgestatteten Testingenieure im Haus verfügbar. So wird dieses wichtige Thema gerne „auf die lange Bank“ geschoben. Entweder werden die Tests gar nicht bei der Planung berücksichtigt oder einfach am Ende der eigentlichen Tests „angehängt“. Diese Vorgehensweise macht wenig Sinn.

Zu wichtigen Bereichen der nicht funktionalen Qualitätsmerkmale können – wie bereits erwähnt – keine Aussagen getroffen werden. Ferner stellt sich die Frage, wie im „Fehlerfalle“ die ermittelten Informationen vor der geplanten Produktauslieferung zur Produktverbesserung noch eingesetzt werden können. Zum besseren Verständnis meiner Frage und deren Bedeutung möchte ich etwas weiter ausholen.

Bei einem klassischen Funktionaltest in der Systemteststufe beispielsweise ist es „normal“, bis kurz vor der eigentlichen Auslieferung zu testen, um möglichst viele Fehler zu finden. Sicherlich kann man auch an dieser Vorgehensweise Kritik üben, doch ich möchte es einmal „pragmatisch“ betrachten. Es werden also mehr oder weniger kritische Defekte gefunden, welche im funktionalen Umfeld anzusiedeln sind. Zum Beispiel eine fehlerhafte Berechnungsprozedur innerhalb einer Funktion. Selbst sehr kritische und komplexe Programmschwächen lassen sich in der Regel recht schnell „bugfixen“ und entweder bei der eigentlichen Produktauslieferung berücksichtigen oder per Patch nachliefern.

Bei Performance-, Last- und Stresstests betrachtet man letztlich jedoch die Software-Architektur. Das heißt, man möchte Qualitätsaussagen in Bezug auf die Architekturgüte der eingesetzten Systeme erhalten. Gesetzt den Fall, man erhält nun Testergebnisse, welche außerhalb der erwarteten Ergebnisbereiche liegen, und es liegt in diesem Falle ein negatives Testergebnis vor, so signalisiert dies Handlungsbedarf.

Wie zuvor bereits angedeutet, liegen in den meisten Fällen die Ursachen – anders als bei Funktionaltests – hier in den konzipierten Architekturen. Dies schließt per Definitionem ein kurzfristig angelegtes „Bugfixing“ aus. Dieser Begriff ist hier auch in der Tat fehl am Platze, denn letztlich kommt man um eine Änderung der betreffenden Architekturen nicht herum. Die damit verbundenen Aufgaben und Folgeaufgaben zur vollständigen Lösung des Problems sind damit mittel- bis langfristig – also im zeitlichen Umfeld von 3 bis 12 Monaten oder länger – anzusiedeln.

Das heißt: Bei Fehlern im funktionalen Umfeld können diese (im Vergleich zu Architekturproblemen) kurzfristig gelöst werden. Aus diesem Grunde können entsprechende Funktionaltests, wenn es auch nicht gängigen Qualitätstheorien und -empfehlungen entspricht, relativ spät innerhalb der Entwicklungsaktivitäten eingeplant werden und dabei dennoch positive (wenn auch begrenzte) Effekte bewirken. Die, durch Korrekturen bedingten, zeitlichen Verzögerungen bezüglich der entsprechenden Versionsverfügbarkeit halten sich in Grenzen. Bei den angesprochenen Architekturthemen ist dies jedoch unmöglich. Zumindest werden die zuvor beschriebenen negativen Effekte nicht ausbleiben!

Besser ist es, insbesondere Performance- und Lasttests bereits am Entwicklungsanfang mit einzuplanen. So zum Beispiel bereits bei den Unittests! Dies hilft dem Entwickler, architektonische Mängel schnell zu erkennen. Architekturmängel „im Großen“ lassen sich mithilfe der Design-Analyse anhand der Architekturkonzepte gut nachvollziehen. Bei Mängeln im Detail gibt es jedoch nur bedingt Alternativen hierzu. Eine Option wäre sicherlich, die strikte Verwendung von Architekturpatterns. Dennoch können auch bei diesem Ansatz (in Ausnahmefällen) Probleme entstehen, welche durch besagte Tests erkannt werden können. Dieser Ansatz bietet zudem den Vorteil, dass Korrekturen an der Architektur bei in der Entwicklung befindlichen und nicht produktiven Systemen oder Methoden vergleichsweise schnell und kostengünstig umzusetzen sind.