Der unsichtbare Baumeister: Eine Kulturgeschichte des Softwaretests und die Kunst der Validierung

Ein zehntägiger Selbstlernkurs über die Grundlagen des Softwaretests und der Validierung

---

Einleitung: Warum dieser Kurs anders ist

Es gibt Berufe, die erst dann wahrgenommen werden, wenn sie versagen. Einer von ihnen ist der Softwaretester. In einer Welt, die von Code durchdrungen ist – vom Wecker am Morgen bis zum Flugzeug, das uns über Kontinente trägt – bleibt die Arbeit jener, die sicherstellen, dass dieser Code funktioniert, meist unsichtbar. Dabei ist sie eine der anspruchsvollsten, verantwortungsvollsten und historisch interessantesten Disziplinen der Technikgeschichte.

Dieser Kurs ist kein schneller Ratgeber. Er ist eine Einladung, die Grundlagen des Softwaretests und der Validierung nicht nur praktisch zu erlernen, sondern auch zu verstehen: als kulturelle Praxis, als historisch gewachsene Denkweise und als ethische Verpflichtung. Er richtet sich an Berufseinsteiger, neugierige Anfänger und alle, die verstehen wollen, warum digitale Systeme heute so funktionieren – oder eben nicht.

Das Ziel: Sie erwerben nicht nur handwerkliches Wissen über Testebenen, Testarten und Testfallentwurf. Sie entwickeln ein Gespür für die Qualität von Software, lernen systematisch Fehler zu denken und werden zu einem kritischen Begleiter digitaler Entwicklungsprozesse. Nach Abschluss dieses Kurses sind Sie in der Lage, eigene Testfälle zu erstellen, Testprozesse einzuordnen und fundiert über Softwarequalität zu sprechen.

Format: Dieser Kurs ist als zehntägiges Selbstlernprogramm konzipiert. Jeder Tag umfasst eine Lerneinheit von etwa einer Stunde. Die Inhalte bauen logisch aufeinander auf – von den historischen Wurzeln bis zur praktischen Abschlussübung.

---

Tag 1: Was ist Softwaretest? – Warum testen wir?

Lernziel

Verstehen, warum Softwaretests unverzichtbar sind und welche gesellschaftliche Bedeutung sie haben.

Einführung: Der unsichtbare Baumeister

Stellen Sie sich vor, Sie bestellen ein Produkt in einem Online-Shop. Sie legen etwas in den Warenkorb, geben Ihre Adresse ein, bezahlen – und dann passiert nichts. Keine Bestellbestätigung, kein Paket. Oder schlimmer: Es wird der falsche Betrag abgebucht.

Solche Probleme entstehen durch Fehler in der Software. Softwaretests sollen genau solche Fehler vor der Auslieferung finden und beheben. Doch die Geschichte des Softwaretests ist auch eine Geschichte des Lernens durch Scheitern.

Historische Tiefe: Die Katastrophen, die uns lehrten

Die Notwendigkeit systematischer Tests wurde der Öffentlichkeit erst durch spektakuläre Fehlschläge bewusst:

Jahr	Ereignis	Folge
1962	Mariner 1 (Venus-Sonde) explodiert kurz nach Start	Fehler in der Flugbahnberechnungssoftware – ein einziger fehlender Bindestrich im Code
1985	Therac-25 (Strahlentherapiegerät) verursacht tödliche Überdosierungen	Race Conditions in der Software – bis zu sechs Todesfälle
1996	Ariane 5 (Trägerrakete) explodiert 37 Sekunden nach Start	Integer-Überlauf bei der Umwandlung einer 64-Bit-Zahl in eine 16-Bit-Zahl – Verlust von 370 Millionen US-Dollar

Diese Vorfälle zeigen: Softwaretests sind keine lästige Pflicht, sondern eine ethische Verantwortung.

Was ist ein Softwaretest?

Ein Softwaretest ist der Prozess, ein Programm auszuführen, um Fehler zu entdecken und sicherzustellen, dass es die Anforderungen erfüllt. Der amerikanische Informatiker Glenford Myers definierte bereits 1979 in seinem Klassiker The Art of Software Testing:

„Testing is the process of executing a program with the intent of finding errors.“

Ein Test umfasst mehr als das bloße Ausführen:

• Planung: Was wird getestet?
• Entwurf: Wie testet man?
• Durchführung: Testfälle ausführen
• Auswertung: Ergebnisse prüfen und dokumentieren

Warum ist Testen wichtig?

Grund	Erklärung
Qualitätssicherung	Software soll zuverlässig und korrekt arbeiten
Kosteneinsparung	Ein Fehler in der Produktion ist teurer als einer in der Entwicklung (Faktor 10 bis 100)
Sicherheit	Fehler können zu Datenverlust, Verletzungen oder Todesfällen führen
Kundenzufriedenheit	Fehlerfreie Software erhöht das Vertrauen der Nutzer
Einhaltung von Standards	Viele Branchen fordern Nachweise über Tests (Medizin, Luftfahrt, Finanzen)

Praxisbeispiel: Der Warenkorb im Online-Shop

Ein einfaches Beispiel:

• Anforderung: Der Warenkorb soll den Gesamtpreis korrekt berechnen.
• Möglicher Fehler: Beim Hinzufügen eines zweiten Artikels wird der Preis überschrieben statt addiert.
• Konsequenz: Der Kunde zahlt zu wenig oder zu viel – beides ist problematisch.

Testfall:

1. Artikel A (10 €) in den Warenkorb legen → Gesamtpreis 10 €
2. Artikel B (5 €) hinzufügen → Gesamtpreis 15 € (erwartet)
3. Tatsächlicher Preis: 5 € → Fehler gefunden!

Zusammenfassung Tag 1

• Softwaretests finden Fehler, bevor sie den Nutzer erreichen.
• Testen spart Geld, schützt vor Schäden und sichert die Qualität.
• Ein guter Test ist systematisch und nachvollziehbar.
• Die Geschichte des Softwaretests ist eine Geschichte des Lernens aus Katastrophen.

Aufgabe Tag 1 (ca. 15 Minuten)

Denken Sie an eine App oder Software, die Sie regelmäßig nutzen (z. B. Messenger, Banking-App, Navigations-App).

