Software-Tests

Warum ist Softwaretesten unverzichtbar?

Fehler frühzeitig erkennen und Kosten sparen

Stell dir vor, du baust ein komplexes LEGO-Modell. Es ist viel einfacher und günstiger, einen falsch gesetzten Stein sofort zu korrigieren, als wenn du erst am Ende merkst, dass ein ganzes Bauteil schief ist und du vieles wieder auseinandernehmen musst. Ähnlich ist es beim Softwaretesten: Je später ein Fehler im Softwareentwicklungszyklus entdeckt wird, desto teurer und aufwendiger wird seine Behebung. Diese Beziehung wird oft durch die Fehlerkostenkurve veranschaulicht, die zeigt, dass die Kosten für die Fehlerbehebung exponentiell ansteigen, je weiter das Projekt fortgeschritten ist. Frühes und kontinuierliches Testen hat eine starke präventive Wirkung: Es hilft, Fehler bereits in der Design- oder frühen Implementierungsphase zu finden. Dort können sie mit deutlich geringerem Aufwand korrigiert werden, was nicht nur direkte Reparaturkosten spart, sondern auch Folgefehler verhindert, die Projektgesamtkosten senkt und die Entwicklungsdauer verkürzt.

Verifikation vs. Validierung: Das Richtige richtig bauen?

Im Kontext der Softwarequalitätssicherung sind Verifikation und Validierung zwei zentrale, aber unterschiedliche Konzepte:

• Verifikation beantwortet die Frage: "Bauen wir das System richtig?" Hierbei wird überprüft, ob die Software die zuvor definierten Spezifikationen, Anforderungen und Designvorgaben korrekt umsetzt. Es geht also um die technische Korrektheit der Implementierung. Ein Beispiel: Bei der Entwicklung einer Online-Banking-Anwendung würde die Verifikation prüfen, ob eine Überweisungsfunktion die eingegebenen Beträge korrekt von einem Konto abzieht und dem anderen gutschreibt, genau wie in den technischen Spezifikationen festgelegt.
• Validierung beantwortet die Frage: "Bauen wir das richtige System?" Hierbei wird überprüft, ob die entwickelte Software die tatsächlichen Bedürfnisse und Erwartungen der Endbenutzer:innen erfüllt und für den vorgesehenen Zweck geeignet ist. Es geht also darum, ob das System das tut, was die Anwender:innen wirklich brauchen. Ein Beispiel: Für dieselbe Online-Banking-Anwendung würde die Validierung untersuchen, ob die Benutzer:innen die Überweisungsfunktion leicht finden, intuitiv bedienen können und ob alle für sie relevanten Informationen (z.B. verbleibendes Tageslimit) klar ersichtlich sind.

Welche grundlegenden Testarten gibt es?

Unit-Tests (Modultests): Die kleinsten Bausteine prüfen

Unit-Tests, auch Modul- oder Komponententests genannt, konzentrieren sich auf die kleinsten isolierbaren Teile einer Software, typischerweise einzelne Funktionen, Methoden oder Klassen.

• Umfang: Eine einzelne, kleine Code-Einheit, die möglichst isoliert von anderen Teilen des Systems getestet wird.
• Zweck: Überprüfen der korrekten logischen Funktionsweise dieser spezifischen Einheit. Es wird getestet, ob die Unit für definierte Eingaben die erwarteten Ausgaben liefert und sich wie spezifiziert verhält.
• Zeitpunkt: Werden in der Regel von den Entwickler:innen selbst während der Implementierungsphase geschrieben und sehr häufig (oft automatisiert nach jeder Codeänderung im Rahmen von Continuous Integration) ausgeführt.
• Beispiel: Für eine Funktion berechne_mehrwertsteuer(betrag, steuersatz) in einer Verkaufssoftware würde ein Unit-Test prüfen, ob bei einem betrag von 100 und einem steuersatz von 0.19 das Ergebnis korrekt 19 ist. Ein weiterer Test könnte prüfen, wie die Funktion auf ungültige Eingaben (z.B. negativer Betrag) reagiert.

Integrationstests: Das Zusammenspiel der Komponenten testen

Integrationstests überprüfen das korrekte Zusammenwirken von zwei oder mehr bereits getesteten Softwarekomponenten (Units oder Module), die zu einer größeren Einheit zusammengefügt werden.

• Umfang: Die Schnittstellen und Interaktionen zwischen mehreren Modulen oder Subsystemen.
• Zweck: Aufdecken von Fehlern, die beim Kombinieren von Komponenten entstehen, z.B. durch inkompatible Schnittstellen, falsche Datenübergaben, unerwartetes Verhalten im Zusammenspiel oder Probleme bei der Kommunikation zwischen den Modulen.
• Zeitpunkt: Nach den Unit-Tests, wenn einzelne Komponenten zu größeren Teilen des Systems integriert werden.
• Beispiel: In einem Webshop werden das Warenkorb-Modul und das Bezahl-Modul getestet. Ein Integrationstest würde prüfen, ob die Artikel aus dem Warenkorb korrekt an das Bezahl-Modul übergeben werden, ob nach erfolgreicher Bezahlung der Warenkorb geleert wird und ob das Bestell-Modul korrekt über die erfolgreiche Transaktion informiert wird.

Systemtests: Das Gesamtsystem im Blick

Systemtests bewerten das vollständig integrierte Softwaresystem als Ganzes gegen die ursprünglich definierten Anforderungen und Spezifikationen.

• Umfang: Das gesamte Softwaresystem in einer Umgebung, die der späteren Produktivumgebung möglichst nahekommt (Testumgebung).
• Zweck: Überprüfen, ob das System alle funktionalen (Was soll es tun?) und nicht-funktionalen (Wie gut soll es das tun? z.B. Performance, Sicherheit, Benutzerfreundlichkeit, Zuverlässigkeit) Anforderungen erfüllt. Es wird das Verhalten des gesamten Systems aus der Perspektive der anwendenden Person getestet.
• Zeitpunkt: Nachdem alle Komponenten integriert wurden und die Integrationstests erfolgreich waren; typischerweise bevor die Software an Kund:innen ausgeliefert oder von ihnen abgenommen wird (Akzeptanztests).
• Beispiel: Für eine neue Social-Media-App würde ein Systemtest umfassen, dass sich Benutzer:innen registrieren, einloggen, Beiträge erstellen und teilen, andere Benutzer:innen finden, Freundschaftsanfragen senden und Nachrichten austauschen können. Gleichzeitig würde geprüft, ob die App auch bei vielen gleichzeitigen Zugriffen stabil läuft (Lasttest als Teil der nicht-funktionalen Tests) und ob die Privatsphäre-Einstellungen korrekt funktionieren (Sicherheitstest).

Lernziele

• grundlegende Arten von Softwaretests (z.B. Unit-, Integrations-, Systemtests) differenzieren, indem der Umfang, der Zweck und der typische Zeitpunkt jeder Testart im Entwicklungsprozess erläutert werden.
• die Vorteile von frühzeitigem Testen im Softwareentwicklungszyklus 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.
• die Konzepte Verifikation und Validierung im Kontext der Softwarequalitätssicherung 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.