Softwaretests mit agilem Prozessframework

TestSPICE 3.0 – die erste Wahl für agile Testprozesse
Kommentare

Bislang finden sich in den gängigen agilen Entwicklungsmethoden nur ansatzweise Aussagen zu Tests – oft in Form von Akzeptanztests am Ende einer Iteration. Um professionelle Softwaretests wie auch eine gute Harmonisierung zwischen Test und agiler Entwicklung zu erreichen, bedarf es jedoch eines Testprozessframeworks mit agilen Elementen. TestSPICE in der Version 3.0 erfüllt als einziges Framework beide Anforderungen und ist damit die erste Wahl, wenn es um die Etablierung agiler Testprozesse innerhalb von Scrum, Software Kanban, Rapid Prototyping oder anderer agiler Methoden geht.

Das Ziel agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als es bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. In den letzten Jahren haben agile Entwicklungsmethoden in der Softwarebranche deutlich an Bedeutung gewonnen: VersionOne stellte beispielsweise in ihrer siebten jährlichen Umfrage zu agilen Methoden 2013 fest, dass bereits 84 Prozent aller Unternehmen agile Prozesse einsetzen. Doch wie sieht es neben der Entwicklung um die Softwaretests aus?

Der Begriff „Prozessframework“ im Zusammenhang mit TestSPICE ist nicht ganz richtig gewählt. TestSPICE ist in Wahrheit deutlich mehr als nur eine Ansammlung von Testprozessen. Vielmehr verbirgt sich dahinter ein Reifegradmodell oder Assessment-Modell, das den Anforderungen von SPICE beziehungsweise der Norm ISO/IEC 15504 folgt. Hierbei existieren für die Prozessreife (Infokasten: „Die Prozessreife gehört zu den erfolgskritischen Faktoren“) die Levels, wie in Abbildung 1 zu sehen.

Abb.1: Reifegradstufen der ISO/IEC 15504

So erklärt sich auch der Name TestSPICE, der den Bezug zur SPICE-Norm und den Fokus auf Testprozesse gleichermaßen herausstellen will. Die Reifegradstufen werden bei ISO/IEC 15504 als Capability Levels bezeichnet und drücken den Grad der Fähigkeiten des betreffenden Prozesses aus.

Die Prozessreife gehört zu den erfolgskritischen Faktoren

Die Bedeutung der Prozessreife oder Prozessfähigkeiten im Bereich der Softwareentwicklung wird häufig unterschätzt. Es gibt jedoch gute Gründe, um die Prozessreife weiterzuentwickeln:

• Reduzierung des Risikos unerwünschter Ergebnisse
• Erhöhung der Prozesssicherheit
• Verbesserung der Prozesstransparenz
• Verantwortung kann tatsächlich delegiert werden
• Ist die Basis für die Etablierung einer effektiven Prozesssteuerung
• Ist die Basis für die Realisierung von Vorhersagemodellen

TestSPICE unterstützt die nachhaltige, planvolle und gesteuerte Entwicklung der Prozessreife im Testumfeld.

Entstehungsgeschichte von TestSPICE

Im Rahmen der Qualitätssicherung liegt stets das Hauptaugenmerk auf der Bewertung von Ergebnissen. Das heißt, es wird in Form von Tests entschieden, ob ein Ergebnis den zuvor gesetzten Anforderungen entspricht oder nicht. Dies führt dann bekanntlich zu Testergebnissen, die passed oder failed sind. Diese Betrachtung hat den entscheidenden Nachteil, dass erst am Ende eines Entwicklungsschritts auf Basis der besagten Testergebnisse Korrekturen eingeleitet werden. Effektiver wäre es jedoch, wenn man diesen Fehler erst gar nicht produziert, sondern die Prozessqualität soweit verbesserte, dass Fehler nicht mehr entstehen können.

Ein zweiter Aspekt liegt in den methodischen Fehlern begründet, die auch heute im Rahmen der Softwarequalitätssicherung häufig auftreten (Infokasten: „Die zehn größten methodischen Fehler im Softwaretest“).

Die zehn größten methodischen Fehler im Softwaretest

Im Bereich des Softwaretests finden sich oft eine oder mehrere der nachfolgend aufgezählten Schwachpunkte in Bezug auf die Planung, Vorbereitung und Durchführung von Tests:

