Typische Schwachstellen eines Testprojekts

Die Top Ten der methodischen Fehler im Softwaretest – Teil 4
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.

Nachdem in Teil drei dieser Artikelserie die Gefahren „planlos“ durchgeführter Tests und der Unterschätzung von Test-Know-how besprochen wurden, folgt nun eine Besprechung der Probleme, die sich aus mangelhaftem Einsatz von Testautomatisierung sowie aus fehlendem Testdaten- und Testumgebungsmanagement ergeben können.

Kein oder falscher Einsatz der Testautomatisierung

Dieser Punkt ist wohl eine Wissensdisziplin innerhalb des Testens mit der größten Bandbreite an Vorstellungen und Erwartungen, die von „nicht sinnvoll einsetzbar“ bis „löst alle unsere Probleme“ reichen. Auf dieser Basis kann das Werkzeug wohl kaum den Anforderungen und Erwartungen gerecht werden. Wie so oft liegt auch hier die Wahrheit in der Mitte: Automatisiertes Testen ist auf vielen Ebenen eine sinnvolle Ergänzung zu manuellen Tests und in manchen Bereichen unumgänglich, wenn man sich beispielsweise Unit Tests oder Schnittstellentests vorstellt. Andere Felder erschließen sich dagegen nicht für die Testautomation, wie der Usability-Test zeigt. Bei dieser Darstellung wird bereits deutlich, dass wohl viel Toolerfahrung für eine professionelle Einführung und den erfolgreichen Betrieb von Testautomationswerkzeugen notwendig ist. Es wird auch kein „Megatesttool“ geben, das alle Teststufen und -disziplinen gleichermaßen bedienen kann. Es bedarf also einer Testtoollandschaft – gar auf Basis einer Toolplattform – um mittels Testautomation und manuellen Tests zu einer kompletten Aussage in Bezug auf alle Qualitätsmerkmale (ISO/IEC 25000 – vormals ISO/IEC 9126), wie in Abbildung 2 zu sehen, zu gelangen.

Abb.

Abb.

 

Dass hierbei Performance- und Lasttests fast immer vergessen werden, erwähnte ich bereits. Das Code-Quality-Management ist ein anderer Bereich der Testautomation, der heute innerhalb qualitätssichernder Prozesse nur in absoluten Ausnahmen bei Softwareunternehmen anzutreffen ist. Im Prinzip wird die ganze Codebasis automatisiert nach bestimmten Patterns abgesucht, die Risikopotenziale bezüglich aktueller oder zukünftiger Fehlerquellen repräsentieren. Vereinfacht kann man sagen, dass mit diesen Informationen mögliche Fehlerquellen (d. h. Fehlerpotenziale) vor ihrer tatsächlichen Existenz bereinigt werden können. Gerade hierbei lassen sich deutliche Kosteneinsparungspotenziale realisieren. Bei erfolgreicher Einführung entsprechender Tools, der notwendigen Engineering-Konzepte und seriöser Auswertung der Reportergebnisse inklusive Umsetzung daraus abzuleitender Handlungsempfehlungen lassen sich Entwicklungsbudgets mit Support und Pflegekosten um bis zu 20 Prozent reduzieren, ohne die Entwicklungsziele zu verändern. Im Vergleich zu den automatisierten Testprozessen über die Benutzeroberflächen der Anwendungen (oft auch als GUI-Testautomation bezeichnet) lassen sich automatisierte Tests auf der Codebasis bereits in ersten Entwicklungsphasen sinnvoll einsetzen. Bei Integration der Testautomation im Allgemeinen (wie des Code-Quality-Management- Ansatzes im Speziellen) lassen sich Qualitätsaussagen über das reifende Produkt wie auch über die aktuellen Entwicklungsprozesse selbst früher, umfassender und präziser bestimmen.

Fehlendes Testdaten- und Testumgebungsmanagement

