Stefan Schmerler - Softwaretest in der Praxis

Bewertung

Dennoch muss man sich bei der Bewertung dieses Ansatzes vor Augen führen, dass einige Prämissen und Abschätzungen getroffen wurden. Für ein »besseres Bauchgefühl« sollte er jedoch allemal genügen.

2.3 Zusammenfassung

▶Der Reifegrad von Software kann nicht über eine Metrik gemessen werden, man muss sich anderweitig behelfen. Eine Möglichkeit ist der Einsatz von Zuverlässigkeitsmodellen.

▶Ein Zuverlässigkeitsmodell ermöglicht Aussagen über das in Zukunft zu erwartende Ausfallverhalten von Software auf Basis bislang beobachteter Ausfälle.

▶Mit Fehlerbaumanalysen kann das statistische Ausfallverhalten komplexer Systeme aus dem Verhalten ihrer Module modelliert werden. Dabei wird transparent, welche Auswirkungen einzelne Fehlerursachen/-ereignisse auf das Gesamtausfallverhalten haben.

▶Markov-Modelle ermöglichen die Beschreibung des statistischen Ausfallverhaltens reparierbarer Systeme sowie die Ableitung wichtiger Kenngrößen.

▶Hardware besitzt ein zeitabhängiges Ausfallverhalten (»Badewannenkurve«), Software folgt einer zeitunabhängigen, exponentialverteilten Ausfallfunktion. Unter dieser Annahme lassen sich wichtige Kenngrößen für Software ableiten.

▶Das Zuverlässigkeitsmodell von Musa ermöglicht unter bestimmten Prämissen quantitative Aussagen über noch zu erbringende Testaufwände, um einen bestimmten Reifegrad beim Ausfallverhalten zu erzielen.

3 Testprozess und Testphasen

Testprozesse in der Softwareentwicklung sind in der Regel gut strukturierte Prozesse, die sich insbesondere in größeren Unternehmen über viele Bereiche und Personen erstrecken. Mit den Jahren wurden eine Reihe von Entwicklungsmodellen und Testprozessen für Software vorgestellt sowie verschiedene Methoden für deren Beurteilung. Die wesentlichen Ansätze werden in diesem Kapitel vorgestellt, zudem die typischen Phasen, in welche sich ein typischer Testprozess gliedert.

Das Entwicklungsmodell

bestimmt den Testprozess.

Testprozesse sind stets abhängig von den zugrunde liegenden Entwicklungsmodellen. Auf die einzelnen Testphasen wird im weiteren Verlauf dieses Kapitels noch ausführlich eingegangen.

Test Process Improvement und

Test Management Approach

Erwähnenswert im Hinblick auf die Etablierung und Verbesserung von Testprozessen in Unternehmen wäre hier u. a. die strukturierte Methode Test Process Improvement [11], mit deren Hilfe die Reife von Testprozessen analysiert und bewertet werden kann. Ergänzend steht mit TMap (Test Management Approach) ein Modell für das Testen und die Qualitätssicherung von Software zur Verfügung, in dem die wesentlichen Aspekte, das Umfeld und die Vorgehensweise beim Test strukturiert beschrieben werden. Somit ist TMap spezieller als andere Prozessmodelle oder das V-Modell, die den gesamten Prozess der Softwareentwicklung betrachten. Es zielt auf die Strukturierung von Tests ab, weniger auf die Optimierung des Testprozesses.

Ein Testprozess wird beschrieben

als strukturiertes Phasenmodell.

Pol, Koomen und Spillner beschreiben in [2] einen Softwaretestprozess anhand eines Phasenmodells. Sie strukturieren dieses Phasenmodell in die Phasen Testvorbereitung, Testspezifikation, Testdurchführung und -auswertung sowie Testabschluss. Darüber hinaus sieht der Testprozess die Rahmenfunktionen Planung und Verwaltung vor. Das Vorgehen ist generisch, d. h. es wird – jeweils nach Erfordernis – auf unterschiedlichen Ebenen angewendet, auf das Gesamtprojekt, auf jede Teststufe und letztlich auch auf einzelne Testobjekte und Testfälle.

TAKT

