Testkonzept

HA5 · Testkonzept · Fallstudie GroceryMate · CTFL 4.0.2 · Kap. 5

Projekt: GroceryMate Features: GM-F01 · GM-F02 · GM-F03 Testfälle: 9 TC (3 je Feature) · 100 % automatisierbar Testkonzept A4: 5 Seiten (HA5 Testkonzept A4) Standard: CTFL 4.0.2 / IEEE 829-2008 Status: Abgeschlossen Erstellt: 16.03.2026 Letzte Aktualisierung: 31.03.2026
Reihenfolge und Begrifflichkeit — CTFL vs. IEEE/ISO

Reihenfolge. Im CTFL 4.0.2 kommt Kapitel 4 (Testentwurf inkl. Testfälle) vor Kapitel 5 (Testplanung inkl. Testkonzept) — das ist didaktisch gedacht (zuerst Techniken, dann Management), nicht die Prozessvorgabe eines Normenwerks. IEEE 829-2008 und ISO/IEC/IEEE 29119-3 beschreiben die praktische Reihenfolge: Test Plan (strategische Planung, inhaltlich dem Testkonzept vergleichbar) → Test Design Specification (Testfallentwurf) → Test Case Specification (konkrete Testfälle). In Projekten gilt typisch Testkonzept → Testfallentwurf, oft iterativ. Fazit: Beide Reihenfolgen sind korrekt — mit unterschiedlichem Zweck (Lernpfad vs. Norm/Praxis).

Diese Website. Genau die praxisnahe Reihenfolge (zuerst Konzept, dann ausführliche Testfälle) ist hier umgesetzt: In der Hausaufgaben-Navigation oben kommst du zuerst zum Testkonzept, danach zum Testfallentwurf. Die Ziffern in den Dateinamen (z. B. 04… und 05…) sind nicht dieselbe „wer steht zuerst“-Sortierung — wenn du unsicher bist, nimm die Nav und die Dokumentenkette auf den Seiten als Maßstab, nicht die alphabetische Ordner-Sortierung.

Begrifflichkeit. Testkonzept ist die offizielle deutsche Bezeichnung im CTFL (Kap. 5.1.1, ISTQB); Test Plan ist der übliche IEEE-Begriff im Englischen. Die D.A.CH-Lokalisierung trennt so das Dokument (Testkonzept) von der Aktivität Testplanung (Kap. 5.1). Bis CTFL 3.0 wurde teils „Testplan“ für das Dokument genutzt; ab CTFL 3.1 ist Testkonzept geführt. In der Praxis sind beide Formulierungen verständlich; für ISTQB-Prüfungen ist Testkonzept die maßgebliche deutsche Form.

Sektion 1

Produktanalyse

Analyse des Testobjekts und der neuen Features, die im nächsten Release getestet werden sollen.

Was ist eine Produktanalyse?
Die Produktanalyse beschreibt, was getestet wird. Sie umfasst: Zielsetzung des Produkts, Zielgruppe, technische Spezifikationen und die Features, die im Test-Scope liegen. Basis: Testbasis-Analyse aus HA4 (CTFL Kap. 4.1). Die Produktanalyse ist Teil des Testkonzepts (CTFL Kap. 5.1.1).

Zielsetzung

GroceryMate ist ein Online-Lebensmittel-Shop, der Nutzern ermöglicht, Produkte zu suchen, zu bewerten, in den Warenkorb zu legen und zu bestellen. Das nächste Release erweitert die Plattform um drei neue Funktionen: ein Bewertungssystem, eine Altersverifikation für alkoholische Produkte und dynamische Versandkosten basierend auf dem Bestellwert.

Zielgruppe (Nutzerbasis)

Primäre Nutzer
Endkunden ab 18 Jahren (aufgrund Altersverifikation für Alkohol), die online Lebensmittel bestellen möchten.
Registrierte Nutzer
Eingeloggte Nutzer mit erweiterten Funktionen: Bewertungen schreiben, Checkout durchführen, Versandkosten sehen.
Gast-Nutzer
Nicht eingeloggte Besucher mit eingeschränktem Zugriff: Produkte ansehen, aber keine Bewertungen abgeben oder bestellen.