1. Kein Testmanagement
2. Unterschätzung von Komplexität und Vorbereitungsdauer
3. Fehlendes oder unzureichendes Testdatenmanagement
4. Fehlende Testautomatisierung
5. Unterschätzung des Know-how-Aspekts
6. Verzicht auf methodisches Vorgehen
7. Kein Tool-Einsatz oder Einsatz ungeeigneter Tools
8. Falsche Testfälle beziehungsweise unzureichende Testüberdeckung
9. Last- und Performancetests erst am Projektende
10. Unterschätzung der Folgen, die sich durch methodische Fehler einstellen

Der Bedarf, Testprozesse angemessen bewerten und verbessern zu können, wurde bereits ab Mitte der 1990er Jahre erkannt. So starteten zu dieser Zeit europaweit unterschiedliche Initiativen, die dieses Thema verfolgten. Mit zunehmender Verbreitung von SPICE kam der Bedarf nach einem zu ISO/IEC 15504 (SPICE) kompatiblen Testprozessmodell auf, das zunächst unter dem Namen SPICE4TEST im Jahr 2010 auf mehreren Konferenzen vorgestellt wurde.

In der Folge schlossen sich führende Beratungsunternehmen (Infokasten: „Prinzipieller Ablauf eines TestSPICE Assessments“) in Europa zur TestSPICE SIG (Special Interest Group) zusammen, um ein Assessment-Modell zu entwickeln, das sich im Testumfeld mit der Frage nach der Prozessqualität beschäftigt. Hierbei ermöglicht TestSPICE die fokussierte Verbesserung aller testrelevanten Themen und Prozesse, die in der gleichen Struktur wie bei den Entwicklungsprozessen vorliegen. Dies führte zur TestSPICE 1.0 (2010) und 2.0 (2011). Die Version 3.0, die unter anderem agile Komponenten enthält, wird voraussichtlich Ende 2013 verfügbar sein. Damit ist TestSPICE die erste Norm, die explizit auch agile Testprozesse als Pendant zu agilen Entwicklungsprozessen anbietet.

Prinzipieller Ablauf eines TestSPICE Assessments

Die TestSPICE-Norm ist inzwischen von der INTACS hinsichtlich der ISO/IEC-15504-Anforderungen verifiziert. Unternehmen können sich somit nach TestSPICE zertifizieren lassen, um ihre besondere Kompetenz im Bereich Softwarequalität und Testmanagement am Markt herauszustellen. Das Prozess-Assessment ist wie bei ISO/IEC 15504 organisiert, und die Prozessbewertung entspricht der ISO/IEC-15504-Bewertung. Das Assessment läuft in folgenden Stufen ab:

1. Preparation

a. Pre-Assessment/Briefing
b. Initialization
c. Assessment Team Identification
d. Collecting Supporting Material
e. Planning und Scheduling
f. Defining Confidentiality Agreement

2. Execution

a. Organizational Unit Briefing
b. SPU/Project Assessment
c. Data Collection
d. Data Validation
e. Process Attribute Rating
f. Interview Feedback Sessions

3. Reporting

a. Assessment Report Preparation
b. Final Report Preparation
c. On-Site Final Meeting/Presentation of the Assessment Results

Aufmacherbild: chili peppers von istockphoto / Urheberrecht: Knartz

[ header = Seite 2: Allgemeiner Überblick und Anwendung]

 

Allgemeiner Überblick und Anwendung

Die TestSPICE-Prozesse decken das gesamte Testbusiness ab. In TestSPICE 3.0 sind folgende Prozesskategorien vorgesehen:

•    Business Life Cycle Processes: In dieser Prozesskategorie sind alle Prozessgruppen zusammengefasst, die für die Vorbereitung und Durchführung von Tests benötigt werden. Die betreffenden Prozesse sind so gestaltet, dass sie auch von Managed Services einsetzbar sind.
o    Test Service Management verwaltet alle Testaufträge. Diese Prozessgruppe fokussiert auf die Beauftragung und Akzeptanz von Testaufträgen.
o    Testing definiert die Prozesse zur Spezifizierung, Implementierung und Wartung von Tests.
o    Test Process Management fokussiert auf die Planung, die Steuerung und das Berichtswesen im Testumfeld.
o    Regression and Reuse Test Engineering beinhaltet Prozesse für die Wiederverwendung von Tests und das Verwalten von Regressionstests.

•    Technical Life Cycle Processes: Hierin werden alle Prozesse zur Verwaltung und Pflege von Testumgebungen, Testdaten und automatisierten Testprozessen zusammengefasst.
o    Test Environment Management beinhaltet Prozesse für die Definition, die Planung, das Aufsetzen und den Support von Testumgebungen.
o    Test Data Management beschreibt die Prozesse für die Bereitstellung und Benutzung von Testdaten.
o    Test Automation beinhaltet Prozesse für die Definition, die Planung, das Aufsetzen und den Support von automatisierten Testprozessen.

