Stefan Schmerler - Softwaretest in der Praxis

Testziel ist es, Auftraggebern Hilfestellung

bei der Software-Abnahme zu geben.

Der Abnahmetest adressiert die Kunden-/Auftraggeber-Situation bei der Entwicklung einer fremdbeauftragten Software. Ziel ist es, mithilfe von Tests des finalen Produkts einem Auftraggeber eine Entscheidungsgrundlage hinsichtlich Akzeptanz oder Ablehnung des Gewerks zu geben. Ein Abnahmetest aus Sicht des Kunden oder Benutzers wird deshalb auch als Akzeptanztest bezeichnet. Hierbei werden in der Regel häufige Anwendungsfälle abgeprüft, stichprobenartig auch Robustheitstests gegen typische Fehlersituationen oder Fehlbedienungen. Neben der funktionalen Absicherung werden bei Abnahmetests auch interne Qualitätsmerkmale wie die Einhaltung von Codierrichtlinien und Standards überprüft.

typische Arten des Abnahmetests

Typische Formen des Abnahmetests sind also ein Test auf vertragliche Akzeptanz, auf Benutzerakzeptanz (Benutzerabnahmetest) sowie ein Feldtest (Alpha- und Beta-Test).

Testbasis

Als Testbasis können alle Dokumente und Informationen dienen, die das Testobjekt aus Anwendersicht beschreiben. Dies können Anwender-/Systemanforderungen und Lastenhefte sein sowie Geschäftsprozesse und Risikoanalysen, aber auch einzuhaltende Gesetze und regulatorische Vorschriften. Bei letzterem spricht man von regulatorischem Abnahmetest.

Akzeptanztestfälle müssen

vom Kunden erstellt werden.

Es ist besonders wichtig, dass der Kunde die Akzeptanztestfälle selbst erstellt, sie zumindest aber einem intensiven Review unterzieht, denn der Softwarehersteller könnte die vertraglich vereinbarten Akzeptanzkriterien missverstanden haben.

nicht auf den Akzeptanztest

warten: Prototypen einsetzen!

Wenn allerdings beim Akzeptanztest gravierende Probleme zutage treten, ist es in Softwareprojekten für grundlegende Änderungen meistens zu spät. Aus diesem Grund ist es stark zu empfehlen, schon in frühen Projektphasen Prototypen von repräsentativ ausgewählten Vertretern der späteren Anwender begutachten zu lassen.

Abb. 3-14: Steckbrief Abnahmetest in der klassischen SW-Entwicklung

3.4.7 Produktionstest

Auch fehlerfreie Produzierbarkeit

und Inbetriebnahme sicherstellen

Beim Produktionstest geht es nicht mehr um die funktionale Korrektheit des Systems – diese wurde in den vorherigen Teststufen bereits nachgewiesen – sondern um den Nachweis der fehlerfreien Produzierbarkeit, also den Ausschluss von Produktionsfehlern des fertig entwickelten und abgesicherten Produkts. Hier gilt der Grundsatz, dass die beste Entwicklung vergebens ist, wenn das Produkt, aus welchen Gründen auch immer, nicht fehlerfrei und in ausreichender Qualität produziert werden kann. Für klassische Bürosoftware besitzt dieser Test keine Relevanz, bei eingebetteten oder mechatronischen Systemen ist das aber durchaus der Fall, denn auch eine Parametrierung und werksseitige Inbetriebnahme des fertigen Produkts kann durch softwareseitige Fehler verhindert werden.

Abb. 3-15: Steckbrief Produktionstest

Spezifika in der Automobiltechnik

In der Automobiltechnik bedeutet dies in Bezug auf elektronische Steuergeräte neben grundlegenden Funktionstests auch die richtige Kontaktierung von Steuergeräten, Aktorik, Sensorik und Leitungssatz. Dies wird während der Produktion stichprobenhaft anhand spezifischer Prüfroutinen durch Produktionstests abgesichert. Der Produktionstest steht in der Regel unter besonderen Randbedingungen, da aufgrund des Serienproduktionsbetriebs nur wenig Zeit zur Verfügung steht, um auf aufgetretene Fehler zu reagieren.

3.4.8 Feldtest

Als produktionsnachgelagerte Teststufen sind Feldtest und Regressionstest zu nennen.

