Abnahmetest für Odoo: Testdatenbank und Szenarien

Der Abnahmetest prüft, ob Odoo mit Ihren Daten so arbeitet, wie es im Projekt vereinbart wurde. Er läuft in einer Kopie der Produktivdatenbank und endet mit einem unterschriebenen Protokoll. Wie Sie je Hostingmodell eine solche Kopie bereitstellen, steht im Artikel Testumgebung für Odoo; hier geht es um den Ablauf des Tests.

Was Sie vorab brauchen

• Eine Testdatenbank nach Ihrem Hostingmodell, erstellt aus dem Datenstand kurz vor dem Stichtag.
• Ein Administratorkonto: Zugriffsrechte darf nach der Dokumentation 20.0 nur ein Administrator ändern.
• Die Liste Ihrer Kernprozesse aus den Anforderungen oder der Fit-Gap-Analyse, je Prozess eine verantwortliche Person.
• Testkonten für die Rollen, die im Betrieb vorkommen: Benutzer, Administrator, Leicht (Light), Portal.
• Testdaten: Kunden, Artikel, Mengen, Preise, Steuersätze, Belegvorlagen.
• Ein Zeitfenster und ein Protokollblatt. Die Prüfpunkte rund um den Stichtag sammelt die Go-live-Checkliste.

Schritt für Schritt: den Abnahmetest durchführen

Schritt 1: Testdatenbank bereitstellen

Bei Odoo Online melden Sie sich im Datenbankmanager unter odoo.com/my/databases als Datenbankadministrator an, wählen die Datenbank und die Aktion Duplizieren (Duplicate). Die Option For testing purposes ist voreingestellt und schaltet externe Aktionen ab. Duplikate verfallen nach 15 Tagen, und je Datenbank sind höchstens fünf Duplikate möglich; für mehr verweist die Seite auf den Odoo-Support. Odoo Online nimmt keine eigenen Module und keine Module aus dem Apps-Store auf.

Bei Odoo.sh setzen Sie einen Zweig auf die Stufe Staging; Odoo.sh kennt die drei Stufen Produktion, Staging und Entwicklung. Staging-Zweige arbeiten auf einer Kopie der Produktivdatenbank, sodass Sie mit Produktivdaten testen, ohne die Produktivdatenbank zu verändern. Nach der Builds-Dokumentation lädt ein Push in einen Staging-Zweig eine frische Kopie der Produktivdatenbank, und Datenbanken werden zwischen Builds desselben Zweigs nicht wiederverwendet; einen Neustart erreichen Sie über Rebuild. Staging-Datenbanken werden nach einem Monat automatisch gelöscht und nicht automatisch gesichert; manuelle Sicherungen bleiben drei Tage verfügbar, höchstens fünf am Tag.

Bei einer eigenen Installation duplizieren Sie die Datenbank im Datenbankmanager, den Sie im Browser unter der Adresse Ihres Servers mit dem Pfad /web/database/manager erreichen, und setzen dabei das Kästchen zum Neutralisieren; die Dokumentation erklärt, dass dabei die neutralize.sql-Skripte aller installierten Module ausgeführt werden. Der Zugang ist durch das Datenbank-Passwort (admin_passwd) geschützt. Die Dokumentation empfiehlt, den Datenbankmanager im Internet abzuschalten (list_db = false), keine Demodaten einzuspielen und auch im Test keine Standardpasswörter zu verwenden; für große Datenbanken ist er nicht gebaut und kann an Speichergrenzen stoßen.

Sichtbares Ergebnis: Sie öffnen die Testdatenbank in einem eigenen Browserfenster. Nach der Dokumentation zeigt eine neutralisierte Datenbank oben einen roten Hinweisbalken.

Schritt 2: Die Grenzen der Testdatenbank einplanen

Die Dokumentation nennt als nicht abschließende Liste: geplante Aktionen, ausgehende E-Mails, Banksynchronisierung, Zahlungsanbieter, Versandmethoden, IAP-Tokens und die Sichtbarkeit der Website für Suchmaschinen. Bei Odoo.sh kommen der Mail Catcher im Reiter Mails hinzu, der ausgehende E-Mails abfängt, und die Regel zu den geplanten Aktionen: Sie sind abgeschaltet; Sie lösen sie von Hand aus oder schalten sie wieder ein, und die Plattform führt sie seltener aus, wenn niemand die Datenbank nutzt.

Für Ihre Szenarien heißt das: Prüfungen, die echten E-Mail-Versand, eine echte Zahlung über einen Zahlungsanbieter oder einen Bankabruf brauchen, lassen sich in der Testdatenbank nicht abschließen. Geplante Aktionen sind ebenfalls abgeschaltet. Bei Odoo.sh-Staging lösen Sie eine Aktion von Hand aus oder schalten sie wieder ein und prüfen den Lauf so im Test; einen Lauf, der abgeschaltet bleibt, prüfen Sie nach dem Go-live in der Produktivdatenbank. Den Bankabgleich selbst üben Sie mit von Hand erfassten Umsätzen; die Banksynchronisierung liefert in der Testdatenbank keine neuen Umsätze. Setzen Sie die externen Punkte als eigenen Prüftermin unmittelbar nach dem Go-live in der Produktivdatenbank an. Bei Odoo Online und Odoo.sh mit eigener Domäne gehört zum echten Versand dazu, dass die Absenderdomäne SPF- und DKIM-konform ist; die Standard-Subdomäne auf odoo.com ist laut Dokumentation dafür vorkonfiguriert.

Schritt 3: Szenarien je Prozess anlegen

Ein Szenario ist ein einzelner Geschäftsvorfall mit einer überprüfbaren Erwartung. Bilden Sie für jeden Kernprozess mindestens eine Zeile und ergänzen Sie die Randfälle, die in Ihrem Betrieb vorkommen, etwa Teillieferung, Gutschrift, Storno oder Fremdwährung. Den Import aus dem Altsystem testen Sie im selben Verfahren und mit eigener Zeile (Datenübernahme aus dem Altsystem). Die folgende Tabelle ist eine redaktionelle Vorlage: Die Beispielzeilen zeigen, wie eine Zeile gefüllt wird, und sind keine Vorgabe für Ihre Prozesse.

Nr.	Prozess	Testfall	Testdaten (Beispiel)	Erwartetes Ergebnis	Nachweis	Ergebnis
1	Verkauf	Angebot, Auftrag, Lieferung und Rechnung für einen Neukunden	Kunde Muster GmbH, Artikel A und B, 19 Prozent Umsatzsteuer	Beide Positionen geliefert, Rechnung und Angebot stimmen im Nettobetrag überein, Lagerbestand sinkt um beide Mengen	Belegnummern von Auftrag, Lieferung und Rechnung, Lagerbericht	bestanden / fehlgeschlagen
2	Einkauf	Bestellung, Wareneingang und Eingangsrechnung eines Lieferanten	Lieferant Beispiel AG, 10 Stück, Einkaufspreis 12,50 Euro netto	Der Wareneingang bucht 10 Stück, die Eingangsrechnung steht offen und stimmt im Betrag mit der Bestellung überein	Bestellnummer, Wareneingangsbeleg, Kreditorenjournal	offen
3	Buchhaltung	Teilzahlung auf eine Ausgangsrechnung	Kundenrechnung 1.190,00 Euro brutto, Zahlung 500,00 Euro	Der offene Posten sinkt auf 690,00 Euro, und der Zahlungseingang steht im richtigen Zeitraum	Journal, Bericht offene Posten	offen
4	Rechte	Leichtbenutzer (Light) meldet sich an	Benutzer mit der Rolle Leicht	Kein Zugriff auf Verkauf, Einkauf, Projekte oder Buchhaltung; nur die freigegebenen Funktionen sind sichtbar	Protokolleintrag mit Uhrzeit	offen

Jede Zeile trägt dieselben Angaben, damit sie später nachvollziehbar ist:

• Vorbedingung: welcher Datenstand, welche Einstellung, welcher offene Vorgang nötig ist.
• Rolle: welcher Benutzer mit welchen Rechten den Fall ausführt.
• Schritte: die Kette der Vorgänge in der Reihenfolge, in der sie im Betrieb laufen.
• Erwartetes Ergebnis: prüfbar, mit Menge, Betrag oder Datum, nicht die Aussage “funktioniert”.
• Nachweis: Belegnummern, Journal, Bericht oder Export, der das Ergebnis belegt.
• Ergebnis, Abweichung, Entscheidung: bestanden oder fehlgeschlagen, was abwich, wer bis wann nachbessert.

Schritt 4: Die Szenarien durchspielen

Fahren Sie zuerst den durchgehenden Fall vom Angebot bis zum Zahlungseingang; er zeigt, ob die Übergaben zwischen den Apps tragen. Danach kommen die Randfälle und je Rolle ein Test der Rechte und der Sichtbarkeit.

Führen Sie das Protokoll während des Tests, nicht danach, und rechnen Sie Beträge und Mengen von Hand nach: So erkennen Sie eine falsche Steuer oder einen falschen Lagerbestand.