Die TestSPICE-Prozessdefinitionen sind nach ISO/IEC 15504-2 beschrieben und beinhalten für jeden Prozess die Informationen aus Abbildung 2.

Abb. 2: Struktur einer Prozessbeschreibung

Zentrales Element ist die Prozess-ID mit dem Prozessbezeichner zur eindeutigen Identifizierung des betreffenden Prozesses. Die Prozess-ID steht in direkter Beziehung zu folgenden Informationselementen:

•    Prozessergebnisse (Process Deliverables)
•    Prozesszweck, das heißt: Was soll mit diesem Prozess erreicht werden? (Process Purpose)
•    Basisaktivitäten, das heißt die Beschreibung der wichtigsten Prozessschritte (Process Activities)
•    Ein- und Ausgangsschnittstellen mit der entsprechenden, beschriebenen Ergebnischarakteristik (Input/Output)

Im Rahmen der Prozessentwicklung wurde das TestSPICE RPM (Reference Process Model) erstellt, das – über seine verschiedenen Entwicklungsiterationen – die Erfahrungen mehrerer Tausend Experten aus dem Bereich Softwarequalität berücksichtigt. Das Referenzmodell, das analog zur ISO/IEC 15504 strukturiert ist, berücksichtigt die Anforderungen und Best Practices aus einer ganzen Reihe bekannter Normen und Modelle im Qualitätsumfeld (Infokasten: „TestSPICE“).

TestSPICE

Ein wichtiger Punkt bei der Entwicklung von Prozessmodellen ist die Berücksichtigung vieler Quasistandards, Normen und Modelle. Diese Eigenschaft unterstützt eine hohe Anwenderakzeptanz. TestSPICE berücksichtigt beispielsweise die folgenden Normen und Best Practices:

• IEEE 829
• ISO/IEC 15504
• ISO/IEC 29119
• ISTQB

TestSPICE kann in jeder Branche und Organisationsgröße angewendet werden. Das Referenzmodell ist so konzipiert, dass es im sequenzorientierten wie auch agilen Entwicklungsumfeld implementiert werden kann.

Da TestSPICE ein Assessment-Modell ist, enthält diese Norm neben dem bereits vorgestellten RPM auch das TestSPICE PAM (Process Assessment Model). Dieses Modell umfasst eine Reihe von Indikatoren für die Beurteilung der Prozessleistung und Prozessfähigkeit. Die besagten Indikatoren dienen als Grundlage zur Bewertung der aktuellen Prozessqualität beziehungsweise Prozessfähigkeit (Capability gemäß SPICE oder ISO/IEC 15504) im Testumfeld der betreffenden Organisation beziehungsweise des betreffenden Unternehmens.

Die TestSPICE PAM und RPM sind aufeinander abgestimmt, sodass eine gemeinsame Basis für die Durchführung des Prozess-Assessments auf einer harmonisierten Skala gegeben ist.

Das Prozess-Assessment-Modell definiert ein zweidimensionales Modell der Prozessfähigkeit. In einer Dimension werden die Prozesse definiert und in Verfahren eingeteilt. Innerhalb einer Prozesskategorie werden auf der ersten Ebene Gruppenprozesse strukturiert, auf einer zweiten Ebene nach der Art der Tätigkeit.

Die andere Dimension beschreibt die Prozessfähigkeit (Capability), die eine Reihe von Verfahrensattributen in Reifegradstufen gruppiert definiert. Die betreffenden Prozessattribute werden gemessen, und hieraus wird dann die besagte Prozessfähigkeit ermittelt.

Das Ziel von TestSPICE ist die stetige Verbesserung der Prozessleistung und der Prozessfähigkeit, basierend auf einem standardisierten Assessment-Ansatz, der den ISO/IEC-15504-Anforderungen folgt. TestSPICE stellt sich also stets die Frage nach dem „Was“: Das Assessment-Modell fokussiert auf Prozesse und bewertet deren Fähigkeiten, beziehungsweise den betreffenden Reifegrad.

Grundzüge agiler Softwareentwicklung

