Typische Schwachstellen eines Testprojekts

Die Top Ten der methodischen Fehler im Softwaretest – Teil 1
Kommentare

Heute ist klar, dass mangelhafte Software unternehmenskritische Risiken in sich birgt. Sie kann ein Unternehmen gar in den Ruin führen. Nur richtig geplante, konzipierte und organisierte Testprojekte unterstützen ein funktionierendes Risikomanagement und liefern verlässliche Qualitätsaussagen zu den getesteten Produkten. In diesem Zusammenhang habe ich meine persönliche Rangliste der zehn häufigsten und schwerwiegendsten Fehler bezüglich Testmethodik zusammengestellt, die ich in diesem Artikel vorstellen möchte.

Gerade im IT- und Softwareumfeld ändert sich vieles in relativ kurzen Zeitabständen. Nur ein Thema scheint seit Bestehen der Disziplinen konstant zu bleiben: Die Anforderungen an Produkte und Dienstleistungen nehmen ständig zu. Sowohl die Kontinuität als auch die Geschwindigkeit sind hierbei bemerkenswert. Keine andere Branche ist – bezogen auf die Ausmaße – mit derartigen Herausforderungen konfrontiert wie die IT- bzw. Softwarebranche. Umso erstaunlicher ist es, dass trotz dieser Herausforderungen gerade Qualitätsmanagement- und Qualitätssicherungsaktivitäten im Vergleich zu anderen Branchen wenig beachtet werden.

Fehler werden unterschätzt!

In jedem Test werden in der Regel Fehler gefunden. Diese werden bereits vom Testteam einer ersten Bewertung unterzogen. Im Rahmen weiterer Bearbeitungen wird die Fehlerschwere, d. h. werden mögliche Auswirkungen auf das Business oft korrigiert. Interessanterweise werden die gefundenen Fehler von anderen Bereichen stets als weniger relevant bewertet – im Vergleich zu den Einschätzungen der Testabteilungen. Das heißt, die Fehler werden in Bezug auf deren Schwere oder Priorität oft herabgesetzt. Es kann ja sein, dass Testteams Fehler falsch einschätzen, aber sollen dabei tatsächlich alle Einschätzungen überzogen sein? Das ist sehr unwahrscheinlich. Dabei ist das Vorgehen, Fehler zu verniedlichen, nicht besonders geschickt. Es ist nur ein vordergründiger „Vorteil“, einer zeitnahen Fehlerbehebung zu entgehen. Hierdurch entstehen allerdings jede Menge neuer Risiken, die dann meist zusätzlich – neben der Fehlerbehebung – zu behandeln sind. Welche weiteren Auswirkungen haben in der Produktion befindliche Defekte auf die Geschäftsprozesse und das Unternehmen? Mit welchen zusätzlichen Kosten ist durch etwaige Ausfälle und Folgefehler (z. B. erhöhte Serviceaufwände, Etablierung von Zwischenlösungen, Schadensersatz, Umsatzausfall, Imageverlust …) zu rechnen? Lassen sich durch die Ausfälle die Jahresziele des Unternehmens noch erreichen? Wie sieht es mit dem generellen Vertrauen der Anwender in die Software, die IT-Umgebung bzw. die Lösung aus?

Besser ist es, einen Fehler zu überschätzen als ihn zu unterschätzen. Dies fördert eine zeitnahe Behebung des Defekts. Die reinen Fehlerbehebungskosten werden dadurch günstiger sein, als würden die betreffenden Ursachen erst mittel- oder langfristig beseitigt. Die Sekundärkosten für Schadensersatz, Image- und Vertrauensverlust als Beispiele, bleiben bei diesem Ansatz womöglich ganz erspart. Jedoch möchte ich hierbei auch betonen, dass meine Regel nicht dazu missbraucht werden sollte, jeden Defekt nur noch mit der höchsten Fehlerklasse bzw. Priorität zu belegen. Es ist hilfreich, vorab ein Regelwerk mit Beispielen zu entwickeln, wie Fehler bewertet werden sollen. So kann eine einheitliche Bewertung sichergestellt werden.

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 Softwareunternehmen weder die Werkzeuge noch die mit der Fachkenntnis ausgestatteten Testingenieure im Hause 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, die 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 Softwarearchitektur. 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 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 drei bis zwölf Monaten oder länger – anzusiedeln.

Das bedeutet: 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 Unit Tests. Dies hilft dem Entwickler, architektonische Mängel schnell zu erkennen. Architekturmängel „im Großen“ lassen sich mithilfe der Designanalyse 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 Architektur- Patterns. Dennoch können auch bei diesem Ansatz (in Ausnahmefällen) Probleme entstehen, die 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.

Weiter mit: Teil 2

Alle Teile: Teil 1, Teil 2, Teil 3, Teil 4, Teil 5, Teil 6

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -