Testing

Viaora 1.0 Testleitfaden

Dieser Leitfaden ist der kanonische Pfad für QA, Sales und Release-Verifikation. Er definiert, was bewiesen werden muss, wo der Start liegt und woran Erfolg erkennbar ist.

Was Tester beweisen müssen

  • Konfigurationsänderungen aus dem Builder werden nach dem Publish in Guest genauso gerendert.
  • Advertiser-eigener Content bleibt über Detail-, Empfehlungs- und Journey-Kontexte hinweg konsistent.
  • Map, Journey, Services und Footer-Navigation bestehen echte Browser-Interaktionen und nicht nur synthetische Tests.
  • Ops kann das System ohne versteckte Einmalschritte oder undokumentierte Abhängigkeiten bedienen.

Kanonischer Durchlauf

  1. Ops legt ein Hotel an oder öffnet es, prüft die zugeordneten Advertiser und startet den Hotel-Builder.
  2. Im Hotel-Builder werden Identity, Services und mindestens ein Discover- oder Journey-Element geändert und anschließend in Draft und Live-Preview geprüft.
  3. Im Advertiser-Builder werden Short Copy und Long Copy angepasst, veröffentlicht und auf die Hotel-Relation hin verifiziert.
  4. In der Guest PWA werden Dashboard, Highlights, Discover, Services und Advertiser-Detail mit funktionierender Footer-Navigation geprüft.
  5. Der Release-Check bestätigt abschließend, dass Builder, Guest und Core auf demselben beabsichtigten Deploy-Stand laufen.

Pflichtflächen im 1.0-Test

  • Ops / Hotelanlage und Advertiser-Zuordnung
  • Hotel-Builder inklusive Draft und Live-Ansicht
  • Advertiser-Builder inklusive Publish
  • Guest PWA mit Footer-Navigation und Routenwechsel
  • Deployment- und Versionsabgleich zwischen Frontend und Core

B16 Full-System Gate

Der wiederholbare Gate pnpm run gate:b16:full-system legt isolierte Demo-Daten an, publiziert Hotel und Advertiser, verknüpft sie und prüft danach Admin, Builder und Guest im Browser. Der Lauf vom 5. Juni 2026 ist mit PASS dokumentiert.

  • Core API: neues Demo-Hotel, drei Demo-Advertiser, Memberships und Publish-Readback
  • Admin/Ops: Hotel-Detail mit realem Tenant-Kontext
  • Hotel-Builder: VBuilder-Preview gegen denselben Core-/Builder-Contract
  • Advertiser-Builder: Preview aus canonical Draft/Published-Daten ohne lokalisierte Objekt-Leaks
  • Guest PWA: Home, Category, Detail, Map-Sheet und Offline-Fallback als Browser-Screenshots

B17 Preview Gate

Nach dem B16-Gate werden die Web-Flächen als Vercel Preview deployt. Der Stand vom 6. Juni 2026 ist in docs/reports/b17-vercel-preview-deploy-2026-06-06.md dokumentiert und bleibt die Basis für Lighthouse und PR-Readout.

  • Guest Preview: Health, Lago-Garden-Map und Offline-Inhalte über geschützte Vercel Preview geprüft
  • Docs Preview: Release Notes und Testing-Handbuch auf B16/B17-Stand gebracht
  • Admin/Ops Preview: Health erreichbar
  • Hotel Builder Preview: Health erreichbar und Analytics-Konfiguration aktiv
  • Advertiser Builder Preview: Health erreichbar und Analytics-Konfiguration aktiv

Nicht automatisch ein Bug

Wenn für alte persistierte Daten noch eine interne Kompatibilitätsbrücke existiert, ist das nicht automatisch ein Produktfehler. Ein Fehler ist es erst dann, wenn daraus sichtbarer Drift oder eine zweite aktive Authoring-Truth entsteht.