Lassen Sie jede Rolle selbst einloggen, statt alles mit dem Administratorkonto zu prüfen. Änderungen an Zugriffsrechten können nach der Dokumentation Nebenwirkungen haben, bis dahin, dass niemand mehr Rechte ändern kann; nehmen Sie sie in der Testdatenbank vor.

Nach einer Korrektur fahren Sie dieselbe Zeile erneut und tragen das zweite Ergebnis mit Datum unter das erste ein. Wiederholen Sie den entscheidenden Durchgang kurz vor dem Stichtag: Die Testdatenbank altert.

Schritt 5: Ergebnis abnehmen und festhalten

Das Abnahmeprotokoll enthält Testdatum und Teilnehmende mit Rolle, die Version (Release 20.0, Zweig oder Revision), den Namen der Testdatenbank samt Herkunft der Kopie, die Szenarientabelle mit Nachweisen, offene Punkte mit Person und Termin sowie die Entscheidung: angenommen, angenommen mit Auflagen oder nicht angenommen.

Konfigurationen, die im Test entstanden sind, übernehmen Sie anschließend in die Produktivdatenbank. Bei Odoo.sh überträgt ein Merge von Staging nach Production nur den Code. Die Dokumentation nennt zwei Wege: die Änderung in der Produktivdatenbank erneut ausführen oder sie als XML-Datendatei in den Zweig schreiben und die Modulversion erhöhen; den zweiten Weg empfiehlt sie für die Nachvollziehbarkeit.

So prüfen Sie das Ergebnis

• Jede Zeile hat ein Ergebnis und einen Nachweis; jeder offene Punkt hat eine Person und einen Termin.
• Die Produktivdatenbank enthält keine Testvorgänge: Suchen Sie nach den Datensätzen des Tests und deaktivieren Sie die Testkonten in den Einstellungen unter Benutzer.
• Die im Test erprobten Einstellungen sind in der Produktivdatenbank gesetzt, nicht nur in der Testdatenbank.
• Die Punkte, die die Testdatenbank nicht abdeckt, stehen mit Termin im Plan nach dem Go-live.
• Die Frist der Testdatenbank ist eingetragen: Bei Odoo Online verfällt ein Duplikat nach 15 Tagen, eine Odoo.sh-Staging-Datenbank wird nach einem Monat gelöscht. Planen Sie Nachtest und Abschluss vorher ein.

Wenn etwas nicht klappt

Symptom	Ursache	Abhilfe
Keine E-Mail kommt beim Testkunden an	Die Testdatenbank ist neutralisiert; ausgehende E-Mails sind abgeschaltet, bei Odoo.sh fängt der Mail Catcher sie ab	Bei Odoo.sh den Inhalt im Mail Catcher prüfen; den echten Versand in der Produktivdatenbank nach dem Go-live prüfen
Eine Zahlung bleibt offen	Zahlungsanbieter sind in der Testdatenbank abgeschaltet, bei Odoo.sh-Staging im Testmodus	Im Testmodus die Ablauflogik prüfen; die echte Buchung nach dem Go-live in der Produktivdatenbank prüfen
Eine geplante Aktion läuft nicht	Geplante Aktionen sind in der neutralisierten Testdatenbank abgeschaltet; bei Odoo.sh-Staging führt die Plattform sie seltener aus, wenn niemand die Datenbank nutzt	Bei Odoo.sh-Staging die Aktion von Hand auslösen oder wieder einschalten und den Lauf so im Test prüfen; einen abgeschaltet gebliebenen Lauf nach dem Go-live in der Produktivdatenbank beobachten
Der Testbenutzer sieht zu viel oder zu wenig	Rechte und Gruppen sind in der Testkopie anders gesetzt als geplant	Rechte je App in den Einstellungen unter Benutzer prüfen; Datensatzregeln nur im Entwicklermodus ändern

Wann Sie Hilfe holen sollten

• Sobald der Test steuerliche Fragen berührt, etwa Eröffnungssalden oder die Zuordnung von Steuern, gehört die Klärung zur Steuerberatung; die Übergabe beschreibt Steuerberater zusammenarbeiten.
• Für eigene Module und Anpassungen genügt der Funktionstest nicht. Ob eigener Code hält, prüfen automatisierte Tests (Automatisierte Tests); richten Sie das mit einem Odoo-Partner ein.
• Bei Fragen zur Testdatenbank im Cloudbetrieb verweist die Dokumentation auf den Odoo-Support, etwa für die Grenze von fünf Duplikaten je Datenbank.
• Wenn der Test länger dauert als geplant, verschieben Sie den Stichtag lieber, als ihn abzukürzen (Stichtag und Parallelbetrieb).