Fast immer fehlt das Testdatenmanagement wie auch eine professionelle Verwaltung der verschiedenen Testumgebungen. Dabei haben Testdaten wie auch Testumgebungen entscheidenden Einfluss auf die ermittelten Testergebnisse. Falsche Konfigurationen der Systeme, eine ungenaue Beschreibung der primären wie sekundären Testdaten, Unmanaged Changes, instabile, teils nicht verfügbare (Teil-) Systeme, können so oft zu Fehlern führen, deren Ursachen nicht in mangelhaften Produktqualitäten liegt. In der Regel werden diese Punkte auch in den nachfolgenden Analysephasen erkannt. Jedoch kostet dies wichtige Zeit, die für das „Fixing“ der tatsächlichen Defekte fehlt oder die Behebungszeiten deutlich verlängert. Als Testmanager sollte man darauf achten, diese Risiken zu eliminieren. Ansonsten könnte den Testreports nicht mehr die notwendige Aufmerksamkeit geschenkt werden. Das wäre in Bezug auf die Qualitätsziele sicher kontraproduktiv.

Sollte das Verständnis für diese beiden Themen gereift sein, fehlen dann aber in der Regel die geeigneten Werkzeuge, die es erlauben, den Testanforderungen in diesem Bereich zu entsprechen. Es ist ratsam, zu folgenden Bereichen geeignete Systeme zu etablieren:

• Testdatenmanagement –Datengeneratoren –Datenanonymisieren/-austausch –Datenmodifizierung/-transformation –Datenanalyse • Testumgebungsmanagement –Change- und Configuration-Management — Systemadministration und Umgebungsüberwachung –Backup-/Restore-Prozesse

Oft wird dabei vergessen, dass Testumgebungen wie auch Testdaten nur für eine ganz bestimmte Produktversion gültig sind. Es mag richtig sein, dass vorgenannte Themen über mehrere Anwendungsversionen fast gleich sind. Doch genau dieser Aspekt führt letztlich zu Änderungen oder Erweiterungen im Bereich der Testdaten und -umgebungen. Also müssen diese Daten auch zusammen mit allen anderen Testartefakten, wie Testkonzepten, Testsuiten, Testfällen, Testskripten etc., versioniert verwaltet werden. Nur so lassen sich die korrekten Umgebungen und Daten für die betreffenden Tests bestimmen. Ferner können auf diese Weise Tests auch nach Jahren nochmals wiederholt werden. Deren Ergebnisse sind also reproduzierbar. Dabei hat sich aus den Erfahrungen heraus gezeigt, dass das Change Control bei klassisch aufgebauten Testumgebungen sehr aufwändig werden kann. Aus diesem Grunde setzt man gerne auf die Virtualisierung von Testumgebungen, wo dies möglich und sinnvoll ist. Auf dieser Basis lassen sich beide Themen vergleichsweise einfach realisieren.

Noch ein weiterer, wichtiger Punkt: Wer sagt einem, dass nach erfolgtem Aufsetzen der Umgebungen und dem Einspielen aller primären und sekundären Testdaten diese auch korrekt und vollständig verfügbar sind? Niemand. Dennoch finden vor den eigentlichen Tests selten entsprechende Stichproben zur Prüfung der Testumgebung und der bereitgestellten Daten statt, die diese Frage beantworten könnten. Gerade hier könnten Testautomationstools wertvolle Unterstützung bieten. Oftmals wären die Werkzeuge sowieso schon verfügbar, sodass die entsprechenden Prüfungen beispielsweise schnell und präzise auf den Datenbanken und Systemen ohne Personaleinsatz in der Nacht vor dem eigentlichen Testbeginn laufen könnten. Bei positivem Ergebnis kann am darauffolgenden Morgen der eigentliche Testlauf mit dem sicheren Gefühl starten, auf einer validen Umgebung zu testen.

Weiter mit: Teil 5

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 -