# Portabilitaet: UNIVERSAL
# Zuletzt validiert: 2026-01-28 (Gemini)
# Naechste Pruefung: 2027-01-28
# Quellen: [skills/_protocols/system-testverfahren.md]

B-O-E TESTVERFAHREN (BEOBACHTUNG, OUTPUT, ERFAHRUNG)
====================================================

Stand: 2026-01-28

HINTERGRUND: GANZHEITLICHES TESTEN
----------------------------------
Unit-Tests pruefen Funktionen. Integration-Tests pruefen Schnittstellen. Aber wer prueft, ob das System "gut" ist?
Das B-O-E Verfahren ist ein Framework, um KI-Agentensysteme (LLM-OS) ganzheitlich zu bewerten.

DIE DREI DIMENSIONEN
--------------------

### B - BEOBACHTUNG (Observation)
**Perspektive:** Von Aussen (Statisch).
**Frage:** "Sieht das System gesund aus?"
**Tests:**
- Existieren alle Pflichtordner?
- Sind Dokumente vorhanden und nicht leer?
- Stimmen die Dateigroessen?
**Natur:** Objektiv, automatisierbar, quantitativ.

### O - OUTPUT (Function)
**Perspektive:** Black Box (Dynamisch).
**Frage:** "Tut es, was es soll?"
**Tests:**
- CLI-Befehl absetzen -> Output pruefen.
- Task erstellen -> DB pruefen.
- Fehler provozieren -> Error-Handling pruefen.
**Natur:** Deterministisch, funktional.

### E - ERFAHRUNG (User Experience)
**Perspektive:** User / Agent (Subjektiv).
**Frage:** "Fuehlt es sich gut an?"
**Tests:**
- Ist die Hilfedatei verstaendlich?
- Finde ich mich in der Ordnerstruktur zurecht?
- Antwortet das System hilfreich?
**Natur:** Qualitativ, "Soft Skills".

WARUM ALLE DREI?
----------------
Ein System kann technisch perfekt sein (B & O gut), aber fuer den User unbenutzbar (E schlecht).
Oder es kann toll aussehen (B gut), aber abstuerzen (O schlecht).
Nur die Kombination gibt ein wahres Bild der "Systemgesundheit".

SIEHE AUCH
----------
skills/_protocols/system-testverfahren.md   Test-Definitionen
tools/testing/run_external.py               Test-Runner