1. Beschreiben Sie eine Funktion dieser Software.
2. Überlegen Sie: Was könnte schiefgehen? Nennen Sie mindestens zwei mögliche Fehler.
3. Notieren Sie, welche Auswirkungen diese Fehler hätten.

---

Tag 2: Der Softwareentwicklungszyklus (SDLC) und die Rolle des Tests

Lernziel

Die Phasen der Softwareentwicklung verstehen und einordnen, wo und wie Tests in diesen Phasen eingebunden werden.

Einführung: Vom Wasserfall zur kontinuierlichen Prüfung

Software entsteht nicht einfach. Sie durchläuft einen Lebenszyklus – von der ersten Idee bis zur Wartung nach der Auslieferung. Die Art und Weise, wie Tests in diesen Zyklus eingebettet werden, hat sich über die Jahrzehnte dramatisch verändert.

Die klassischen Phasen des SDLC

Phase	Beschreibung	Testaktivität
Anforderungsanalyse	Was soll die Software tun?	Anforderungen auf Vollständigkeit, Widersprüche und Testbarkeit prüfen
Entwurf	Wie wird die Software gebaut?	Architektur und Schnittstellen auf Machbarkeit prüfen
Implementierung	Programmieren des Codes	Unittests durch Entwickler
Test	Systematisches Prüfen der Software	Integrationstests, Systemtests, Abnahmetests
Auslieferung	Bereitstellung für Nutzer	Rauchtests, Deployment-Tests
Wartung	Fehlerbehebungen, Erweiterungen	Regressionstests

Historischer Wandel: Vom Wasserfall zum Shift Left

In den 1970er und 1980er Jahren dominierte das Wasserfallmodell: Tests waren eine eigene Phase am Ende des Entwicklungsprozesses. Doch diese späte Integration erwies sich als problematisch – Fehler, die erst im Test entdeckt wurden, waren extrem teuer zu beheben.

Die Erkenntnis, die sich in den 1990er Jahren durchsetzte: Je früher ein Fehler gefunden wird, desto günstiger ist die Behebung.

Entdeckungszeitpunkt	Relative Kosten der Fehlerbehebung
Anforderungsphase	1
Entwurfsphase	5
Implementierungsphase	10
Testphase	20
Produktion	50–100

Diese Zahlen (nach Barry Boehm, Software Engineering Economics, 1981) führten zum Prinzip des Shift Left: Testaktivitäten so früh wie möglich im Entwicklungsprozess beginnen.

Beispiel: Eine Banking-App

Phase	Möglicher Fehler	Wenn unentdeckt
Anforderung	„Überweisung“ wurde als „Einzahlung“ definiert	Falsche Geschäftslogik, Neuentwicklung nötig
Entwurf	Schnittstelle zur Bank nicht geplant	Integration scheitert, Verzögerungen
Implementierung	Zinsberechnung falsch programmiert	Kunden erhalten falsche Zinsen, Reputationsschaden
Test	Testfall für Sonderfall vergessen	Fehler kommt in Produktion

Zusammenfassung Tag 2

• Der SDLC beschreibt die Phasen der Softwareentwicklung.
• Tests sind nicht nur eine Phase, sondern ein kontinuierlicher Prozess.
• Shift Left bedeutet: Testaktivitäten so früh wie möglich beginnen.
• Je früher ein Fehler gefunden wird, desto günstiger ist die Behebung.

Aufgabe Tag 2 (ca. 15 Minuten)

Stellen Sie sich vor, Sie entwickeln eine App für To-Do-Listen.

1. Zeichnen Sie eine einfache Grafik mit den SDLC-Phasen (oder beschreiben Sie sie in Stichpunkten).
2. Markieren Sie für jede Phase eine mögliche Testaktivität.
3. Beschreiben Sie kurz, was passiert, wenn ein Fehler in der Anforderungsphase unentdeckt bleibt.

---

Tag 3: Grundbegriffe – Verification vs. Validation, Fehler vs. Defekt

Lernziel

Die wichtigsten Fachbegriffe des Softwaretests sicher unterscheiden können.

Einführung: Die Sprache der Qualität

Um über Qualität zu sprechen, braucht es eine klare Sprache. Im Softwaretest hat sich ein Begriffssystem etabliert, das oft missverstanden wird. Zwei Unterscheidungen sind besonders zentral: Verification vs. Validation und Error vs. Defekt vs. Failure.

Verification und Validation

Diese beiden Begriffe wurden auf der berühmten NATO-Konferenz 1968 in Garmisch-Partenkirchen als zentrale Konzepte der Softwaretechnik etabliert.

Begriff	Bedeutung	Frage	Beispiel
Verification	Prüft, ob das Produkt gemäß den Spezifikationen gebaut wurde	„Bauen wir das Produkt richtig?“	Code-Review, Unittest prüft, ob eine Funktion korrekt programmiert wurde
Validation	Prüft, ob das Produkt die tatsächlichen Bedürfnisse der Nutzer erfüllt	„Bauen wir das richtige Produkt?“	Abnahmetest mit echten Nutzern

Merksatz:
Verification prüft gegen das Pflichtenheft (technische Spezifikation).
Validation prüft gegen die Anforderungen (Nutzerbedürfnisse).

Error, Defekt und Failure

Diese Kette – vom menschlichen Irrtum über den im Code verankerten Defekt bis hin zum sichtbaren Versagen – ist zentral, um zu verstehen, warum Testen nicht einfach „Ausprobieren“ ist, sondern systematische Fehlersuche.

Begriff	Beschreibung	Beispiel
Error (Fehler)	Ein menschlicher Fehler im Denken oder Handeln	Ein Entwickler schreibt if (a = b) statt if (a == b)
Defekt (Bug)	Die Abweichung im Programm (Ursache)	Der Code enthält eine Zuweisung statt eines Vergleichs
Failure (Versagen)	Der Defekt zeigt sich während der Ausführung	Das Programm stürzt ab oder liefert falsches Ergebnis

Kette:

Mensch macht Error → Programm enthält Defekt → Bei Ausführung tritt Failure auf

Beispiele zur Veranschaulichung

Beispiel 1: Taschenrechner

• Error: Entwickler denkt, dass Division durch 0 erlaubt ist.
• Defekt: Code erlaubt Division durch 0.
• Failure: Programm stürzt ab, wenn Nutzer durch 0 teilt.

Beispiel 2: Anmeldefunktion

• Error: Anforderung „Passwort muss 8 Zeichen haben“ wurde übersehen.
• Defekt: Passwörter mit 3 Zeichen werden akzeptiert.
• Failure: Nutzer meldet: „Ich konnte mich mit ‚abc‘ anmelden – das ist unsicher!“

Zusammenfassung Tag 3

• Verification = richtig gebaut?
• Validation = das Richtige gebaut?
• Error = menschlicher Fehler
• Defekt = Fehler im Code
• Failure = sichtbares Versagen bei Ausführung

Aufgabe Tag 3 (ca. 15 Minuten)

Gegeben ist folgende Situation:

Ein Entwickler programmiert eine Funktion, die den Rabatt berechnet:
„Bei einem Einkauf über 100 € gibt es 10 % Rabatt.“
Er schreibt:
if (einkaufswert > 100) { rabatt = einkaufswert * 0.1; }
Tatsächlich soll der Rabatt aber ab 100 € (inklusive) gewährt werden.

1. Was ist hier der Error?
2. Was ist der Defekt?
3. Wann würde ein Failure auftreten?
4. Handelt es sich bei der Prüfung des Codes durch einen Kollegen um Verification oder Validation? Begründen Sie.

---

Tag 4: Testebenen – Unit-, Integrations-, System- und Abnahmetest

Lernziel

Die vier klassischen Testebenen kennen und voneinander abgrenzen können.

Einführung: Ein Schichtenmodell der Prüfung

Software besteht aus vielen kleinen Teilen. Man testet nicht alles auf einmal, sondern auf verschiedenen Ebenen. Jede Ebene hat einen eigenen Zweck und findet unterschiedliche Fehlerarten. Dieses Schichtenmodell hat sich seit den 1980er Jahren als Industriestandard etabliert.

Die vier Testebenen im Überblick

Ebene	Was wird getestet?	Wer führt durch?	Typische Fehler
Unit-Test	Einzelne Funktion, Methode oder Klasse	Entwickler	Logikfehler, falsche Berechnungen
Integrationstest	Zusammenspiel mehrerer Einheiten	Entwickler oder Tester	Schnittstellenfehler, falsche Datenübergabe
Systemtest	Das gesamte System im produktionsähnlichen Umfeld	Tester	Gesamtverhalten, Performance, Sicherheit
Abnahmetest (UAT)	Das System aus Sicht des Nutzers	Endnutzer, Fachabteilung	Erfüllung der Geschäftsanforderungen

Detaillierte Betrachtung

Unit-Test

• Testet die kleinste testbare Einheit isoliert.
• Meist automatisiert (z. B. mit JUnit, pytest, NUnit).
• Entwickler schreiben Unit-Tests oft parallel zum Code oder sogar davor (Test-Driven Development).
• Beispiel: Eine Funktion addiere(a, b) wird mit verschiedenen Werten getestet: (2, 3) → 5, (-1, 1) → 0.

Integrationstest

• Testet das Zusammenspiel zwischen Komponenten.
• Kann von unten nach oben (Bottom-up) oder von oben nach unten (Top-down) erfolgen.
• Beispiel: Prüfen, ob die Datenbankverbindung funktioniert und ob die Anmeldekomponente korrekt mit der Benutzerdatenbank kommuniziert.

Systemtest

• Testet das vollständige, integrierte System.
• Umfasst funktionale und nicht-funktionale Tests.
• Beispiel: Die gesamte Anwendung wird in einer Testumgebung installiert und alle Funktionen werden durchgetestet – vom Login bis zur Abmeldung.

Abnahmetest (User Acceptance Testing, UAT)

• Letzte Teststufe vor der Auslieferung.
• Wird von den späteren Nutzern durchgeführt.
• Beispiel: Ein Mitarbeiter aus der Buchhaltung prüft, ob die neue Rechnungssoftware alle benötigten Geschäftsprozesse abdeckt.

Beispiel: Eine Bestellplattform

Ebene	Testgegenstand	Beispiel
Unit	Funktion preisBerechnen(menge, preisProStueck)	Test mit menge=2, preis=10 → Ergebnis=20
Integration	Warenkorb + Preisberechnung	Artikel in Warenkorb legen → Gesamtpreis korrekt
System	Gesamte Plattform	Bestellung von A bis Z durchspielen (Login, Artikel suchen, Warenkorb, Bezahlung, Bestätigung)
Abnahme	Endnutzer testet	„Kann ich als Kunde mit Rabattcode bestellen?“

Zusammenfassung Tag 4

• Unit-Test: Kleinste Einheit isoliert
• Integrationstest: Zusammenspiel
• Systemtest: Gesamtsystem
• Abnahmetest: Nutzerakzeptanz
• Alle Ebenen sind wichtig – keine ersetzt die andere.

Aufgabe Tag 4 (ca. 15 Minuten)

Ordnen Sie die folgenden Testaktivitäten der richtigen Testebene zu:

Aktivität	Testebene
Ein Entwickler testet eine einzelne Funktion, die den Rabatt berechnet.
Ein Fachanwender prüft, ob die neue Software den Arbeitsablauf im Büro unterstützt.
Es wird getestet, ob die Datenbank und der Webserver korrekt miteinander kommunizieren.
Die gesamte Anwendung wird auf einem Testserver installiert und umfassend geprüft.

Zusatzfrage:
Welche Testebene fehlt, wenn Sie nur Unit- und Systemtests durchführen? Welche Fehler könnten übersehen werden?

---

Tag 5: Testarten – Funktionale und nicht-funktionale Tests

Lernziel

Den Unterschied zwischen funktionalen und nicht-funktionalen Tests kennen und Beispiele für beide Kategorien nennen können.

Einführung: Was vs. Wie gut

Nicht jeder Test prüft, ob eine Funktion „funktioniert“. Manchmal geht es um Eigenschaften der Software: Wie schnell ist sie? Wie sicher? Wie benutzerfreundlich?

