Grundlagen des Softwaretests

Softwaretests kommen in vielen Fachgebieten und Branchen zum Einsatz. Bei jedem Projekt stehen Sie vor einer neuen Aufgabe. Bevor Sie mit dem Testen beginnen, müssen Sie die Sicht des Kunden und das Fachgebiet verstehen. Je nach Projekt können auch unterschiedliche Testmethoden erforderlich sein. Ein solides Verständnis der Grundlagen ist daher die erste Voraussetzung für den Erfolg.

Warum sind Softwaretests notwendig?

Bei der Entwicklung können unbeabsichtigt Fehler, Defekte oder Bugs entstehen. Moderne Software ist komplex. Missverständnisse können deshalb zu falscher Logik und fehlerhaftem Code führen.

Durch Tests lassen sich Fehler erkennen und beheben. So verbessert sich die Softwarequalität. Ziel ist es, fehlerfreie Anwendungen zu entwickeln und auszuliefern. Entwickelt ein Unternehmen Software im Auftrag eines Kunden, bestimmen gesetzliche, vertragliche und branchenspezifische Anforderungen die Arbeit. Ein qualitätsbewusstes Unternehmen setzt Tests als bewährte Praxis ein.

Wie viel Testaufwand ausreicht, lässt sich schwer bestimmen. Sorgfältige Planung und gut entworfene Testfälle ermöglichen eine Auslieferung in hoher Qualität.

Wer führt die Softwaretests durch?

Wer sollte die Software testen? Entwickler prüfen ihren Code vor der Übergabe oft mehrmals. Trotzdem können Defekte bestehen bleiben, weil es schwer ist, eigene Fehler zu erkennen.

Tester betrachten die Software unvoreingenommen aus Kundensicht und konzentrieren sich auf Spezifikationen und Anforderungen. So können sie Probleme aufdecken, die bei der Entwicklung übersehen wurden. Tests sollten deshalb stets von unabhängigen Testern durchgeführt werden.

Getrennte Entwicklungs- und Testteams haben auch Nachteile. Es kann zu Kommunikationslücken kommen. Wenn Entwickler die Verantwortung für Qualität allein beim Testteam sehen, vernachlässigen sie unter Umständen die Codeprüfung. Das erhöht den Aufwand für das Testteam.

Manchmal testen Entwickler gegenseitig ihre Arbeit. Das nennt man Buddy Testing. Jedes Entwicklungsteam sollte fest zuständige Tester haben. Ein Projekt verfügt in der Regel über mindestens ein eigenes Testteam. Manche Unternehmen haben getrennte Teams für Gebrauchstauglichkeit, Leistung, Sicherheit und andere Testarten. Andere vergeben die Arbeit an spezialisierte Unternehmen, unabhängige Tester oder Berater.

Was muss tatsächlich getestet werden?

Machen Sie sich mit den Projektanforderungen und dem realen Einsatzumfeld der Software vertraut. So können Sie entscheiden, was getestet werden muss, und eine passende Teststrategie entwickeln.

Diagramm in voller Größe öffnen ↗

Was muss tatsächlich getestet werden?

Wann wird die Software getestet?

Wer früh mit dem Testen beginnt, hilft dem Entwicklungsteam, termingerecht fertig zu werden, und spart Zeit, Geld und Aufwand. Defekte, die erst spät entdeckt werden, können teuer zu beheben sein. Teilen Sie die Entwicklung in Phasen ein und testen Sie die Ergebnisse jeder Phase, bevor Sie fortfahren. Das fördert eine pünktliche Auslieferung und bessere Ergebnisse. Auch die Integration wird einfacher, wenn jedes Modul zuvor einzeln anhand seiner Spezifikation getestet wurde.

Wie oft müssen wir testen?

Testen Sie parallel zur Entwicklung und suchen Sie bereits in den frühen Phasen nach möglichst vielen Defekten. Wie häufig Sie testen, hängt von der benötigten Qualität ab. Frühe Erkenntnisse erlauben Änderungen am Entwurf, solange sie einfacher und günstiger sind. Später werden größere Änderungen aufwendig und teuer.

Diagramm in voller Größe öffnen ↗

Wie oft müssen wir testen?

Was sind Standards für Softwaretests?

Teststandards sind für Kunden und Hersteller wichtig. Kunden investieren in Software und möchten darauf vertrauen können, dass die Qualität ihre Kaufentscheidung rechtfertigt.

Seriöse Unternehmen steuern die Produktqualität anhand öffentlich anerkannter Standards. Deren Einhaltung schafft Sicherheit hinsichtlich des Produkts und seines erwarteten Verhaltens. So können Kunden darauf vertrauen, Software mit dem gewünschten Qualitätsstandard zu erwerben.

Herstellern helfen Standards, das Endprodukt zu verbessern. Hat ein Unternehmen Standards ausgewählt, kann es diese Grundlage für spätere Projekte wiederverwenden. Viele Teststandards helfen, Qualität zu bewerten und die Wirksamkeit von Tests zu steigern. Kein einzelner Standard deckt jedoch alle Aspekte des Softwaretests ab.

Sowohl Standards, die Tests als Teil eines breiteren Anforderungskatalogs behandeln, als auch spezielle Teststandards können Ihnen bei der Arbeit Orientierung geben.

Was ist die Testbarkeit von Software?

Die Testbarkeit beschreibt, wie leicht sich ein Softwaresystem testen lässt. Bewerten Sie sie frühzeitig, um die erforderlichen Testressourcen abzuschätzen. Tests decken Defekte auf. Die Testbarkeit hilft einzuschätzen, wo Defekte verborgen bleiben könnten. Hohe Testbarkeit erleichtert das Testen, während niedrige Testbarkeit mehr Aufwand verursacht. Berücksichtigen Sie die folgenden Faktoren.

1. Steuerbarkeit bedeutet, dass sich der Testprozess kontrollieren und damit optimieren lässt.
2. Beobachtbarkeit setzt voraus, dass das Verhalten und die Faktoren, die das Ergebnis beeinflussen, sichtbar und damit prüfbar sind.
3. Verfügbarkeit bedeutet, dass Sie für den Test auf das System zugreifen können.
4. Einfachheit ergibt sich aus einem einheitlichen Entwurf, klaren Funktionen und einfachen Programmierpraktiken. Das senkt die Testkomplexität. Komplexere Software ist schwieriger zu testen.
5. Stabilität erleichtert den Test. Häufige Entwurfsänderungen können ihn stören.
6. Verfügbare Informationen über die Software beeinflussen stark, wie effizient Sie testen können.

Behalten Sie diese Zusammenhänge zur Testbarkeit im Blick.

1. Höhere Testbarkeit ermöglicht bessere Tests und trägt zu weniger Defekten bei.
2. Geringere Testbarkeit kann die Testqualität beeinträchtigen und dazu führen, dass mehr Defekte im System verbleiben.

Verifizierung und Validierung von Software

Verifizierung und Validierung bezeichnen unterschiedliche Arten der Prüfung. Bei der Validierung geht es darum, ob Sie das richtige System entwickeln. Erfüllt es die Anforderungen des Kunden?

Die Verifizierung prüft, ob Sie das System richtig entwickeln. Im Mittelpunkt stehen die technische Qualität und die Einhaltung der geforderten Standards.

Bei der Validierung wird geprüft, ob die Spezifikationen den Kundenbedürfnissen entsprechen. Die Verifizierung prüft, ob die Entwicklung die Softwarequalitätsstandards und technischen Praktiken der Organisation einhält.

Diagramm in voller Größe öffnen ↗

Verifizierung und Validierung von Software

Manche Ansätze sehen die Verifizierung in jeder Entwicklungsphase vor, konzentrieren die Validierung aber auf Anfang und Ende, also auf die Anforderungsanalyse und die Abnahmetests. Das ist in der Praxis schwer umzusetzen. Zu Beginn lassen sich kaum alle Kundenanforderungen erfassen. Anforderungen ändern sich oft nach dem Entwicklungsstart, und auch Entwicklungsteams können Änderungen verlangen. Führen Sie daher sowohl Verifizierung als auch Validierung während der gesamten Entwicklung durch.

Tester setzen Verifizierung und Validierung, kurz V&V, ein, um unterschiedliche Aspekte der Softwarequalität zu untersuchen.

Softwaretest und Debugging

Tests und Debugging haben unterschiedliche Ziele. Tests decken Defekte auf. Debugging setzt nach dem Fund eines Defekts an und beseitigt dessen Ursache.

Sobald Tester einen Defekt melden, suchen Entwickler nach der Grundursache. Sie untersuchen die betroffenen Module, finden das Problem im Code und beheben es. Beim Debugging wird die Ursache Schritt für Schritt ermittelt und beseitigt.