Benutzeranalyse (Kurz)

Demografie: Erwachsene Endkundinnen und Endkunden (Schwerpunkt typischerweise 25–45 Jahre), deutschsprachig; keine spezielle IT-Voraussetzung. Technikaffinität: niedrig bis mittel — alltägliche Browser-Nutzung, kein Entwickler-Publikum. Nutzungsszenarien: Wocheneinkauf mit größerem Warenkorb; spontane Kleinbestellungen; vor dem Kauf Bewertungen lesen; für GM-F02 Zugriff auf alkoholische Kategorie nur nach erfolgreicher Altersprüfung.

Bestehende Funktionalität (vor GM-F01 · GM-F02 · GM-F03)

Der Shop war bereits nutzbar mit u. a. Produktsuche und -navigation, Login/Registrierung, Warenkorb und Checkout-Grundfluss. Dieses Testkonzept bezieht sich auf die drei neuen Features und deren Integration in diese bestehenden Abläufe — kein vollständiger Regressionstest der gesamten Altfunktionalität.

Hardware- und Software-Spezifikationen

KategorieSpezifikation
BrowserChrome, Firefox, Safari, Edge (neueste 2 Versionen)
GeräteDesktop (Windows, macOS), Mobile (iOS, Android), Tablets
Backendgrocerymate.masterschool.com, Session-Management (Cookie)

Produktfunktionen (Features im Test-Scope)

GM-F01
Bewertungssystem für Produkte
Eingeloggte Nutzer können Produkte mit 1–5 Sternen bewerten und optionales schriftliches Feedback hinterlassen. Max. eine Bewertung pro Nutzer und Produkt. Durchschnittsbewertung wird auf Produktseite angezeigt.
GM-F02
Altersverifikation für alkoholische Produkte
Beim ersten Aufruf der Kategorie /store erscheint ein Geburtsdatum-Modal. Nutzer unter 18 Jahren erhalten keinen Zugriff. Verifikation ist session-basiert (kein erneutes Modal innerhalb der Session).
GM-F03
Versandkosten
Versandkosten entfallen ab einem Bestellwert ≥20€ (Freigrenze). Darunter fallen Versandkosten von 5€ an. Soll: Versandkostenanzeige bei Warenkorbänderungen (Erhöhen und Reduzieren) konsistent mit der Testbasis; Details und beobachtetes Verhalten siehe Risiko „Versandkosten Live-Update“ und HA4. Nur für eingeloggte Nutzer im Checkout sichtbar.

Testfälle gesamt

9 ausgearbeitete Testfälle für GM-F01 · GM-F02 · GM-F03 (je 3) — vollständig spezifiziert, priorisierte Teilmenge aus der HA4-Testbasis (Testbasis-Analyse A4, inhaltlich zur HA4 Anforderungsanalyse). Techniken: EP, BVA, UC (CTFL Kap. 4.2). Referenz: Web HA5 Testfallentwurf · A4 HA5 Testfallentwurf A4 (12 Seiten: 3 Übersichtsseiten + 9 TC). Weitere Testfragen aus HA4 bleiben für eine Erweiterung des Testsets verfügbar.
Abgleich mit ISO/IEC/IEEE 29119-3 / IEEE 829: dokumentierter Umfang entspricht dem aktuellen HA5 Testfallentwurf (Web) und HA5 Testfallentwurf A4.

Sektion 2

Teststrategie

Festlegung der Testarten, Priorisierung und des Testumfangs (Scope).

Was ist eine Teststrategie?
Die Teststrategie beschreibt wie getestet wird. Sie definiert:
  • Welche Testarten kommen zum Einsatz? (Funktional, Regression, Performance, etc.)
  • Was liegt im Scope, was außerhalb?
  • Welche Features haben Priorität?