Diese Unterscheidung ist nicht akademisch – sie hat praktische Konsequenzen für Testplanung, Ressourcen und Werkzeuge.

Funktionale Tests

Sie prüfen was die Software tut – ob sie die spezifizierten Funktionen korrekt ausführt.

Testart	Beschreibung	Beispiel
Funktionstest	Prüft einzelne Funktionen gegen Anforderungen	Login funktioniert mit korrekten Daten
Integrationstest (funktional)	Prüft Zusammenspiel von Funktionen	Nach erfolgreichem Login wird das Dashboard geladen
Systemtest (funktional)	Prüft Gesamtfunktionalität	Bestellprozess vollständig durchlaufen
Regressionstest	Prüft, ob neue Änderungen bestehende Funktionen zerstört haben	Nach einem Update funktioniert der Login noch
Smoke Test	Grober Test, ob das System startet und grundlegend funktioniert	App startet und Hauptmenü ist erreichbar

Nicht-funktionale Tests

Sie prüfen wie gut die Software etwas tut – die Qualitätsmerkmale.

Testart	Beschreibung	Beispiel
Performancetest	Prüft Geschwindigkeit, Antwortzeiten	1000 Nutzer gleichzeitig → Antwortzeit unter 2 Sekunden
Lasttest	Prüft Verhalten unter erwarteter Last	Black Friday: 10.000 Bestellungen pro Minute
Stresstest	Prüft Verhalten über der Belastungsgrenze hinaus	50.000 Nutzer → System stürzt kontrolliert ab
Sicherheitstest	Prüft Schutz vor Angriffen	SQL-Injection, Passwort sicher gespeichert
Usability-Test	Prüft Benutzerfreundlichkeit	Finden neue Nutzer die Funktion zum Zurücksetzen des Passworts?
Kompatibilitätstest	Prüft auf verschiedenen Geräten/Browsern	Website funktioniert auf Chrome, Firefox, Safari und mobil

Beispiel: Online-Banking-Login

Testart	Kategorie	Testfall
Login mit korrekten Daten	funktional	Zugang gewährt
Login mit falschem Passwort	funktional	Fehlermeldung erscheint
Ladezeit unter 3 Sekunden	nicht-funktional (Performance)	Seite lädt schnell genug
Login auch mit Screenreader bedienbar	nicht-funktional (Usability / Barrierefreiheit)	Zugänglichkeit für blinde Nutzer
Mehrere falsche Eingaben führen zu Sperre	nicht-funktional (Sicherheit)	Schutz vor Brute-Force-Angriffen

Zusammenfassung Tag 5

• Funktionale Tests: Prüfen die Erfüllung der fachlichen Anforderungen.
• Nicht-funktionale Tests: Prüfen Qualitätsmerkmale wie Performance, Sicherheit, Benutzerfreundlichkeit.
• Beide sind wichtig für eine hochwertige Software.
• Der amerikanische Qualitätsexperte Gerald Weinberg bemerkte: „Der Mensch neigt dazu, das zu testen, was er erwartet, nicht das, was tatsächlich da ist.“

Aufgabe Tag 5 (ca. 15 Minuten)

Sie testen eine Wetter-App. Nennen Sie für jede der folgenden Kategorien einen konkreten Testfall:

1. Funktionale Anforderung
2. Performance
3. Sicherheit
4. Usability
5. Kompatibilität

Beispiel:
Funktional: „Die App zeigt die aktuelle Temperatur für den eingegebenen Ort an.“

---

Tag 6: White-Box- vs. Black-Box-Testing

Lernziel

Die beiden grundlegenden Testansätze verstehen und entscheiden können, wann welcher Ansatz sinnvoll ist.

Einführung: Zwei Welten des Testens

Es gibt zwei grundsätzliche Perspektiven, aus denen man Software testen kann. Diese Unterscheidung wurde in den 1970er Jahren von Glenford Myers und anderen systematisch herausgearbeitet und ist bis heute grundlegend.

Black-Box-Testing

Merkmal	Beschreibung
Perspektive	Außensicht (wie ein Nutzer)
Kenntnis	Keine Kenntnis des Quellcodes
Grundlage	Anforderungen, Spezifikationen
Ziel	Prüfen, ob das System die Anforderungen erfüllt
Techniken	Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellen

Beispiel:
Sie testen eine Suchmaschine. Sie geben Suchbegriffe ein und prüfen, ob relevante Ergebnisse erscheinen. Sie wissen nicht, wie der Algorithmus im Inneren arbeitet.

White-Box-Testing

Merkmal	Beschreibung
Perspektive	Innensicht (wie ein Entwickler)
Kenntnis	Quellcode ist bekannt
Grundlage	Code-Struktur, Logikpfade
Ziel	Sicherstellen, dass alle Pfade, Zweige und Bedingungen getestet werden
Techniken	Anweisungsüberdeckung, Zweigüberdeckung, Pfadüberdeckung

Beispiel:
Sie testen eine Funktion, die je nach Eingabe unterschiedliche Zweige durchläuft. Sie stellen sicher, dass jeder Zweig mindestens einmal ausgeführt wird.

Überdeckungsarten (White-Box)

Überdeckungsart	Beschreibung	Beispiel
Anweisungsüberdeckung (Statement Coverage)	Jede Code-Zeile wurde mindestens einmal ausgeführt	100 % = alle Zeilen getestet
Zweigüberdeckung (Branch Coverage)	Jede mögliche Verzweigung (if/else) wurde getestet	if (a > b) – beide Fälle (true und false)
Pfadüberdeckung (Path Coverage)	Jeder mögliche Weg durch das Programm wurde getestet	Alle Kombinationen von Verzweigungen

Einfaches Code-Beispiel:

python

def rabatt(preis):
    if preis > 100:
        return preis * 0.9
    else:
        return preis

• Anweisungsüberdeckung: Ein Test mit preis=150 deckt beide Zeilen ab? Nein – nur den if-Zweig. Die else-Zeile wird nicht ausgeführt.
• Zweigüberdeckung: Man braucht zwei Tests: preis=150 und preis=50.
• Pfadüberdeckung: Hier identisch mit Zweigüberdeckung (da nur eine Verzweigung).

Vergleich

