QS - Was? Wann? Wer?
Wer die Begriffe „Qualitätssicherung“ und „Softwareprojekte“ hört, denkt unmittelbar an das Testen von ausführbaren Programmen. Das ist zwar grundsätzlich nicht falsch, aber es ist eine sehr eingeschränkte Betrachtungsweise. Ein fehlerfreies Programm ist noch lange nicht qualitativ hochwertig. Demnach umfasst die Qualitätssicherung auch mehr als nur das reine Testen von Software.
Statisches Testen
Am Anfang eines Softwareprojektes steht meist ein Doku ment in Form einer Anforderungsspezifikation (Lastenheft). Darin werden jene Wünsche aufgeführt, die der Auftraggeber an das zukünftige Softwareprodukt hat. Wird ein Lastenheft als Instrument für eine Ausschreibung verwendet, so werden die potentiellen Dienstleister mit einem Pflichtenheft antworten.
Softwarearchitekten, Projektleiter und Entwickler sind jenemRollen, die in der Regel mit der Analyse des Lastenhefts und der Erstellung eines Pflichtenhefts assoziiert werden. Aber schon hier sollte bereits die Qualitätssicherung in Form des statischen Testens einsetzen. Denn Qualität kann nicht erst nach der Fertigstellung der Software „hineingetestet“ werden.
Welche Fragestellungen sollten berücksichtigt werden?
Welche Technik setzen wir ein? Was für Ressourcen brauchen wir? Welche Werkzeuge sollen wir nutzen? Welche Entwicklungsmethode(n) wenden wir an? Das sind typische Fragen, die sich Softwarearchitekten und -entwickler stellen und beantworten müssen. Der Qualitätsmanager untersucht das vorliegende Dokument hingegen nach anderen Schwerpunkten. Er stellt sich Fragen wie: Gibt es Widersprüche? Sind die Anforderungen eindeutig spezifiziert? Bleiben Fragen unbeantwortet? Haben alle Beteiligten (Kunde, Entwicklung und Test) dasselbe Verständnis wird dieselbe „Sprache“ gesprochen?
Insbesondere die Interpretierbarkeit von Aussagen und damit verbundene Fehlannahmen können im späteren Verlauf des Projektes sehr teuer werden. Aus rein wirtschaftlichen Gründen ist es daher sehr zu empfehlen, noch weit vor dem ersten produzierten Quellcode mit der Qualitätssicherung zu beginnen. Was hier exemplarisch am Lastenheft beschrieben wird, setzt sich im späteren Projektverlauf konsequent fort. Mit jedem Change Request sollte erneutstatisch getestet werden.
Review - das Instrument für statische Tests
Im IEEE1028-Standard wird zwischen zwei Review- Gruppen unterschieden. Reviews auf die Produkte und Teilprodukte (Gruppe 1) sowie Reviews auf den Projektablauf oder Entwicklungsprozess (Gruppe 2). Wir betrachten hier nur die erste Gruppe mit folgenden Review-Arten:
- Technischer Review
- Walkthrough
- Inspection
- Informeller Review
Ohne im Einzelnen auf die unterschiedlichen Review-Arten einzugehen, können diese prinzipiell auf alle Arbeitsergebnisse im Softwareentwicklungsprozess (z.B. Anforderungsspezifikationen, Designspezifikationen, Testspezifikationen oder Softwaredokumentation) angewendet werden und bieten damit die Möglichkeit, sehr früh in dem Softwareentwicklungsprozess qualitätssichernde Maßnahmen durch zuführen.
Wer ist beteiligt und wie geht man vor?
Teilnehmer eines solchen Review sind mindestens einer der Verfasser (oft Kundenvertreter), ein Gutachter (z.B. Projektleiter), ein Protokollant (z.B. Testmanager) und ein Moderator (z.B. Softwarearchitekt).
Sinnvollerweise kommt dabei eine standardisierte Checkliste oder Fragenliste zum Einsatz. Die Punkte dieser Liste hat der Moderator zur Vorbereitung von den Teilnehmern im Vorfeld eingefordert. Mit Hilfe eines vollständigen Review können bereits vorab 60 - 90 % der potentiellen Fehler gefunden werden, die sich unmittelbar auf den Erfolg des Projektes auswirken können.
Dynamisches Testen
Beim dynamischen Testen wird zwischen White-Box- und Black-Box-Tests unterschieden. Zunächst soll an dieser Stelle der Black-Box-Test näher betrachtet werden. In diesem wird das laufende (Teil-)Programm/System getestet. Black-Box-Tests werden zu verschiedenen Zeitpunkten und mit unterschiedlichem Fokus bzw. Aufgaben im Projektverlauf ausgeführt. Dieser Zusammenhang wird im klassischen V-Modell in der Abbildung 1 gut illustriert.
 |