Testaktivitäten werden hierbei rollenspezifisch zu sog. Testfunktionen zusammengefasst: Testen, Testmanagement, methodische Unterstützung, technische Unterstützung, funktionale Unterstützung, Verwaltung, Koordination und Beratung, Anwendungsintegrator und beim Einsatz von Testautomatisierung auch TAKT (Testen, Automatisierung, Kenntnisse, Tools), genauer TAKT-Architekt und TAKT-Ingenieur. Diese Funktionen bzw. Rollen haben Schwerpunkte in bestimmten Testphasen und können im Projekt selbst eingerichtet sein oder über spezialisierte Organisationseinheiten einbezogen werden.

International Software Testing

Qualifications Board (ISTQB)

Bei anderen Autoren oder Institutionen finden sich zum Teil andere Gruppierungen und andere Bezeichnungen, die aber inhaltlich meist mehr oder weniger auf dasselbe hinauslaufen. So wird bei ISTQB (International Software Testing Qualifications Board) der fundamentale Testprozess mit den folgenden Hauptaktivitäten definiert [12]: Testplanung und -steuerung, Testanalyse und -entwurf, Testrealisierung und -durchführung, Bewertung von Testende-Kriterien und Bericht sowie Abschluss der Testaktivitäten.

die Normen ISO/IEC/IEEE 29119

Im September 2013 wurde die Norm ISO/IEC/IEEE 29119 Software Testing veröffentlicht, die international erstmals viele ältere, nationale Normen des Softwaretestens, wie z. B. die IEEE 829, zusammenfasst und ersetzt. Die Normreihe ISO/IEC 25000 ergänzt dies um Aspekte des Softwareengineerings als Leitfaden für die gemeinsamen Qualitätskriterien und ersetzt die Norm ISO/IEC 9126.

3.1 Wasserfallmodell nach Boehm

sequenzielles Entwicklungsmodell

Das Wasserfallmodell [13] kann als Pionier der definierten Softwareentwicklungsprozesse angesehen werden. In der heutigen industriellen Softwareentwicklung kaum noch von Bedeutung, war es seinerzeit Wegbereiter und Vorstufe heutiger strukturierter Entwicklungsprozesse. Es handelt sich um ein sequenzielles Entwicklungsmodell, das durch einen linearen, sequenziellen Ablauf der Entwicklungsaktivitäten charakterisiert ist.

Abb. 3-1: Wasserfallmodell nach Boehm

Am Ende jeder Phase liegt ein fertiggestelltes Ergebnis vor – in der Regel sind dies Dokumente, z. B. eine Architekturspezifikation. Da die Ergebnisse jeweils Eingaben für darauffolgende Aktivitäten bilden, muss jede Phase vollständig abgeschlossen sein, bevor die nächste Phase begonnen werden kann.

Bewertung des Wasserfallmodells

Durch die strenge Phasensequenz werden die Anwender nur in der ersten Phase, der Anforderungserfassung, in die Entwicklung miteinbezogen. Damit lassen sich Anforderungen während der Entwicklung kaum ändern. Dies ist eine erhebliche, realitätsfremde Einschränkung. Auch Analyse-, Planungs- und Entwicklungsfehler werden erst spät bemerkt. Hier bedürfte es einer Rückkopplung über mehrere Phasen.

Nachteil der Dokumentenorientierung

Da beim Wasserfallmodell der Projektablauf auf die Erstellung von Dokumenten ausgerichtet ist, werden Projektrisiken erst spät oder gar nicht erkannt. Risiken sind aber gerade im Wasserfallmodell eine kritische Größe, da sich bei Eintreten eines Risikos in einer Phase alle folgenden Schritte und somit das gesamte Projekt verzögern könnten.

3.2 Das klassische V-Modell

Links: Entwicklung,

Rechts: Integration

Im Gegensatz zum Wasserfallmodell ist das heute gängige V-Modell [14] deutlich strukturierter und besser angepasst an die Anforderungen moderner Softwareentwicklung. Auch hier haben wir ein sequenzielles Entwicklungsmodell vor uns. Die Grundidee des allgemeinen V-Modells ist, dass Entwicklungs- und Testarbeiten gleichberechtigte Tätigkeiten sind. Im linken Ast befinden sich die immer detaillierter werdenden Entwicklungsschritte, im rechten Ast die Integrations- und Testtätigkeiten auf der jeweiligen Ebene.