Kriterium	Black-Box	White-Box
Wissen über Code	Keins	Vollständig
Durchführender	Tester, Nutzer	Entwickler, Tester mit Code-Zugriff
Fehlerarten	Falsches Verhalten, fehlende Funktionen	Logikfehler, nicht ausgeführte Pfade
Aufwand	Mittel	Hoch (bei vollständiger Überdeckung)

Zusammenfassung Tag 6

• Black-Box: Test von außen, basierend auf Anforderungen.
• White-Box: Test von innen, basierend auf Code-Struktur.
• Beide Ansätze sind wichtig: Black-Box prüft das Was, White-Box prüft die Vollständigkeit der Tests.

Aufgabe Tag 6 (ca. 15 Minuten)

Gegeben ist folgender Code:

python

def zugang_gewaehren(alter, mitgliedschaft):
    if alter >= 18 and mitgliedschaft == "aktiv":
        return "Zugang erlaubt"
    else:
        return "Zugang verweigert"

1. Black-Box: Nennen Sie zwei Testfälle nur auf Basis der Beschreibung.
2. White-Box: Welche Tests sind nötig, um 100 % Zweigüberdeckung zu erreichen?
3. Zusatz: Warum reicht Black-Box allein nicht aus, um alle Fehler zu finden?

---

Tag 7: Testfall-Entwurf – Struktur, Techniken, Beispiele

Lernziel

Professionelle Testfälle aufbauen und mit einfachen Techniken systematisch entwerfen können.

Einführung: Die Kunst der systematischen Prüfung

Ein Testfall ist mehr als eine Idee. Er ist ein präzises, reproduzierbares Dokument. Gute Testfälle sind:

• Wiederholbar: Jeder Tester kommt zum gleichen Ergebnis
• Eindeutig: Keine Interpretationsspielräume
• Nachvollziehbar: Auch später versteht man, was geprüft wurde

Struktur eines Testfalls (nach IEEE 829)

Feld	Beschreibung	Beispiel
Testfall-ID	Eindeutige Kennung	TC_LOGIN_001
Beschreibung	Kurzer Titel, was geprüft wird	Login mit korrekten Daten
Vorbedingungen	Was muss vorher erfüllt sein?	Benutzer ist registriert, Browser geöffnet
Testschritte	Detaillierte Schritt-für-Schritt-Anleitung	1. E-Mail eingeben 2. Passwort eingeben 3. Klick auf „Anmelden“
Erwartetes Ergebnis	Was soll passieren?	Weiterleitung zum Dashboard, Begrüßung „Hallo Max“
Tatsächliches Ergebnis	(wird bei Ausführung ausgefüllt)
Status	Bestanden / Nicht bestanden

Testfall-Entwurfstechniken

Äquivalenzklassenbildung

Man teilt mögliche Eingaben in Klassen ein, bei denen das Verhalten gleich sein sollte.
Es reicht, einen Vertreter pro Klasse zu testen. Diese Technik geht auf Glenford Myers zurück und reduziert die Anzahl notwendiger Tests erheblich.

Beispiel: Alter (0–120 Jahre)

• Gültige Klasse: 0 bis 120
• Ungültige Klasse: unter 0
• Ungültige Klasse: über 120

→ Testfälle: Alter = 50 (gültig), Alter = -5 (ungültig), Alter = 150 (ungültig)

Grenzwertanalyse

Man testet die Grenzen zwischen Äquivalenzklassen. Hier treten besonders häufig Fehler auf – ein Phänomen, das in der Praxis immer wieder beobachtet wird.

Beispiel: Alter (0–120)

• Grenzen: 0, 1, 119, 120
• Testfälle: 0 (gültig), 1 (gültig), 119 (gültig), 120 (gültig), -1 (ungültig), 121 (ungültig)

Beispiel: Postleitzahlenfeld (5-stellig, nur Zahlen)

Äquivalenzklassen:

• Gültig: 5-stellige Zahl (z. B. 10115)
• Ungültig: weniger als 5 Zeichen
• Ungültig: mehr als 5 Zeichen
• Ungültig: enthält Buchstaben
• Ungültig: leer

Testfälle:

ID	Beschreibung	Eingabe	Erwartet
TC_PLZ_001	Gültige PLZ	10115	Akzeptiert
TC_PLZ_002	Zu kurz	1234	Fehlermeldung
TC_PLZ_003	Zu lang	123456	Fehlermeldung
TC_PLZ_004	Enthält Buchstaben	12A45	Fehlermeldung
TC_PLZ_005	Leeres Feld	(leer)	Fehlermeldung

Zusammenfassung Tag 7

• Ein Testfall besteht aus ID, Beschreibung, Vorbedingungen, Schritten, erwartetem Ergebnis.
• Äquivalenzklassenbildung reduziert die Anzahl notwendiger Tests.
• Grenzwertanalyse prüft die kritischen Stellen an den Grenzen.

Aufgabe Tag 7 (ca. 15 Minuten)

Sie testen ein Altersfeld für eine Website, auf der man nur ab 18 Jahren bestellen darf.
Erlaubt sind Zahlen von 18 bis 99.

1. Bilden Sie die Äquivalenzklassen (gültig und ungültig).
2. Führen Sie eine Grenzwertanalyse durch.
3. Erstellen Sie drei Testfälle in Tabellenform (mit ID, Beschreibung, Eingabe, erwartetem Ergebnis).

---

Tag 8: Testplanung und User Acceptance Testing (UAT)

Lernziel

Verstehen, wie Tests organisiert werden und was bei der finalen Abnahme durch Nutzer zu beachten ist.

Einführung: Vom Plan zur Freigabe

Testen passiert nicht einfach „irgendwie“. Es wird geplant. Ein Testplan legt fest, was, wie, wann und von wem getestet wird. Am Ende des Testprozesses steht der Abnahmetest (UAT), bei dem die Nutzer bestätigen, dass die Software ihren Anforderungen entspricht.

Bestandteile eines Testplans (nach IEEE 829)