Ich möchte hier keine umfassende Einführung über agile Softwareentwicklung schreiben. Hierzu gibt es bereits eine ganze Reihe umfassender Artikel aus meiner Feder wie auch der anderer Autoren, die in diesem Magazin bereits erschienen sind. Als kleine Einstimmung nur so viel: Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lat. agilis: flink; beweglich) in der Softwareentwicklung. Je nach Kontext bezieht sich der Begriff auf Teilbereiche der Softwareentwicklung – wie im Fall von Agile Modeling – oder auf den gesamten Softwareentwicklungsprozess – exemplarisch sei Extreme Programming angeführt. Agile Softwareentwicklung versucht mit geringem bürokratischen Aufwand, wenigen Regeln und meist einem iterativen Vorgehen auszukommen. Ich spreche deshalb gerne von iterativen Prozessmodellen als Oberbegriff für die Entwicklungsmethoden wie Scrum, Software Kanban etc. (Infokasten: „Was versteht man unter agilen Prozessen?“) im Vergleich zu sequenzorientierten Prozessmodellen, wie zum Beispiel dem V-Modell.

Was versteht man unter agilen Prozessen?

Allen agilen Prozessen ist gemeinsam, dass sie sich zahlreicher Methoden bedienen, um die Aufwandskurve möglichst flach zu halten. Inzwischen gibt es eine Vielzahl von agilen Prozessen. Zu den bekanntesten Vertretern dieser Prozessgattung zählen unter anderem:

• Adaptive Software Development (ASD)
• Crystal
• Extreme Programming (XP)
• Feature-driven Development (FDD)
• Software Kanban
• Scrum
• Agiles Testen
• Behavior-driven Development (BDD)

Der Rational Unified Process (RUP) wird von vielen Vertretern agiler Methoden (viele von ihnen haben das Agile Manifest unterzeichnet) als nicht agiler, schwergewichtiger Prozess aufgefasst. Das ist allerdings umstritten beziehungsweise es wurde versucht, mit dem Agile Unified Process eine agile Variante von RUP zu entwickeln.

Diese iterativen Prozessmodelle zielen auf einen – im Vergleich zu sequenzorientieren Prozessmodellen – flexibleren und schlankeren Softwareentwicklungsprozess ab. Auf diese Weise wird mehr auf die zu erreichenden Ziele fokussiert und auf technische wie auch soziale Probleme bei der Softwareentwicklung eingegangen.

TestSPICE im agilen Umfeld

Bereits TestSPICE 2.0 bietet einige Ansätze, die auch im agilen Umfeld eingesetzt werden können. Im Rahmen der Entwicklung zur Version 3.0 wurde jedoch ganz bewusst das Prozessmodell um agile Elemente erweitert, um so die einfache Anwendung in iterativen gleichermaßen wie in sequenzorientierten Prozesswelten zu ermöglichen. In diesem Zusammenhang wurde das Frameworkdesign im Vergleich zu TestSPICE 2.0 gestreamlined und an den novellierten ISO/IEC-15504-Anforderungen von 2012 ausgerichtet. Insbesondere besagtes Streamlining unterstützt den Lean-Management-Gedanken, der in allen agilen Methoden einen der zentralen Ansätze bildet. In diesem Rahmen ist es bei agilen Prozessen wichtig, das Maß der notwendigen Prozessdetaillierung exakt an die aktuellen Anforderungen im Entwicklungsumfeld anzupassen. Hier liefert das TestSPICE Process Assessment Model die entsprechenden Informationen darüber, ob der aktuell ermittelte Capability Level zu den geprüften Testprozessen den besagten Anforderungen genügt. Entsprechend der Ergebnisse aus dem Assessment können die Testprozesse an den richtigen Stellen weiterentwickelt, beziehungsweise nachjustiert werden.

TestSPICE legt die entsprechenden Informationen (Input/Output) fest, die bezüglich des Betriebs von Testprozessen notwendig sind. Jedoch wird die Art und Weise der Informationsdarstellung nicht reglementiert. Somit können auch die Regelwerke agiler Methodenansätze im Bereich der Dokumentation berücksichtigt werden.

Fazit

TestSPICE bietet sowohl ein Prozessreferenzmodell als auch ein Prozess-Assessment-Modell für Testprozesse an, das die aktuellen Geschäftsanforderungen berücksichtigt. Diese Modelle sind branchenneutral entwickelt und können deshalb in jeder Branche gleichermaßen angewendet werden. Das zentrale Element ist natürlich das TestSPICE PAM. Hierüber lassen sich Prozesse über eine standardisierte Methode bewerten und weiterentwickeln. Die Prozessqualität wird in Capability Levels gemessen. Deren Kanon wie auch Wertmaß orientieren sich an SPICE beziehungsweise ISO/IEC 15504. Unternehmen, die bereits die SPICE-Norm einsetzen, können einfach die TestSPICE-Norm in ihr Qualitätssystem integrieren, da Kompatibilitätsprobleme nicht zu befürchten sind. Weiterführende Informationen zu TestSPICE finden sich im Internet unter http://testspice.de.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -