Software-Tests

4 min 2 Abschnitte
Was du nach diesem Konzept kannst 3
  1. Du bist in der Lage, grundlegende Arten von Softwaretests (z. B. Unit-, Integrations- und Systemtests) zu differenzieren ,

    indem der jeweilige Umfang, Zweck und typische Zeitpunkt im Entwicklungsprozess voneinander abgegrenzt werden.

  2. Du bist in der Lage, die Vorteile von frühzeitigem Testen im Softwareentwicklungszyklus zu erklären ,

    indem der Zusammenhang zwischen dem Zeitpunkt der Fehlerentdeckung und den Fehlerbehebungskosten (Fehlerkostenkurve) erläutert und die präventive Wirkung früher Tests auf die Projektgesamtkosten und -dauer aufgezeigt wird.

  3. Du bist in der Lage, die Konzepte Verifikation und Validierung im Kontext der Softwarequalitätssicherung zu differenzieren ,

    indem die Kernfragen 'Bauen wir das System richtig?' (Verifikation) und 'Bauen wir das richtige System?' (Validierung) anhand von konkreten Beispielen aus dem Softwaretest unterschieden und ihre Bedeutung für die Erfüllung von Anforderungen erläutert werden.

Warum ist Softwaretesten unverzichtbar?

Die Fehlerkostenkurve: Warum frühes Testen Geld spart

Stell dir vor, du entwickelst eine komplexe Software. Wenn du einen Logikfehler in einer Schleife direkt beim Schreiben des Codes bemerkst, korrigierst du ihn in wenigen Sekunden – die Kosten gehen gegen null. Bemerkst du denselben Fehler erst, nachdem die Software an die Kundschaft ausgeliefert wurde, wird es teuer.

Dieses Phänomen beschreibt die Fehlerkostenkurve. Sie visualisiert, dass die Kosten für die Fehlerbehebung exponentiell steigen, je weiter ein Projekt fortgeschritten ist. Ein Fehler im Live-System erfordert oft das Umschreiben von Code, Datenbankmigrationen und den Einsatz des Supports für verärgerte Nutzer:innen. Frühzeitiges Testen wirkt hier präventiv: Es deckt Probleme auf, wenn sie noch günstig zu beheben sind, und senkt so die Projektgesamtkosten und die Entwicklungsdauer drastisch.

Verifikation: Bauen wir das System richtig?

In der Qualitätssicherung unterscheiden wir zwei zentrale Fragestellungen. Die erste lautet: "Bauen wir das System richtig?" Diesen Vorgang nennen wir Verifikation.

Bei der Verifikation prüfst du die rein technische Korrektheit. Du kontrollierst, ob die Software exakt das tut, was in den technischen Spezifikationen und Anforderungen definiert wurde.

  • Beispiel: Du entwickelst eine Login-Funktion. Die Verifikation prüft, ob das eingegebene Passwort korrekt verschlüsselt und fehlerfrei mit dem Eintrag in der Datenbank abgeglichen wird. Es geht hierbei ausschließlich um die korrekte technische Umsetzung der Vorgaben.

Validierung: Bauen wir das richtige System?

Die zweite zentrale Fragestellung lautet: "Bauen wir das richtige System?" Diesen Vorgang nennen wir Validierung.

Hierbei verlässt du die rein technische Ebene und nimmst die Perspektive der Endbenutzer:innen ein. Du überprüfst, ob die entwickelte Software den tatsächlichen Zweck erfüllt und im Alltag nützlich ist.

  • Beispiel: Bei derselben Login-Funktion prüft die Validierung, ob der Login-Prozess für die Anwender:innen intuitiv und schnell ist. Selbst wenn der Code technisch perfekt ist (erfolgreiche Verifikation), ist das System nutzlos, wenn die Benutzer:innen den Login-Button nicht finden oder der Prozess zu umständlich ist (fehlgeschlagene Validierung).
Software-Tests — dec-software-engineering-quality-assurance-the-basics-of-testing-software-testing_page1.svg

Welche grundlegenden Testarten gibt es?

Unit-Tests: Das Fundament prüfen

Da du bereits weißt, dass eine gut geschriebene Funktion nach dem Single-Responsibility-Prinzip (SRP) nur eine einzige Aufgabe haben sollte, lässt sich diese isolierte Aufgabe perfekt testen. Das ist die Rolle der Unit-Tests (Modultests).

  • Umfang: Sie testen die kleinsten isolierbaren Bausteine deines Codes, meist einzelne Funktionen oder Methoden.
  • Zweck: Sie stellen sicher, dass die interne Logik (wie Verzweigungen oder Schleifen) fehlerfrei funktioniert. Du übergibst definierte Argumente und prüfst, ob der erwartete Rückgabewert erscheint.
  • Zeitpunkt: Sie werden von den Entwickler:innen selbst direkt während der Implementierungsphase geschrieben und bei jeder Code-Änderung automatisiert ausgeführt.

Integrationstests: Das Zusammenspiel kontrollieren

Selbst wenn zwei Funktionen für sich allein (im Unit-Test) perfekt funktionieren, heißt das nicht, dass sie auch fehlerfrei miteinander kommunizieren. Hier kommen Integrationstests ins Spiel.

  • Umfang: Sie testen die Schnittstellen und den Datenaustausch zwischen zwei oder mehr bereits getesteten Modulen.
  • Zweck: Sie decken Fehler auf, die erst durch das Zusammenwirken entstehen – zum Beispiel, wenn ein Modul Daten in einem Dictionary-Format sendet, das ein anderes Modul nicht verarbeiten kann.
  • Zeitpunkt: Sie werden durchgeführt, sobald einzelne Komponenten im Entwicklungsprozess zu größeren Subsystemen zusammengefügt werden.

Systemtests: Das große Ganze bewerten

Wenn alle Bausteine integriert sind, muss die Software als komplettes Produkt bewertet werden. Dies geschieht durch Systemtests.

  • Umfang: Getestet wird das vollständig integrierte Gesamtsystem in einer Umgebung, die der späteren Produktivumgebung (Live-System) so nah wie möglich kommt.
  • Zweck: Sie überprüfen, ob alle funktionalen und nicht-funktionalen Anforderungen (wie Performance, Sicherheit und Benutzerfreundlichkeit) aus der Perspektive der Anwender:innen erfüllt sind.
  • Zeitpunkt: Sie finden am Ende der Entwicklung statt, bevor die Software an die Kund:innen ausgeliefert wird. Ein Beispiel ist der komplette Durchlauf in einem Webshop: Von der Registrierung über die Produktsuche bis hin zur erfolgreichen Bezahlung.
Software-Tests — dec-software-engineering-quality-assurance-the-basics-of-testing-software-testing_page2.svg

Teste dein Wissen

Du erklärst der Projektleitung, warum das Testteam früh eingebunden wird. Wie entwickeln sich die Fehlerbehebungskosten laut Fehlerkostenkurve im Projektverlauf?

Bereit für mehr?

Thema verstanden?

Teste dein Wissen interaktiv in unserer App. 7 Tage kostenlos, dann nur 5 € im Monat.