Bestandteil	Beschreibung
Testumfang	Welche Funktionen werden getestet? Was ist ausgeschlossen?
Testziele	Was soll mit den Tests erreicht werden?
Teststrategie	Welche Testebenen und -arten werden eingesetzt?
Ressourcen	Wer führt Tests durch? Welche Werkzeuge?
Testumgebung	Hardware, Software, Datenbanken, Netzwerk
Testdaten	Welche Daten werden für Tests benötigt?
Zeitplan	Wann beginnen und enden die Tests?
Risiken	Was könnte schiefgehen? (z. B. Zeitmangel, fehlende Umgebung)
Kriterien	Wann gilt ein Test als bestanden? Wann ist das Produkt freigabereif?

User Acceptance Testing (UAT)

Der UAT ist die letzte Teststufe vor der Auslieferung. Er wird von Endnutzern oder der Fachabteilung durchgeführt.

Ziel: Sicherstellen, dass die Software die Geschäftsanforderungen erfüllt und im Arbeitsalltag funktioniert.

Historische Bedeutung: Der UAT ist ein sozialer und organisatorischer Prozess, nicht nur ein technischer. Er entscheidet über Freigabe oder Ablehnung – und damit über den Erfolg oder Misserfolg eines Projekts.

Typische UAT-Aktivitäten:

• Geschäftsprozesse werden mit der Software durchgespielt
• Prüfung auf Vollständigkeit der Funktionen
• Prüfung auf Benutzerfreundlichkeit aus Fachperspektive
• Formale Bestätigung (Akzeptanzkriterien erfüllt)

Voraussetzungen für UAT:

• Systemtest ist abgeschlossen
• Kritische Fehler sind behoben
• Testumgebung ist stabil
• Fachabteilung hat Zeitfenster eingeräumt

Beispiel: UAT für eine Rechnungssoftware

Aktivität	Beteiligte	Ergebnis
Rechnung erstellen	Buchhalter	Funktion vorhanden, alle Pflichtfelder da
Rechnung versenden	Buchhalter	Versand per E-Mail funktioniert
Zahlungseingang buchen	Buchhalter	Buchung wird korrekt erfasst
Offene Posten anzeigen	Buchhalter	Übersicht ist klar und vollständig

Nach erfolgreichem UAT wird die Akzeptanz formal bestätigt (z. B. durch Unterschrift oder Freigabe im Tool).

Zusammenfassung Tag 8

• Ein Testplan organisiert den gesamten Testprozess.
• UAT ist der finale Test durch die Nutzer.
• Ohne UAT besteht das Risiko, dass die Software zwar technisch korrekt ist, aber im Geschäftsalltag nicht funktioniert.

Aufgabe Tag 8 (ca. 15 Minuten)

Stellen Sie sich vor, Sie planen Tests für eine Mitarbeiter-App zur Urlaubsbeantragung.

1. Nennen Sie drei Punkte, die in den Testplan gehören.
2. Beschreiben Sie zwei Szenarien für den UAT (wer führt was durch?).
3. Nennen Sie ein Kriterium, das erfüllt sein muss, bevor der UAT starten darf.

---

Tag 9: Best Practices & Industriestandards

Lernziel

Bewährte Praktiken aus der Industrie kennen und verstehen, welche Standards im Softwaretest eine Rolle spielen.

Einführung: Von der Kunst zum Handwerk

Softwaretest hat sich von einer oft stiefmütterlich behandelten „lästigen Pflicht“ zu einer professionellen Disziplin entwickelt. Dies ist nicht zuletzt der Arbeit von Organisationen wie dem ISTQB (gegründet 2002) und der Etablierung von Industriestandards zu verdanken.

Best Practices im Softwaretest

Best Practice	Beschreibung
Shift Left	Testaktivitäten früh im Entwicklungsprozess beginnen (bereits in der Anforderungsphase)
Testautomatisierung	Sich wiederholende Tests (z. B. Regressionstests) automatisieren, um Zeit zu sparen
Unabhängigkeit der Tester	Entwickler sollten ihre eigenen Arbeiten nicht allein testen – ein unabhängiger Tester findet mehr Fehler
Nachvollziehbare Testfälle	Testfälle so dokumentieren, dass sie jederzeit von anderen ausgeführt werden können
Risikobasierter Ansatz	Mehr Testaufwand in kritische Bereiche investieren
Kontinuierliches Testen	Testen als fortlaufenden Prozess verstehen, nicht als Phase am Ende
Testdatenmanagement	Realistische Testdaten bereitstellen, ohne sensible Daten zu verwenden

Wichtige Industriestandards

Standard	Bereich	Bedeutung
ISTQB	Grundlagenwissen	Internationaler Standard für Test-Ausbildungen. Bietet ein gemeinsames Begriffssystem, das weltweit von Tausenden Unternehmen genutzt wird.
ISO/IEC 25010	Softwarequalität	Definiert Qualitätsmerkmale: Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit, Portabilität. Nachfolger der bekannten ISO 9126.
ISO/IEC 29119	Testprozesse	Internationaler Standard für Testprozesse, -dokumentation und -techniken
IEEE 829	Testdokumentation	Standard für Testpläne, Testfallbeschreibungen, Testberichte. Seit 2008 in der Überarbeitung, aber immer noch weit verbreitet.

Shift Left – im Detail

„Shift Left“ bedeutet, Tests nach links im Entwicklungsprozess zu verschieben – also früher zu beginnen. Der Begriff wurde in den 2000er Jahren im Zuge agiler Entwicklungsmethoden populär.

Beispiel für Shift Left:

• Traditionell: Test beginnt nach der Implementierung
• Shift Left:
  • Anforderungen werden schon auf Testbarkeit geprüft
  • Entwickler schreiben Unittests vor dem Code (Test-Driven Development)
  • Code-Reviews finden vor der Integration statt

Vorteil: Fehler werden früher gefunden – die Behebung ist günstiger und schneller. Die bereits in Tag 2 dargestellte Kostentabelle ist die empirische Grundlage dieses Prinzips.

Zusammenfassung Tag 9

• Best Practices wie Shift Left, Testautomatisierung und risikobasierter Ansatz erhöhen die Testeffizienz.
• Industriestandards (ISTQB, ISO 25010) schaffen eine gemeinsame Basis für professionelles Testen.
• Wer diese Prinzipien anwendet, wird im Berufsalltag als wertvoller Qualitätsexperte geschätzt.

Aufgabe Tag 9 (ca. 15 Minuten)