Abb. 1: Allgemeines V-Modell, Quelle [2]
Anforderungsdefinition - das Maß aller Dinge
Im Rahmen der Anforderungsdefinition, welche zu Beginn des Projektes formuliert wird (u.a. im Lastenheft), werden die Leistungen und Anforderungen des Kunden an das zu künftige Softwaresystem aufgeführt. Diese Definition steht am Ende des Projektes dem Abnahmetest gegenüber. Der Abnahmetest ist somit ein Test gegen den Vertrag, der zwischen dem Auftraggeber und dem Softwarelieferanten besteht. Hier wird final festgestellt, ob das ausgelieferte Softwareprodukt den Erwartungen des Kunden entspricht. Tests dieser Art werden entweder durch Kundenvertreter oder vom Testteam unter der Regie des Kunden durchgeführt.
Funktionaler Systementwurf
Im funktionalen Systementwurf werden die Anforderungen des Systems mit genauerem Detailierungsgrad in Funktionen und Dialogabläufen abgebildet. Dem gegenüber steht vor der Abnahme der Systemtest. Sämtliche Teilsysteme des Gesamtproduktes werden jetzt verbunden und als Gesamtheit getestet. Dies ist gewissermaßen dieGeneralprobe des Softwarelieferanten vor dem Abnahmetest.
Technischer Systementwurf
Im technischen Systementwurf wird die technische Realisierung des Systems vorbereitet. Schnittstellen werden definiert und das Gesamtsystem in sinnvolle Teilsysteme untergliedert. Diese werden idealerweise getrennt entwickelt und getestet. Dem technischen Systementwurf steht der Integrationstest gegenüber. Auf dieser Teststufe werden demnach einzelne Softwaremodule zu autarken Teilsystemen verbunden, welche unabhängig voneinander getestet werden.
Komponententest
Die Heimat der Entwickler sind die sogenannten Kompo nententests (oft auch als Unit-Tests oder Modul-Tests bezeichnet). Hier werden die kleinsten Softwareeinheiten (Funktionen/Prozeduren/Methoden) getestet und hinsichtlich eines korrekten Verhaltens geprüft. Auf der Entwurfsseite steht diesen Tests die Komponentenspezifikation gegenüber. Darin werden im Detail die einzelnen Softwaremodule definiert (Schnittstellen, Ein- und Ausgabe, etc.). Obwohl der Entwickler Zugriff auf den Code hat, handelt es sich hierbei um einen Black-Box-Text, da lediglich das Verhalten der Software zur Laufzeit geprüft wird.
Code-Analyse mit dem White-Box-Test
Dem Black-Box-Test gegenüber steht der sogenannte White-Box-Test. Darin wird der Quellcode als solcher analysiert und nicht etwa ausgeführt. In der sogenannten statischen Code-Analyse werden werkzeugunterstützt Metriken erstellt, mit deren Hilfe eine Aussage über die Qualität des Quellcodes gemacht werden kann. Hinzu kommen erfahrungsbasierte Betrachtungen. So kann u.a. geschätzt werden, wieviele Fehler im Verhältnis zu den vorhanden Zeilen Code zu erwarten sind. Mit Hilfe der werkzeugunterstützten Code-Analyse sind u.a. folgende Prüfungen durchgeführbar:
- Anweisungsüberdeckung
- Zweigüberdeckung
- Test der Bedingungen
- Pfadüberdeckung
Die statische Code-Analyse kann in Entwicklungsumge bungen während des Entwicklungsprozesses eingesetzt werden. Sie sollte aber auf jeden Fall Bestandteil einer Continous-Integration-Umgebung sein.
Interessanterweise sagt die Literatur nicht viel darüber aus, zu welchem Zeitpunkt und von welchem Personenkreis White-Box-Tests durchgeführt werden sollten. Da es sich jedoch um Tätigkeiten der Code-Analyse handelt, liegt es nahe, diese begleitend zur Programmierung durchzuführen. Idealerweise liegt die Verantwortung bei einem erfahrenen Entwickler, Softwarearchitekten oder auch technikaffinen Tester.
Wer macht was?
Bisher wurden nur die unterschiedlichen Teststufen betrachtet. Lediglich bei den Komponententests und der Code-Analyse wurde erwähnt, wer diese durchführt. Doch wie verhält es sich mit den anderen Tesstufen? Bei der Qualitätssicherung werden grundsätzlich fünf verschiedene Testrollen unterschieden:
- Testmanager
Der Testmanager plant und steuert den Test, hat Verant wortung für sein Testteam und berichtet den Teststatus an das Projektmanagement.
- Testdesigner
Der Testdesigner entwirft die Testfälle. Ebenso ist er ein Experte für Testmethoden und die Testspezifikation im Softwaretest.
- Testautomatisierer
Der Testautomatisierer ist ein Experte für die Automatisierung von Testfällen. Das heißt, er entwickelt Testfälle, die automatisch und werkzeugunterstützt ablaufen können.
- Testadministrator
Ein Experte für die Installation und den Betrieb der Testumgebung ist der Testadministrator. Seine Kenntnisse sind vergleichbar mit denen eines Systemadministrators.
- Tester
Der Tester ist für die Testdurchführung zuständig ist, erstellt Fehlerberichte und meldet Probleme.
In der Praxis kommt es regelmäßig vor, dass einige der oben genannten Rollen in Personalunion wahrgenommen werden. Dies ist auch legitim, da eine scharfe Trennung meist gar nicht möglich oder sinnvoll ist. Mit Ausnahme des Komponententests (hier testen die Entwickler) sind die oben genannten Rollen in allen Teststufen anzutreffen.
Warum es nicht sinnvoll ist, dass Entwickler im System-, Integrations- oder Abnahmetest mitwirken, erläutern wir übrigens im zweiten Teil dieser Reihe.
Begrifflichkeiten
Wie bereits beschrieben, werden White-Box-Tests wie auch Black-Box-Tests dem dynamischen Testen zugeordnet. So ist es zumindest im ISTQB-Standard definiert, nach welchem auch hierzulande zertifiziert wird. Schlägt man allerdings unter dem Stichwort „Statisches Software-Testverfahren“ in Wikipedia nach, so wird man feststellen, dass dort die Tätigkeit der Code-Analyse, da sie nicht zur Laufzeit durchgeführt wird, als statisches Testen angesehen wird. An dieser Stelle existieren somit verschiedene Betrachtungsweisen.
Das in Abbildung 1 abgebildete allgemeine V-Modell ist ebenso in verschiedenen Ausprägungen zu finden. Im Rahmen dieses Artikels wurde der von ISTQB gelehrte Standard zugrundegelegt.
Nicht selten kann auch das Verständnis der beschriebenen Begrifflichkeiten im Kundenumfeld unterschiedlich sein. So wird beispielsweise der Integrationstest gerne als Systemtest verstanden und der Systemtest als solcher gar nicht mehr erwähnt. Um Missverständnissen vorzubeugen, sollte man sich daher zuvor genauestens mit der Testkultur des Auftraggebers vertraut machen.
Unter anderem in Telekommunikationsunternehmen findet man häufig den Begriff des End-to-End-Tests. Im Prinzip ist damit ein produktionsnaher Systemtest gemeint, bei dem von einem Ende (z.B. Anwender) bis zum anderen Ende (z.B. Datenbank) geprüft wird, ob sich das System im Produktionsumfeld korrekt verhalten würde.
End-to-End-Tests werden auch gerne als Ersatz für Ab nahmetests genutzt. Erwartungsgemäß sollten dabei kaum noch Fehler auftreten, da diese bereits in den vorangestellten Teststufen entdeckt worden sein sollten. Doch die Praxis beweist auch hier regelmäßig etwas anderes.
Eine ebenfalls gängige Tätigkeit in der Qualitätssicherung ist der sogenannte Regressionstest. Damit ist nach einer Softwaremodifikation das wiederholte Testen von Bestandsfunktionalitäten gemeint.
Im Regressionstest wird somit sichergestellt, dass Softwareänderungen oder -erweiterungen keine Bestandsfunktionalität beeinträchtigen. Regressionstests werden mit jedem neuen Software-Release (Wartungsphase) durchgeführt und haben die Eigenschaft quantitativ zuzunehmen. Hier muss also mit jedem neuen Release eine Priorisierung bzw. Gewichtung stattfinden.
Fazit
In diesem ersten Artikel der neuen Reihe wurde verstärkt auf die Testobjekte „Dokumente“ und „Software“ geschaut. Doch auch die permanente Bewertung des Entwicklungs- und Qualitätssicherungsprozesses selbst ist eine qualitätsfördernde Maßnahme.
Da jede Kundensituation individuell ist, muss Bewährtes aus Projekt A nicht auch das Richtige für Projekt B sein. Hier gilt es aufmerksam zu hinterfragen und anzupassen. Qualität erzielt man nicht allein durch das Ausführen von Testfällen. Einen echten Sinn macht die Qualitätssicherung nur dann, wenn sie als ein ganzheitlicher Prozess betrachtet und dieser an die sich ständig ändernden Bedingungen anpasst wird.
Um die gebräuchlichen Begrifflichkeiten im Testumfeld vorzustellen, wurde hier das allgemeine V-Modell als Vorgangsmethode gewählt. Heutzutage wird aber zunehmend agil entwickelt (z.B. nach Scrum). In agilen Softwareprojekten muss man sich jedoch anderes in Sachen Qualitätssicherung aufstellen als in klassischen Projekten. Auf diesen Aspekt werden wir in folgenden Artikeln näher eingehen.
Bildnachweis: www.pixabay.com | test testing optical magnifier search http www | PublicDomainPictures