Referenz: CTFL Kap. 5 (Testmanagement)

Testumfang (Scope)

Im Umfang enthalten
  • Bewertungssystem (GM-F01): 1–5 Sterne, Textfeld optional, Login-Pflicht, Duplikatprüfung
  • Altersverifikation (GM-F02): Geburtsdatum-Modal, 18+ Prüfung, Session-Persistenz
  • Versandkosten (GM-F03): Freigrenze, Live-Update, Login-Pflicht
  • Integration mit bestehenden Features: Login/Registrierung, Warenkorb, Checkout
Außerhalb des Umfangs
  • Technik: Backend-Datenbank, Zahlungsabwicklung (externe Schnittstelle), Verifizierung von E-Mail-Adressen — werden nicht separat getestet.
  • Sicherheit: Kein gezielter Test auf Angriffs-Szenarien
  • Barrierefreiheit: Kein vollständiges WCAG-Audit
  • Browser: Schwerpunkt Chrome, andere Browser nur bei Bedarf

Testarten (CTFL 4.0.2 Kap. 2.2.2 — vier kanonische Testarten)

TestartBeschreibungAnwendung
Funktionaler TestPrüfung, ob Features gemäß Spezifikation funktionierenAlle 3 Features (GM-F01 · GM-F02 · GM-F03)
Nicht-funktionaler TestPerformance, Usability, KompatibilitätGM-F03 (Versandkosten-Update) · GM-F02 (Modal)
Black-Box-TestTest auf Basis von Spezifikation ohne CodekenntnisAlle Features
White-Box-TestNicht angewendet (kein Code-Zugriff im Scope)

Testentwurfs-Techniken (CTFL 4.0.2, Kap. 4.2)

Äquivalenzklassenbildung (EP) · Grenzwertanalyse (BVA) · Anwendungsfalltest (UC).

Hauptrisiken und Maßnahmen

Risiko: Versandkosten Live-Update (unidirektional)
Details: In der Testbasis (HA4) dokumentiertes Verhalten: Anzeige der Versandkosten aktualisiert beim Erhöhen des Warenkorbwerts zuverlässig; beim Reduzieren wurde eine Abweichung vom erwarteten Soll beobachtet (u. a. Reload nötig).
Maßnahme: Prüfung und Nachweis u. a. mit TC-F03.F3.2 (siehe HA5 Testfallentwurf / HA5 Testfallentwurf A4); ggf. Fehlerdokumentation in HA6.
Risiko: Zeichenlimit Bewertungs-Textfeld unklar
Details: Bekannte Lücke in HA4 (F6/AC6; siehe HA4 Anforderungsanalyse und Testbasis-Analyse A4).
Maßnahme: Kein eigener TC in den 9 spezifizierten HA5-Fällen; Klärung / Risiko siehe Abschnitt „Bekannte Lücken & Abstimmung (HA4 / PO)“.
Risiko: 2. Bewertung — Block oder Update?
Details: Bekannte Lücke in HA4 (Grenzfälle; siehe HA4 Anforderungsanalyse und Testbasis-Analyse A4).
Maßnahme: Kein eigener TC in den 9 spezifizierten HA5-Fällen; Klärung / Risiko siehe Abschnitt „Bekannte Lücken & Abstimmung (HA4 / PO)“.

Bekannte Lücken & Abstimmung (HA4 / PO)

Restrisiken & Vorgehen
Verbleibende Spezifikationslücken aus der Testbasis-Analyse (HA4) sind benannt; Priorisierung und Klärung erfolgen mit dem Product Owner. Die geplanten Tests decken die drei neuen Features ab; einzelne Lücken werden risikobasiert mitgesteuert.
Sektion 3

Testziele

Messbare Ziele, die durch die Tests erreicht werden sollen.

Was sind Testziele?
Testziele beschreiben was erreicht werden soll. Sie sind messbar (z. B. „100 % der geplanten Testfälle ausgeführt“, „≥89 % bestanden“) und dienen als Erfolgskriterium für den Testprozess. Referenz: CTFL Kap. 5.1 (Testplanung).