1. Erklären Sie in Ihren eigenen Worten, was „Shift Left“ bedeutet und warum es wichtig ist.
2. Nennen Sie zwei Situationen, in denen sich Testautomatisierung besonders lohnt.
3. Welches Qualitätsmerkmal aus ISO 25010 ist für eine Banking-App besonders wichtig? Begründen Sie kurz.

---

Tag 10: Abschlussübung – Testfälle für eine Beispielanwendung

Lernziel

Alle bisher gelernten Inhalte praxisnah anwenden und einen vollständigen Testsatz für eine konkrete Funktion erstellen.

Szenario: Anmeldefunktion

Sie testen eine Anmeldefunktion für eine Webanwendung.

Regeln:

• E-Mail-Adresse: muss ein gültiges Format haben (z. B. name@domain.de)
• Passwort: mindestens 8 Zeichen, mindestens eine Zahl
• Button „Anmelden“: nur aktiv, wenn beide Felder gültig sind
• Bei falschen Daten: Fehlermeldung „Anmeldedaten ungültig“
• Bei korrekten Daten: Weiterleitung zum Dashboard

---

Teil 1: Testfälle erstellen (ca. 30 Minuten)

Erstellen Sie mindestens 6 Testfälle in folgender Tabellenform:

ID	Beschreibung	Vorbedingungen	Testschritte	Erwartetes Ergebnis
TC_LOGIN_001	…	…	…	…

Berücksichtigen Sie:

• Gültige Kombinationen
• Ungültige Kombinationen
• Grenzfälle (z. B. Passwort genau 8 Zeichen, Passwort 7 Zeichen)
• Leere Felder
• Sonderfälle (z. B. E-Mail ohne @)

---

Teil 2: Analyse (ca. 15 Minuten)

Beantworten Sie folgende Fragen zu Ihren Testfällen:

1. Testebenen: Auf welcher Testebene befinden sich diese Tests? Begründen Sie.
2. Black-Box oder White-Box: Handelt es sich um Black-Box- oder White-Box-Tests? Begründen Sie.
3. Äquivalenzklassen: Welche Äquivalenzklassen haben Sie für das Passwort gebildet?
4. Nicht-funktionaler Test: Beschreiben Sie einen nicht-funktionalen Test für die Anmeldefunktion.

---

Teil 3: Reflexion (ca. 10 Minuten)

Notieren Sie kurz:

• Was war für Sie die größte Herausforderung bei der Erstellung der Testfälle?
• Welches Thema aus den letzten zwei Wochen fanden Sie am wichtigsten?
• Wo sehen Sie Ihre nächsten Schritte, um sich im Bereich Softwaretest weiterzuentwickeln?

---

Lösungsvorschlag für die Abschlussübung

Teil 1: Testfälle

ID	Beschreibung	Vorbedingungen	Testschritte	Erwartetes Ergebnis
TC_LOGIN_001	Gültige Anmeldung mit korrekten Daten	Benutzer ist registriert (max@beispiel.de / passwort123)	1. E-Mail: max@beispiel.de eingeben 2. Passwort: passwort123 eingeben 3. Button „Anmelden“ klicken	Weiterleitung zum Dashboard
TC_LOGIN_002	Passwort genau 8 Zeichen mit Zahl	Benutzer ist registriert (test@mail.de / passwort1)	1. E-Mail: test@mail.de eingeben 2. Passwort: passwort1 eingeben 3. Button „Anmelden“ klicken	Weiterleitung zum Dashboard (Grenzwertanalyse)
TC_LOGIN_003	Passwort 7 Zeichen (zu kurz)	Benutzer ist registriert	1. E-Mail: beliebig@mail.de eingeben 2. Passwort: passwor1 (7 Zeichen) eingeben 3. Button „Anmelden“ klicken	Fehlermeldung „Anmeldedaten ungültig“
TC_LOGIN_004	Passwort ohne Zahl	Benutzer ist registriert	1. E-Mail: beliebig@mail.de eingeben 2. Passwort: passwort (ohne Zahl) eingeben 3. Button „Anmelden“ klicken	Fehlermeldung „Anmeldedaten ungültig“
TC_LOGIN_005	Ungültiges E-Mail-Format	–	1. E-Mail: max.beispiel.de (ohne @) eingeben 2. Passwort: passwort123 eingeben	Button „Anmelden“ bleibt inaktiv (kein Klick möglich)
TC_LOGIN_006	Beide Felder leer	–	1. E-Mail-Feld leer lassen 2. Passwort-Feld leer lassen	Button „Anmelden“ bleibt inaktiv
TC_LOGIN_007	Korrekte E-Mail, falsches Passwort	Benutzer ist registriert	1. E-Mail: max@beispiel.de eingeben 2. Passwort: falschesPasswort eingeben 3. Button „Anmelden“ klicken	Fehlermeldung „Anmeldedaten ungültig“

Teil 2: Analyse

1. Testebenen
Diese Tests befinden sich auf der Systemtest-Ebene.
Begründung: Es wird das vollständige, integrierte System getestet – nicht nur eine isolierte Funktion (Unit) und nicht nur das Zusammenspiel zweier Komponenten (Integration). Die Anmeldefunktion wird im Gesamtkontext der Webanwendung geprüft, inklusive Weiterleitung zum Dashboard.

2. Black-Box oder White-Box?
Es handelt sich um Black-Box-Tests.
Begründung: Die Tests basieren ausschließlich auf den Anforderungen und Regeln (E-Mail-Format, Passwortlänge, Button-Verhalten, Fehlermeldungen). Es wird kein Blick in den Quellcode genommen.

3. Äquivalenzklassen für das Passwort

Klasse	Bereich	Beispiel	Erwartung
Gültig	≥ 8 Zeichen, mind. 1 Zahl	passwort1	Akzeptiert
Ungültig – zu kurz	< 8 Zeichen	passwor1	Abgelehnt
Ungültig – keine Zahl	≥ 8 Zeichen, aber keine Zahl	passwort	Abgelehnt
Ungültig – leer	–	(leer)	Abgelehnt (Button inaktiv)

Grenzwertanalyse:

• 7 Zeichen mit Zahl → ungültig
• 8 Zeichen mit Zahl → gültig
• 8 Zeichen ohne Zahl → ungültig

