Zwar kann ein Softwaresystem erst nach der Fertigstellung ganzheitlich auf die Erfüllung der geforderten Anforderungen getestet werden, jedoch ist das Risiko, im Softwareprozess mit der Qualitätssicherung bis zum Ende der Implementierung zu warten, zu hoch. Daher wird Qualitätssicherung im Software Engineering begleitend zu allen anderen Aktivitäten durchgeführt.
Ganz allgemein wird der Begriff Softwarequalität in der DIN-ISO-Norm 9126 folgendermaßen definiert:
"Softwarequalität ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen."
Demnach müsste man eine Software dahingehend überprüfen, ob das, was ausgeliefert wurde, die vorher festgelegten Anforderungen (Erfordernisse) erfüllt. Es wird die Wichtigkeit einer Spezifikation deutlich: Laut DIN kann über die Qualität von Software nur auf Basis der Spezifikation ("festgelegte Erfordernisse") entschieden werden. In der Praxis zeigt sich allerdings, dass die wahrgenommene Qualität einer Software in erster Linie dadurch bestimmt wird, ob der Kunde feststellt, dass die Software seine tatsächlichen Anforderungen erfüllt. Da viele Anforderungen oft erst während der Softwareentwicklung erkannt werden, muss im Hinblick auf die Kundenzufriedenheit kontinuierlich dafür gesorgt werden, dass die Menge der spezifizierten Anforderungen auch die Menge der tatsächlichen Anforderungen enthält.
Neben der Bestimmung der Qualität eines Softwaresystems als Ganzes können auch für die im Verlauf der Softwareentwicklung erzeugten Artefakte (Softwaremodelle, Anforderungen, Architekturen, Dokumente, Softwarekomponenten) die Qualität bestimmt werden.
Unter dem Begriff Qualitätsmanagement (QM) werden alle organisierten Maßnahmen zusammengefasst, die der Verbesserung der Qualität von Produkten, Prozessen oder Leistungen jeglicher Art dienen. Da es im Software Engineering zu risikoreich ist, mit der Bestimmung der Softwarequalität bis zum Abschluss der Implementierung zu warten, wird bereits während des Entwicklungsprozesses mit der Bestimmung der Qualität bereits erzeugter Softwarefragmente begonnen. Doch nicht nur der erzeugte Programmcode ist beim Softwarequalitätsmanagement zu berücksichtigen. Weil die Implementierung direkt von den in den Aktivitäten Requirements Engineering, Spezifikation und Architektur getroffenen Vorgaben und Entscheidungen abhängig ist, pflanzen sich Fehler der Spezifikation oder der Architekturdefinition unmittelbar auf die Implementierung fort. Daher müssen diese Artefakte ebenfalls beim Qualitätsmanagement im Software Engineering miteinbezogen werden.
Typische Aktivitäten im Qualitätsmanagement sind:
Grundsätzlich lässt sich Qualitätsmanagement in die Bereiche konstruktives und analytisches Qualitätsmanagement aufteilen.
Beim konstruktiven Qualitätsmanagement werden a priori (also vor der Erstellung) alle Qualitätseigenschaften für Produkte oder Prozesse definiert, um Fehler während der Softwareentwicklung zu vermeiden und die Qualität der erstellten Artefakte zu gewährleisten beziehungsweise zu erhöhen. Die Maßnahmen zum konstruktiven Qualitätsmanagement umfassen:
Beim analytischen Qualitätsmanagement werden ex post (also nach der Erstellung) Maßnahmen zur Prüfung und Bewertung des aktuellen Qualitätsniveaus der Prüfobjekte durchgeführt, um Fehler systematisch aufzuspüren und ihre Ausmaße bestimmen zu können. Dabei lassen sich statische und dynamische Testverfahren unterscheiden.
Statische Tests
Im Rahmen eines Reviews oder Audits wird der Prüfling analysiert, begutachtet, untersucht, die dabei
gewonnenen Informationen zusammengetragen, gegebenenfalls in Metriken oder Kennzahlen verdichtet und schließlich ausgewertet.
Dynamische Tests
Der Prüfling (ein Stück Software) wird mit konkreten Eingabewerten ausgeführt und das Ergebnis
der Ausführung bewertet.
Durch vorausschauendes konstruktives Qualitätsmanagement kann der Aufwand im analytischen Qualitätsmanagement reduziert werden.
Grundsätzlich können alle im Software Engineering erstellten Artefakte auf die Einhaltung von Qualitätsanforderungen getestet werden. Das bedeutet, dass neben dem ...
Beim Testen des erzeugten Softwaresystems wird zwischen sogenannten Teststufen unterschieden. Wie oben bereits erwähnt, ist es zu
risikoreich, mit der Qualitätssicherung von Software bis zum Abschluss der Implementierung zu warten. Bevor jedoch das System als
Ganzes in seiner Einsatzumgebung getestet werden kann, wird in der industriellen Softwareentwicklung mit Testaktivitäten begonnen,
sobald die ersten Softwareartefakte erzeugt wurden. Die folgende Abbildung zeigt eine schematische Übersicht über die
verschiedenen Teststufen im Software Engineering.
Komponententest (auch: Modultest, Unit Test)
Um die Implementierung eines Softwaresystems durch mehrere Softwareentwickler zu
ermöglichen, wird das System in seine logischen Bestandteile (auch: Komponenten, Module, Klassen, Bausteine) zerlegt. Jede Komponente
wird separat implementiert und nach Fertigstellung in das System eingebracht (auch: integriert). Während bzw. nach der Fertigstellung
einer Softwarekomponente kann diese bereits auf Einhaltung von spezifizierten Vorgaben überprüft werden. Das isolierte
Prüfen von einzelnen Softwarebestandteilen wird Komponententest genannt.
Beispiele: Prämienberechnung: Berechnung von Versicherungsprämien abhängig von den gewählten Leistungen; Warenkorb: Berechnung der Gesamtsumme aller Artikel; Adresskomponente: Erzeugen der richtigen Anschrifft für den Briefverkehr aus den Kundendaten.
Integrationstest
Sobald mindestens zwei Softwarekomponenten fertiggestellt wurden, können sie zu einem System
zusammengeführt, das heißt integriert werden. Während beziehungsweise nach der Integration wird in Integrationstests das
Zusammenspiel von Gruppen von Komponenten getestet. Die Integrationstests prüfen, ob die Komponenten so zusammenarbeiten, wie es in
der Spezifikation beschrieben wurde. Insbesondere bei komplexen Softwaresystemen mit sehr vielen Komponenten sind nicht alle Komponenten
zur gleichen Zeit fertig. In diesen Fällen werden fehlende Komponenten durch sogenannte Treiber und Dummies simuliert, damit bereits
mit dem Test begonnen werden kann. Folgende Abbildung illustriert das Zusammenspiel von Komponenten, Treibern und Dummies.
Als Treiber werden dabei Softwarefragmente bezeichnet, die das Aufrufen anderer Komponenten simulieren. Dummies hingegen simulieren Komponenten, die durch andere Komponenten aufgerufen werden.
Insbesondere technische Schnittstellen zu externen Systemen werden im Integrationstest durch Dummies und Treiber simuliert. Denn erst das fertige Softwaresystem kann an externe Systeme angeschlossen werden, das Zusammenspiel der Schnittstellen muss jedoch bereits vorher getestet werden.
Beispiele: Integration einer Adresskomponente mit einem externen Dienst zur Adressvalidierung; Integration von PDF-Drucker und dem Warenkorb zum Erzeugen der Rechnung; Integration vom Bestandssystem mit einem Inkasso-System zum automatischen Versand von Rechnungen.
Systemtest
Nach Abschluss der Entwicklungsarbeiten und der Integration aller Softwarebestandteile zu einem fertigen System
wird mit dem sogenannten Systemtest das System als Ganzes getestet. Ziel des Systemtests ist die Überprüfung, ob das System
als Ganzes die spezifizierten Anforderungen erfüllt. Dabei werden neben den fachlichen Anforderungen auch die spezifizierten
Qualitätseigenschaften getestet. Unter anderem wird im Verlauf des Systemtests durch gezielte Stress- und Lasttests auch
das Systemverhalten unter besonders anspruchsvollen Situationen (z. B. viele Nutzer und große Datenmengen, über kurze periodische
oder lange Zeiträume hinweg) überprüft. Der Systemtest wird in der Regel ohne die Beteiligung des Auftraggebers
durchgeführt und ist für die Organisation, die das System erstellt, der letzte Test, bevor die Software übergeben wird.
Eine große Herausforderung beim Systemtest ist die möglichst originalgetreue Nachbildung der Produktivumgebung des Kunden. Dazu zählen
Wobei insbesondere die Bereitstellung von originalgetreuen Datensätzen, die gleichzeitig den Vorschriften des Datenschutzes entsprechen, ein großes und oft unlösbares Problem darstellt.
Beispiele: Online-Shop: Test eines neuen Shop-Systems nach vollständiger Ablösung des Altsystems; Schadenssystem: Ablösung eines Schadenssystems einer Kompositversicherung.
Abnahmetest (auch: Akzeptanztest)
Die letzte Teststufe ist der Abnahmetest, bei dem das fertige System bereits beim
Auftraggeber installiert ist und unter den tatsächlichen Betriebsbedingungen getestet wird. Beim Abnahmetest wird geprüft, ob
das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist. Der Auftraggeber führt den Abnahmetest selber
durch oder wird in der Durchführung miteinbezogen. Von der Art der Durchführung ist der Abnahmetest eine spezielle Art des
Systemtests, eine trennscharfe Abgrenzung ist dabei in der Regel schwierig. Der wichtigste Unterschied gegenüber dem Systemtest ist
jedoch die Durchführung durch eine andere Organisation als die, die das System entwickelt hat. Ein erfolgreicher Abnahmetest ist
häufig die vertraglich vereinbarte Voraussetzung für die Rechnungsstellung.