Primäre Ziele

  • Alle 3 Features funktionieren gemäß Spezifikation
  • Akzeptanzkriterien aus Testbasis-Analyse erfüllt
  • Versandkosten: Anzeige und Plausibilität bei Warenkorbänderungen (Erhöhen und Reduzieren) entsprechen den Akzeptanzkriterien aus der Testbasis; Prüfung u. a. mit TC-F03.F3.2 (siehe HA5 Testfallentwurf / HA5 Testfallentwurf A4). Abweichungen werden risikobasiert dokumentiert (siehe Risiken).

Erwartete Ergebnisse (messbar)

MetrikZiel
Testfall-Ausführungsquote100 %
Testfall-Erfolgsquote≥ 89 %
Kritische Fehler (Severity 1)0
Hochprioritäre Fehler (Severity 2)Alle behoben
Sektion 4

Testkriterien

Entry, Exit und Suspension Criteria — wann wird mit Tests begonnen, wann abgeschlossen, wann pausiert?

Was sind Testkriterien?
Testkriterien legen fest, unter welchen Bedingungen getestet wird:
  • Entry Criteria: Voraussetzungen, um mit Tests zu starten
  • Exit Criteria: Bedingungen, um Tests abzuschließen
  • Suspension Criteria: Gründe, um Tests zu pausieren
Referenz: CTFL Kap. 5.2 (Testüberwachung und -steuerung)

Entry Criteria (Startkriterien)

Bedingungen, die erfüllt sein müssen, bevor Tests beginnen können:

Exit Criteria (Abnahmekriterien)

Bedingungen, die erfüllt sein müssen, um Tests abzuschließen:

  • Alle 9 TCs gemäß HA5 Testfallentwurf und HA5 Testfallentwurf A4 ausgeführt (100 %)
  • Mindestens 8/9 TCs bestanden (≥89 %)
  • Alle Fehler dokumentiert
  • Testprotokoll vollständig
  • Abschlussbericht erstellt

Suspension Criteria (Aussetzungskriterien)

Gründe, um Tests zu pausieren:

  • grocerymate.masterschool.com nicht erreichbar
  • Login funktioniert nicht
  • Kritischer Blocker (z.B. /store nicht zugänglich)
  • Gesundheitliche Gründe
Sektion 5

Ressourcenplanung

Personal, Hardware, Software und Tools, die für die Tests benötigt werden.

Warum Ressourcenplanung?
Eine klare Ressourcenplanung stellt sicher, dass alle benötigten Mittel (Personal, Geräte, Tools) verfügbar sind. Ohne ausreichende Ressourcen können Tests nicht erfolgreich durchgeführt werden.

Personal & Rollen

RolleVerantwortungPersonen
QA Tester (Student)Testdurchführung (9 TCs laut HA5 Testfallentwurf / HA5 Testfallentwurf A4), Bug-Dokumentation, Abschlussbericht1
Reviewer (Mentor)Review Testprotokoll, Feedback (optional, minimal)0–1

Hardware

  • Desktop/Laptop (Windows, macOS oder Linux)
  • Optional: Smartphone für Mobile-Tests

Software & Tools

  • Browser: Chrome (primär)
  • Dokumentation: Excel oder vergleichbare Office-Anwendung
  • Screenshots: Snipping Tool / macOS Screenshots
  • Optional: Browser DevTools (Debugging)
Sektion 6

Testumgebung

Beschreibung der technischen Umgebung, in der Tests durchgeführt werden.

Was ist eine Testumgebung?
Die Testumgebung ist die Infrastruktur, auf der getestet wird. Sie sollte möglichst nah an der Produktionsumgebung sein, um realistische Testergebnisse zu erzielen. Referenz: CTFL Kap. 5.3 (Testumgebung).

Umgebungen