4. Nicht-funktionaler Test

ID	Beschreibung	Testschritte	Erwartetes Ergebnis
NF_001	Antwortzeit bei gleichzeitigen Anmeldungen	100 Nutzer simulieren, die sich gleichzeitig anmelden	Die durchschnittliche Antwortzeit liegt unter 3 Sekunden

Alternative nicht-funktionale Tests:

• Sicherheit: Nach 5 fehlgeschlagenen Anmeldeversuchen wird der Account für 15 Minuten gesperrt.
• Usability: Die Fehlermeldung „Anmeldedaten ungültig“ erscheint innerhalb von 1 Sekunde nach Klick.

Teil 3: Reflexion (Beispielantworten)

Größte Herausforderung:
Die größte Herausforderung war, alle Grenzfälle und ungültigen Kombinationen systematisch zu erfassen. Besonders die Kombination aus mehreren ungültigen Bedingungen zu berücksichtigen, war aufwendig.

Wichtigstes Thema:
Das Thema Testfall-Entwurf mit Äquivalenzklassen und Grenzwertanalyse. Dadurch kann ich systematisch vorgehen und muss nicht „wild drauflos testen“.

Nächste Schritte:

1. Praktische Erfahrung sammeln, z. B. durch Testen von Open-Source-Projekten.
2. Grundlagen der Testautomatisierung erlernen (z. B. mit Selenium).
3. ISTQB-Foundation-Level-Zertifizierung in Betracht ziehen.

---

Glossar: Wichtige Fachbegriffe des Softwaretests

Begriff	Erklärung
Acceptance Testing	Abnahmetest; letzte Teststufe, bei der der Nutzer prüft, ob die Software die Geschäftsanforderungen erfüllt.
Äquivalenzklassenbildung	Testentwurfstechnik; Eingaben werden in Klassen eingeteilt, bei denen das Verhalten gleich sein sollte.
Best Practices	Bewährte Vorgehensweisen in der Branche, z. B. Shift Left, Testautomatisierung, risikobasierter Ansatz.
Black-Box-Testing	Testansatz ohne Kenntnis des Quellcodes; basiert auf Anforderungen und Spezifikationen.
Defekt	Fehler im Programmcode, der zu einem falschen Verhalten führen kann. Auch Bug genannt.
Error	Menschlicher Fehler, der zu einem Defekt führt.
Failure	Sichtbares Versagen der Software während der Ausführung (z. B. Absturz, falsches Ergebnis).
Grenzwertanalyse	Testentwurfstechnik; testet die Grenzen zwischen Äquivalenzklassen, wo Fehler besonders häufig auftreten.
Integration Testing	Testebene, die das Zusammenspiel mehrerer Komponenten oder Module prüft.
ISO 25010	Internationaler Standard für Softwarequalität; definiert Qualitätsmerkmale wie Funktionalität, Zuverlässigkeit, Benutzbarkeit.
ISTQB	International Software Testing Qualifications Board; weltweit anerkannte Zertifizierung für Testwissen.
Regression Testing	Wiederholung von Tests nach Änderungen, um sicherzustellen, dass bestehende Funktionen nicht beeinträchtigt wurden.
Shift Left	Prinzip, Testaktivitäten früh im Entwicklungsprozess zu beginnen.
System Testing	Testebene, die das vollständige, integrierte System im produktionsähnlichen Umfeld prüft.
Testfall	Detaillierte Beschreibung von Eingaben, Schritten und erwarteten Ergebnissen zur Prüfung einer bestimmten Funktion.
Testplan	Dokument, das Umfang, Ressourcen, Zeitplan, Strategie und Kriterien für die Tests festlegt.
UAT (User Acceptance Testing)	Benutzerabnahmetest; siehe Acceptance Testing.
Unit Testing	Testebene, die kleinste Einheiten (z. B. Funktionen) isoliert prüft; meist durch Entwickler.
Validation	„Bauen wir das richtige Produkt?“ Prüft, ob die Software die tatsächlichen Nutzerbedürfnisse erfüllt.
Verification	„Bauen wir das Produkt richtig?“ Prüft, ob die Software gemäß den Spezifikationen gebaut wurde.
White-Box-Testing	Testansatz mit Kenntnis des Quellcodes; prüft interne Struktur, Pfade und Zweige.

---

Quellen

• Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall.
• Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• IEEE Std 829-2008. IEEE Standard for Software and System Test Documentation.
• ISO/IEC 25010:2011. Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models.
• ISTQB (2023). Standard Glossary of Terms Used in Software Testing, Version 3.5.
• Myers, G. J. (1979). The Art of Software Testing. John Wiley & Sons.
• NATO Science Committee (1969). Report on the Conference on Software Engineering, Garmisch-Partenkirchen.
• Weinberg, G. M. (1971). The Psychology of Computer Programming. Van Nostrand Reinhold.

---

Fazit: Vom Anfänger zum kritischen Prüfer

Dieser Kurs hat Sie von den historischen Wurzeln des Softwaretests über die begrifflichen Grundlagen bis hin zu konkreten Techniken des Testfallentwurfs geführt. Sie kennen nun die vier Testebenen, unterscheiden funktionale von nicht-funktionalen Tests, verstehen den Unterschied zwischen Black-Box und White-Box und wissen, wie ein Testplan aufgebaut ist.

Das Ziel war nicht, Sie zu einem „fertigen“ Tester zu machen – das wäre nach zwei Wochen anmaßend. Aber Sie haben das Fundament gelegt, um:

• eigene Testfälle systematisch zu entwerfen,
• Testprozesse in Entwicklungsprojekten einzuordnen,
• Fachgespräche über Softwarequalität zu führen,
• und sich gezielt weiterzuentwickeln – etwa durch eine ISTQB-Zertifizierung oder praktische Erfahrung in Open-Source-Projekten.

In einer Zeit, in der digitale Systeme immer tiefer in unser Leben eindringen, wird die Fähigkeit, ihre Qualität zu prüfen und ihre Grenzen zu verstehen, zu einer Kernkompetenz – nicht nur für Ingenieure, sondern für alle, die Verantwortung für die Gestaltung unserer digitalen Welt übernehmen wollen.