Klären Sie mögliche Ursachen eines Defekts, bevor Sie ihn beheben. Debugging ohne ausreichende Informationen kann in einem verbundenen Modul einen neuen Defekt auslösen. Vermeiden Sie planloses Ausprobieren. Geben Sie das korrigierte Modul anschließend an den Tester zurück, damit es gründlich getestet wird.

1. Tests decken Defekte auf. Debugging findet und behebt ihre Ursachen.
2. Tests sind ein wichtiger Bestandteil der Entwicklung. Debugging reagiert auf die dabei entdeckten Defekte.
3. Tests beginnen früh in der Entwicklung. Debugging beginnt, sobald Defekte gemeldet werden.
4. Zu den Tests zählen Verifizierung und Validierung (V&V). Debugging untersucht und behebt die Ursache eines Defekts.

Was ist ein Defekt?

Ein Defekt ist eine Abweichung von der Softwareanforderungsspezifikation. Defekte können im Code oder im Entwurf auftreten und bei der Programmausführung falsche Ausgaben verursachen.

1. Code mit vielen Defekten wird oft als fehlerhaft oder „buggy“ bezeichnet.
2. Ein Fehlerbericht beschreibt die Art eines Defekts.
3. Fehlerverfolgungstools erfassen und verfolgen Defekte in einem System.
4. Bei einer Testtechnik werden absichtlich Defekte in den Code eingebaut. Anschließend wird beobachtet, ob das System wie erwartet auf diese Probleme reagiert.

Diagramm in voller Größe öffnen ↗

Was ist ein Defekt?

Was sind Schweregrad und Priorität?

Der Schweregrad beschreibt, wie sich ein Defekt auf das System auswirkt. Die folgenden Kategorien ordnen diese Auswirkungen ein.

1. Kritisch bedeutet, dass die Anwendung aufgrund eines Systemausfalls oder beschädigter Daten nicht ordnungsgemäß funktioniert. Der Benutzer kann nicht fortfahren.
2. Schwerwiegend bedeutet, dass das System ausfallen kann. Der Benutzer erreicht das Ergebnis aber ohne zusätzliche Schulung auf einem anderen Weg. Solche Defekte sind weniger gravierend als kritische Defekte.
3. Mittel bedeutet, dass das System weiterläuft, aber falsche oder widersprüchliche Ausgaben erzeugt.
4. Gering bedeutet, dass der Defekt weder einen Systemausfall verursacht noch die Gebrauchstauglichkeit beeinträchtigt und leicht zu beheben ist.
5. Kosmetisch bedeutet, dass der Defekt das Erscheinungsbild des Systems beeinträchtigt.

Ein Fehlerbericht hält neben dem Schweregrad auch die Priorität fest. Die Priorität gibt dem Entwicklungsteam die Reihenfolge vor, in der Defekte behoben werden sollen.

1. Bei niedriger Priorität beheben Sie den Defekt nach Defekten mit höherer Priorität. Sofortiges Eingreifen ist nicht nötig.
2. Bei mittlerer Priorität beheben Sie den Defekt zeitnah, sobald die Defekte mit höherer Priorität abgearbeitet sind.
3. Bei hoher Priorität kümmern Sie sich sofort um den Defekt und beheben ihn so schnell wie möglich.

Entscheiden Sie anhand des gemeldeten Schweregrads und der Priorität gemeinsam, wie dringend Sie handeln müssen.

Diagramm in voller Größe öffnen ↗

Was sind Schweregrad und Priorität?

1. Bei hoher Priorität und hohem Schweregrad hindert ein Problem in einer grundlegenden Funktion den Benutzer daran, das System zu verwenden. Beheben Sie es sofort.
2. Bei hoher Priorität und geringem Schweregrad beeinträchtigen ein falsch geschriebener Firmenname oder ein fehlerhaftes Logo die Funktion kaum. Eine sofortige Korrektur ist dennoch nötig.
3. Bei hohem Schweregrad und niedriger Priorität betrifft ein erheblicher Defekt ein Modul, das der Benutzer nicht sofort benötigt. Die Behebung kann warten.
4. Bei niedriger Priorität und geringem Schweregrad werden kosmetische Defekte, die die Funktion nicht beeinträchtigen, in der Regel zuletzt behoben.