UmgebungZweckURL
LIVEProduktiv-System (manuelle Funktionstests)grocerymate.masterschool.com

Testdaten

Konten & Produkte
  • 1 Test-Account (eingeloggt)
  • Gast-Modus (nicht eingeloggt)
  • Produkte auf grocerymate.masterschool.com (bereits vorhanden)
Szenarien
  • Warenkorb: <20€, =20€, >20€
  • Geburtsdaten: 17 J. 364 T., =18 J., >18 J.
  • Browser: Chrome (primär), optional Firefox/Safari
Sektion 7

Zeitplan und Aufwandsschätzung

Zeitlicher Ablauf der Testaktivitäten mit Start- und Enddaten sowie geschätztem Aufwand.

Warum ein Zeitplan?
Ein Zeitplan gibt dem Team Struktur und ermöglicht es, Fortschritt zu messen. Aufwandsschätzungen helfen bei der Ressourcenplanung und identifizieren Engpässe frühzeitig.

Zeitplan

AktivitätDatumUmgebungVerantwortlichAufwand (h)
Testvorbereitung + Testdurchführung GM-F01 (3 TC)Fr 20.03.26LIVEQA Tester4
Testdurchführung GM-F02 + GM-F03 (6 TC)Sa 21.03.26LIVEQA Tester5
Bug-Dokumentation + TestabschlussberichtMo 23.03.26QA Tester3
GESAMT:12 h

Testzeitraum: 20.–23.03.2026 · 12 Stunden · 3 Tage · Solo-Projekt

Sektion 8

Test-Deliverables (Liefergegenstände)

Dokumente und Artefakte, die während des Testprozesses erstellt und geliefert werden.

Was sind Deliverables?
Deliverables sind die messbaren Ergebnisse des Testprozesses. Sie dokumentieren, was getestet wurde, welche Fehler gefunden wurden und ob die Testziele erreicht wurden. Referenz: CTFL Kap. 5.4 (Test-Deliverables).

Dokumente

DeliverableBeschreibungVerantwortlich
Testkonzept (HA5)Vollständiger Testplan mit 8 Abschnitten (IEEE 829-2008 / CTFL 4.0.2); A4-Dokument 5 Seiten (HA5 Testkonzept A4)QA Tester
Testbasis-Analyse (HA4)3 Features (GM-F01 · GM-F02 · GM-F03) nach ISO/IEC/IEEE 29119-3 — HA4 Testbasis-Analyse A4, Web HA4 Anforderungsanalyse (bereits vorhanden)QA Tester
Testfallentwurf (HA5)9 vollständig spezifizierte TCs (3 je Feature), Ziel: hohe Automatisierbarkeit (im Entwurf 100 %), Traceability zu HA4 — HA5 Testfallentwurf, HA5 Testfallentwurf A4 (12 Seiten) (bereits vorhanden)QA Tester
TestprotokollDurchführungs-Log der 9 TCs mit Status (Pass/Fail), Screenshots bei Fehlern — HA6 Testprotokoll A4QA Tester
Bug-ReportsFehlerberichte mit Screenshots, Steps to Reproduce, Severity (falls Fehler gefunden) — HA6 Fehlerbericht A4 (Musterdokument BUG-001 / BUG-002)QA Tester
TestabschlussberichtZusammenfassung: Ausführungsrate, Pass-Rate, gefundene Fehler, Empfehlungen — HA6 Testabschlussbericht A4QA Tester

Metriken (im Abschlussbericht)

Test Execution Rate (%)
Anteil ausgeführter Testfälle — Ziel: 100 %
Pass Rate (%)
Anteil bestandener Testfälle — Ziel: ≥ 89 %
Defect Density
Anzahl gefundener Fehler je Feature
Defect Distribution
Verteilung der Fehler nach Schweregrad (Severity 1–4)
Retest Success Rate (%)
Anteil erfolgreich nachgetesteter Fehler
Coverage (Akzeptanzkriterien %)
Abgedeckte AC — Ziel: 100 %