Was ist HA4? In der Aufgabenstellung heißt die Tätigkeit oft „Anforderungsanalyse“ — fachlich (CTFL/ISO) ist das eine Testbasis-Analyse: vage Anforderungen aufnehmen, reales Verhalten prüfen, Testbedingungen und Akzeptanzkriterien ableiten, bekannte Lücken und Restrisiken dokumentieren. Das entspricht ISO/IEC/IEEE 29119-3 und CTFL Testanalyse (Kap. 4.1). Kurz: Aufgabenbegriff „Anforderungsanalyse“ · Standardbegriff „Testbasis-Analyse“ — hier meinen beide dieselbe Arbeit aus Tester-Sicht (nicht IREB-Requirements-Engineering).
Begriffserklärung — Anforderungsanalyse vs. Testbasis-Analyse
Anforderungsanalyse (IREB / Requirements Engineering)
Perspektive des Requirements Engineers: Anforderungen werden erhoben, strukturiert, dokumentiert und validiert — bevor die Software existiert.
- Stakeholder befragen
- User Stories / Use Cases schreiben
- Anforderungen priorisieren und freigeben
Testbasis-Analyse (CTFL Kap. 4.1 · ISO/IEC/IEEE 29119-3)
Perspektive des Testers: Vorhandene Anforderungen (die Testbasis) werden ausgewertet, um daraus Testbedingungen, Akzeptanzkriterien und Grenzfälle abzuleiten.
- Was muss getestet werden? (Testbedingungen)
- Wann gilt es als korrekt? (Akzeptanzkriterien)
- Wo kann es schiefgehen? (Grenzfälle, Risiken)
Schema — Aufbau einer Testbasis-Analyse pro Feature (Vorlage)
Feature
Name und eindeutige ID des Features. Referenz zur Anforderung oder User Story.
Vage Anforderung
Die ursprünglich formulierte (oft unvollständige) Anforderung — Ausgangspunkt der Analyse.
Testfragen & Antworten
Mind. 3 testing-relevante Fragen, die aus der Anforderung entstehen, und die gefundenen Antworten (aus der Anwendung oder Spezifikation).
Akzeptanzkriterien
Konkrete, prüfbare Bedingungen: wann gilt das Feature als korrekt implementiert? Grundlage für Testfälle.
Grenzfälle & Risiken
Rand- und Fehlerfälle, die besondere Aufmerksamkeit benötigen — typischerweise Eingaben an Grenzen, Rollenwechsel, unerwartete Zustände.
Bekannte Lücken (in Tests geprüft)
Stellen, an denen die Spezifikation noch Lücken lässt — mit Verweis darauf, wie sie adressiert werden (z. B. geplante Testfälle, Abstimmung mit PO). So bleibt die Analyse abgeschlossen, ohne Unklarheiten zu verschweigen.
Ausarbeitung — GroceryMate · Drei neue Features (Testbasis-Analyse / Anforderungsanalyse aus Tester-Sicht)
Feature 1
Bewertungssystem für Produkte
Vage Anforderung: 5-Sterne + optionales Textfeld
Testfragen & Antworten
- F1Funktioniert das 5-Sterne-System (1 Stern Minimum)? Ja - 1 Stern möglich
- F1Funktioniert das 5-Sterne-System (5 Sterne Maximum)? Ja - 5 Sterne möglich
- F2Wer darf bewerten — alle Nutzer oder nur eingeloggte? Nur eingeloggte Nutzer; Gäste haben keine Bewertungsoption
- F4Ist das Textfeld Pflicht oder optional? Optional - Bewertung nur mit Sternen (ohne Text) möglich
- F3Wird die Durchschnittsbewertung visuell angezeigt? Ja - als ausgefüllte Sterne auf Produktseite
- F5Kann ein Nutzer dasselbe Produkt mehrfach bewerten? Nein - max. 1 Bewertung/Nutzer/Produkt
- F6Gibt es eine maximale Zeichenanzahl für Feedback? Nicht in Anforderung spezifiziert - muss im Test ermittelt werden
Akzeptanzkriterien
| AC1 | Eingeloggter Nutzer kann mit 1–5 Sternen bewerten |
| AC2 | Gast ohne Login erhält keinen Zugang zur Bewertungsfunktion |
| AC3 | Durchschnittsbewertung wird auf Produktseite angezeigt |
| AC4 | Textfeld ist optional - Bewertung ohne Text wird akzeptiert |
| AC5 | Max. eine Bewertung pro Nutzer und Produkt |
| AC6 | Textfeld hat maximale Zeichenanzahl (im Test zu ermitteln) |
Grenzfälle
Stern = 0, Stern = 6
Gast → Bewerten
Leeres Textfeld
0 Bewertungen, Rundung, Halber Stern
2. Bewertung
Max. Textlänge
Bekannte Lücken (in Tests geprüft)
- Rundungsregel — wird gegen Anzeige/AC geprüft
- Zweite Bewertung: Block oder Update?
- Zeichenlimit Textfeld — explorativ / in späteren Tests
Feature 2
Altersverifikation für alkoholische Produkte
Vage Anforderung: Modal bei Kategorie, 18+
Testfragen & Antworten
- F1Wird jemand mit 17J 364T korrekt abgelehnt (1 Tag vor 18)? Ja - Zugriff verweigert (tagesgenau)
- F1Wird jemand mit exakt 18 Jahren korrekt zugelassen? Ja - Store freigegeben
- F2Erscheint das Modal beim ersten /store Aufruf? Ja - vor Produktanzeige
- F3Muss das Modal bei jedem Seitenaufruf erneut bestätigt werden? Nein - innerhalb Session nicht erneut
- F6Wie lange bleibt die Verifikation gespeichert? Nicht spezifiziert - im Test zu ermitteln
- F4Wird Datumsformat (TT.MM.JJJJ) verlangt? Ja - Modal zeigt Datumsfelder
- F5Was passiert bei ungültigem Datum (z.B. 31.02.)? Nicht spezifiziert - im Test zu ermitteln
Akzeptanzkriterien
| AC1 | Geburtsdatum < 18 Jahre → Zugriff verweigert |
| AC2 | Geburtsdatum ≥ 18 Jahre → Store freigegeben |
| AC3 | Modal erscheint beim ersten Aufruf von /store vor Produkten |
| AC4 | Innerhalb derselben Session kein erneutes Modal |
| AC5 | System verlangt Geburtsdatum im Datumsformat |
| AC6 | Ungültige Datumseingaben werden abgefangen |
| AC7 | Verifikations-Status hat definierte Gültigkeitsdauer |
Grenzfälle
17J 364T, =18J
Browser-Refresh, Tab-Wechsel
Session-Ende, Browser-Neustart
Ungültiges Datum (31.02.)
Bekannte Lücken (in Tests geprüft)
- Session-Dauer — im Test zu verifizieren
- Cookie-Dauer — im Test zu verifizieren
- Ungültiges Datum — Fehlerverhalten im Test prüfen
Feature 3
Versandkosten
Vage Anforderung: Freigrenze 20€, darunter 5€
Testfragen & Antworten
- F1Wird bei 19,99€ korrekt 5€ Versandkosten berechnet? Ja - 5€ Versandkosten
- F1Wird bei exakt 20€ korrekt 0€ Versandkosten berechnet? Ja - 0€ Versandkosten
- F1Wird bei >20€ korrekt 0€ Versandkosten berechnet? Ja - 0€ Versandkosten
- F2Werden 5€ angezeigt UND korrekt zur Gesamtsumme addiert? Ja - Anzeige "5€" + Gesamtsumme = Warenkorb + 5€
- F3Aktualisieren sich Versandkosten beim Hinzufügen (≥20€)? Ja - automatisch 0€
- F3Aktualisieren sich Versandkosten beim Entfernen (<20€)? NEIN — ohne Reload keine Abwärtsaktualisierung; Abweichung vom erwarteten Soll, Prüfung in HA5/HA6
- F4Ist /checkout ohne Login zugänglich? Nein - Weiterleitung /auth
Akzeptanzkriterien
| AC1 | Bestellwert ≥ 20€ → Versandkosten = 0€ |
| AC2 | Bestellwert < 20€ → Versandkosten = 5€ |
| AC3 | Versandkosten aktualisieren sich bei Warenkorbänderungen |
| AC4 | Checkout ohne Login → Weiterleitung zu /auth |
| AC5 | Versandkosten werden angezeigt und zur Gesamtsumme addiert. |
Grenzfälle
19,99€, =20€, 20,01€
Hinzufügen → ≥20€
Entfernen → <20€
Gast ohne Login
Bekannte Lücken (in Tests geprüft)
- Live-Update Versandkosten: in der Erkundung nur bei Erhöhung des Warenkorbwerts zuverlässig; bei Reduktion Prüfung mit TC-F03.F3.2 / ggf. Fehlerbericht (HA6)
Zusammenfassung — Analysestatus aller Features
| Feature | Kernverhalten | Grenzfälle identifiziert | Bekannte Lücken | Status |
|---|---|---|---|---|
| Bewertungssystem | 1–5 Sterne, optionales Textfeld, nur eingeloggte Nutzer, 1 Bewertung/Produkt | Gast, Mehrfachbewertung, Textlänge | Rundung, 2. Bewertung, Textlänge — in HA5/HA6 adressiert | Abgeschlossen |
| Altersverifikation | Geburtsdatum-Modal auf /store, 18+-Grenze, session-basiert | 17J 364T, exakt 18J (BVA), Session/Refresh, Tab-Wechsel | Session/Cookie-Dauer, ungültiges Datum — in Tests verifiziert | Abgeschlossen |
| Versandkosten | Freigrenze 20€, Versand 5€, Live-Update (Hinweis aus Erkundung), Login erforderlich | Wert 20€, 19,99€, 20,01€, leerer Warenkorb, Gast | Live-Update bei Reduktion — bekanntes Verhalten; Prüfung HA5/HA6 | Abgeschlossen |
Aufbau dieser Seite — Leseanleitung
① Oben — Theorie
Erklärt den Unterschied zwischen Anforderungsanalyse (IREB / RE) und Testbasis-Analyse (CTFL / ISO) — und warum die HA4-Aufgabe aus Tester-Sicht dem Standard ISO/IEC/IEEE 29119-3 entspricht, auch wenn die Aufgabenstellung „Anforderungsanalyse“ sagt.
② Mitte — Schema
Die 6 Felder einer professionellen Testbasis-Analyse als wiederverwendbare Vorlage — das generische Muster für jede zukünftige Anforderungsanalyse aus Tester-Sicht.
③ Unten — HA4 Analyse
Alle drei Features ausgefüllt nach diesem Schema: Testfragen & Antworten, Akzeptanzkriterien, Grenzfall-Tags, bekannte Lücken — plus Zusammenfassungstabelle. Dasselbe inhaltliche Muster liegt dem A4-Formular HA4 Testbasis-Analyse A4 zugrunde.
Hinweis zu bekannten Lücken: Die dokumentierten Lücken sind kein Widerspruch zum Status „Abgeschlossen“: Die Testbasis ist für das weitere Vorgehen (HA5/HA6) vollständig genug; verbleibende Punkte sind benannt und werden über Tests oder Abstimmung adressiert — transparent für Review und PO.