Alpha-Test inhouse,

Beta-Test im Feld

Beim Feldtest wird die Software in verschiedenen Betriebsumgebungen getestet. Auch bei noch so intensivem System- und Produkttest ist es einem Hersteller kaum möglich, alle oder auch nur einen Großteil der möglichen Produktivumgebungen beim Test zu berücksichtigen. Die Produktivumgebung bzw. Nutzungsart hat durchaus Einfluss auf das abzusichernde Systemverhalten und muss daher im Testprozess Berücksichtigung finden. Softwarehäuser versenden daher im Rahmen einer sogenannten Beta-Testphase Vorabversionen der Software an einen ausgewählten Kundenkreis, um solch einen Feldtest durchzuführen. Natürlich werden auch eigene Mitarbeiter für diese Absicherung herangezogen – in diesem Fall spricht man von Alpha-Test.

3.4.9 Regressionstest und nachgelagerte Teststufen

Unter einem Regressionstest ist die erneute Absicherung eines bereits getesteten Systems nach dessen Modifikation unter Nutzung bereits vorhandener Testfälle zu verstehen. Diese Änderungen können bei der Weiterentwicklung oder auch in der Wartungsphase, also nach Verkaufsstart, im normalen Lebenszyklus der Software auftreten.

Testziele des Regres­sionstests

Testziel ist der Nachweis, dass nach der Fehlerbeseitigung zum einen der Fehler auch tatsächlich behoben ist – man spricht hier von der Verifikation der Fehlerbehebung. Zum anderen ist zu prüfen, ob durch die Fehlerbeseitigung möglicherweise neue Defects in das SUT eingebracht wurden oder durch den jetzt beseitigten Fehler bislang maskierte Defects ihre Fehlerwirkung zu zeigen beginnen. Hält man sich vor Augen, dass erfahrungsgemäß 5 % Neufehler bei einer Fehlerabstellung eingebracht werden, erkennt man die Wichtigkeit des Regressionstests.

Regressionstests sind aufwendig und

werden aufgrund vermeintlicher Redun-

danz oft nicht stringent durchgeführt.

Im Auge zu behalten ist in der Praxis aber immer auch der Effizienzaspekt. Regressionstests sind teuer! Die Frage ist: Was muss aufgrund einer Änderung erneut getestet werden und was nicht? Schließlich wurde ja oftmals »nur eine Zeile Code geändert«. Die Realität ist: Viele Änderungen im Code haben das Potenzial zu Seiteneffekten. Selbst wenn kein neuer Fehler eingebracht und kein maskierter Defect freigelegt wurde, ändert sich das Systemverhalten (die Änderung hatte letztlich ja einen Grund) und das neue Verhalten könnte Probleme aufwerfen, die vorher noch nicht absehbar waren. In vielen Fällen ist also beim Regressionstest von einem vollständigen Testzyklus auszugehen – so bitter das ist. In der Praxis ist daher zu empfehlen, eine Reihe von Fehlern in einer gemeinsamen Bugfix-Release zu beheben, sodass der Regressionstestaufwand in einem besseren Verhältnis dazu steht. Wenn die Ressourcen für einen vollständigen Regressionstest tatsächlich nicht zur Verfügung stehen, sollten folgende Mindestregeln eingehalten werden:

▶Wiederholung aller Tests, die eine Fehlerwirkung gezeigt haben, deren Ursache der korrigierte Fehlerzustand war. Dies wird ohnehin für die Verifikation der Fehlerbeseitigung benötigt,

▶Test aller Komponenten, die korrigiert oder geändert wurden,

▶Test aller Komponenten, die neu eingefügt wurden.

auf was am ehesten verzichten?

Auf was kann man am ehesten verzichten? Es besteht die Möglichkeit, im Testplan folgende Einschränkungen vorzunehmen:

▶Wiederholung nur derjenigen Tests aus dem Testplan, die eine genügend hohe Priorität haben,

▶bei funktionalen Tests Verzicht auf gewisse Varianten, d. h. Sonderfälle der Software,

▶Einschränkung der Tests auf bestimmte Konfigurationen wie z. B. andere Sprachen,

▶Einschränkung der Tests auf bestimmte Teilsysteme oder Teststufen.