Suchen

Qualitätssicherung in der Software-Entwicklung Softwaretests mit Augenmaß

| Autor / Redakteur: Volker Brase * / Florian Karlstetter

Was in den Gründerzeiten der Programmierung eher die Ausnahme war, ist heute fester und unerläßlicher Bestandteil eines jeden Softwareprojekts: das Testen. Entweder ist man, wie namhafte große Softwarehersteller, in der glücklichen Situation, neue Produkte in Alpha- und Betaversionen bei der breiten Masse der Anwender reifen zu lassen, oder – und das ist eher der Fall – man muß einen Teil des Entwicklungsbudgets für Tests einplanen.

Firma zum Thema

Volker Brase, Software-Architekt bei dem Informatikunternehmen infolab wirft einen praxisgeprägten Blick auf die heute mehr oder weniger üblichen Testmethoden bei der Software-Entwicklung.
Volker Brase, Software-Architekt bei dem Informatikunternehmen infolab wirft einen praxisgeprägten Blick auf die heute mehr oder weniger üblichen Testmethoden bei der Software-Entwicklung.
( Archiv: Vogel Business Media )

Dieser Artikel wirft einen praxisgeprägten Blick auf die heute mehr oder weniger üblichen Testmethoden und schließt mit einer durchaus subjektiv gemeinten Bewertung der manchmal geradezu dogmatisch vertretenen Teststrategien.

Eine Faustregel gilt nach sechzig Jahren Softwareentwicklung unverändert: Der billigste Fehler ist der, der gar nicht erst entsteht. Ihr steht die nicht minder wahre Behauptung entgegen: „Wer nicht arbeitet, macht keine Fehler.“ Folglich ist es mit vertretbarem Aufwand kaum möglich, fehlerfreie Software zu erstellen. Allerdings sollten ein hohes Maß an Fehlerrobustheit und ein definiertes Verhalten im Fehlerfall selbstverständlich sein.

Damit verlassen wir das allgemeine Feld der Qualitätssicherung und wenden uns dem Thema „Testen“ zu. Dieses umfaßt zwei Tätigkeiten: zum einen das Ausführen von programmierten Funktionen und zum anderen das Vergleichen des Ist-Ergebnisses mit dem Soll-Ergebnis.

Automatisierte Testverfahren

Gleichgültig, ob als Regressions-, Integrations-, Leistungs-, oder XY-Test, ganz gleich, ob ich die korrekte Funktion bestätigen oder Fehler provozieren will: Die grundsätzliche Vorgehensweise ist immer die gleiche. Und ich stehe vor der Wahl, Tests manuell oder automatisch auszuführen. Die heutigen technischen Möglichkeiten, der hohe Kostendruck, verbunden mit der Forderung nach Reproduzierbarkeit, und nicht zuletzt die Tatsache, daß der Mensch selbst die größte Fehlerquelle ist: Das alles spricht eindeutig für die automatische, also programmgesteuerte oder -unterstützte Testdurchführung. Aber auch das Testprogramm muß programmiert werden, und da beißt sich die Katze schnell in den Schwanz.

Für die Entscheidung „automatisch oder manuell“ gilt die einfache Regel: so viel automatisch wie möglich, so wenig manuell wie nötig. Hier gilt dieselbe Faustformel wie für andere IT-Projekte: Achtzig Prozent der Tests lassen sich mit vernünftigem Aufwand automatisieren; jede Steigerung um weitere fünf Prozentpunkte verdoppelt den Aufwand für die Automatisierung.

Heute sind sogenannte „Unit-Tests“ üblich. Diese werden meist vom Programmierer selbst erstellt und unterstützen den Modul- oder Funktionstest. Sie lassen sich automatisch ausführen, soweit keine Interaktionen des Anwenders erforderlich sind (und sei es nur das Bestätigen einer Fehlermeldung), verletzen aber das Vier-Augen-Prinzip und haben nicht die „destruktive Energie“ eines externen Testers.

Programmgesteuertes Testen

Daher ist der Test über die Benutzerschnittstelle – der User-Interface-Test, kurz: UI-Test – als Ersatz oder Ergänzung für den Black-Box-Test innerhalb der Integrationsphase am besten geeignet. Hierbei wird der Bedienablauf programmgesteuert ausgeführt; im Idealfall geht das so weit, daß das UI-Testprogramm jeden einzelnen Tastendruck und jede Mausbewegung genauso ausführt, wie ein Anwender das tun würde.

Ein großes Problemfeld beim programmgesteuerten Testen ist die Identifizierung der einzelnen Objekte auf dem Bildschirm. Wo uns Menschen ein Blick genügt – denn dafür ist die Benutzer-Schnittstelle ja gemacht – hat das Testprogramm oft eine sehr unscharfe Brille. Moderne Entwicklungsumgebungen – Software Development Kits, kurz: SDKs – mit zum Beispiel WPF (Windows Presentation Foundation) bieten zwar Identifizierungsmöglichkeiten wie die „Automation-Id“. In der Praxis hat das aber Grenzen; besonders dann, wenn Objekte, wie gerade bei der objektorientierten Programmierung üblich, mehrmals in verschiedenen Ausprägungen auf dem Monitor zu finden sind.

weiter mit: Grundlagen der automatischen oder programmgesteuerten Testdurchführung

(ID:2051069)