Seminar Magnolia CMS – Testing, Qualitätssicherung und Troubleshooting

Das Seminar entwickelt eine mehrstufige Qualitätssicherung für Definitionen, Templates, Content, APIs, Integrationen, Sicherheit, Performance und produktionsnahe Fehlerdiagnose. Der Schwerpunkt liegt auf einer reproduzierbaren Vorgehensweise mit klaren Ausgangswerten, kontrollierten Änderungen, Negativtests und dokumentierten Abnahmekriterien. Produktive Änderungen werden nicht vorausgesetzt; alle Arbeitsschritte lassen sich in einer Labor- oder Projektumgebung nachvollziehen.

Inhaltsübersicht

1. Teststrategie und Umgebungen
2. Definitionen, Templates und Content prüfen
3. APIs, Integrationen und Sicherheit testen
4. Performance und Stabilität
5. Diagnose und Ursachenanalyse
6. Zielgruppe und Voraussetzungen
7. Didaktik und Arbeitsweise

Teststrategie und Umgebungen

Inhaltsverzeichnis

• Risiken, Teststufen und Verantwortungen
• Testdaten, Umgebungen und Reproduzierbarkeit
• Abnahmekriterien und Traceability
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Risiken, Teststufen und Verantwortungen, Testdaten, Umgebungen und Reproduzierbarkeit und Abnahmekriterien und Traceability zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Risiken, Teststufen und Verantwortungen werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Testdaten, Umgebungen und Reproduzierbarkeit wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Abnahmekriterien und Traceability werden schrittweise konfiguriert oder implementiert. Ein risikobasierter Testplan wird aus Architektur und kritischen Nutzerabläufen abgeleitet. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Testlandkarte mit Stufen und Eigentümern.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Definitionen, Templates und Content prüfen

Inhaltsverzeichnis

• YAML- und Konfigurationsvalidierung
• Renderingfälle, Varianten und Leerzustände
• Content-Qualität, Referenzen und Publishing
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet YAML- und Konfigurationsvalidierung, Renderingfälle, Varianten und Leerzustände und Content-Qualität, Referenzen und Publishing zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: YAML- und Konfigurationsvalidierung werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Renderingfälle, Varianten und Leerzustände wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Content-Qualität, Referenzen und Publishing werden schrittweise konfiguriert oder implementiert. Fehlerhafte Definitionen und Inhalte werden automatisiert erkannt und verständlich gemeldet. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Prüfsuite für Definitionen und Content.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

APIs, Integrationen und Sicherheit testen

Inhaltsverzeichnis

• Vertrags-, Schema- und Berechtigungstests
• Timeouts, Fehlerantworten und Wiederholung
• Negativtests, Eingabegrenzen und Datenfreigabe
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Vertrags-, Schema- und Berechtigungstests, Timeouts, Fehlerantworten und Wiederholung und Negativtests, Eingabegrenzen und Datenfreigabe zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Vertrags-, Schema- und Berechtigungstests werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Timeouts, Fehlerantworten und Wiederholung wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Negativtests, Eingabegrenzen und Datenfreigabe werden schrittweise konfiguriert oder implementiert. Ein API- und Integrationssatz wird gegen gültige, ungültige und unberechtigte Aufrufe geprüft. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: API-Testpaket mit Sicherheitsfällen.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Performance und Stabilität

Inhaltsverzeichnis

• Lastprofile, Baseline und Budgets
• Cache, Index, Datenbank und externe Abhängigkeiten
• Dauerlauf, Ressourcenverbrauch und Grenzwerte
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Lastprofile, Baseline und Budgets, Cache, Index, Datenbank und externe Abhängigkeiten und Dauerlauf, Ressourcenverbrauch und Grenzwerte zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Lastprofile, Baseline und Budgets werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Cache, Index, Datenbank und externe Abhängigkeiten wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Dauerlauf, Ressourcenverbrauch und Grenzwerte werden schrittweise konfiguriert oder implementiert. Ein Lasttest wird durchgeführt und ein Engpass anhand von Messwerten eingegrenzt. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Performancebericht mit Budget und Maßnahmen.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Diagnose und Ursachenanalyse

Inhaltsverzeichnis

• Symptom, Zeitachse und Reproduktionsfall
• Logs, Metriken, Thread- und Fehlerkontext
• Hypothesen, Behebung, Regression und Wissensbasis
• Praxisübung, Prüfung und Dokumentation

Dieses Kapitel verbindet Symptom, Zeitachse und Reproduktionsfall, Logs, Metriken, Thread- und Fehlerkontext und Hypothesen, Behebung, Regression und Wissensbasis zu einem nachvollziehbaren Arbeitsablauf. Technische Konfiguration, redaktionelle Wirkung, Berechtigungen und betriebliche Folgen werden gemeinsam betrachtet, damit lokale Einzelmaßnahmen nicht zu inkonsistenten Gesamtprozessen führen.

1. Schritt 1 – Ausgangslage erfassen: Symptom, Zeitachse und Reproduktionsfall werden in der Laborumgebung oder im bereitgestellten Referenzfall inventarisiert. Abhängigkeiten, Verantwortungen, bestehende Ausnahmen und erkennbare Risiken werden in einer Prüfliste festgehalten.
2. Schritt 2 – Zielmodell festlegen: Für Logs, Metriken, Thread- und Fehlerkontext wird ein Sollzustand mit eindeutigen Namens-, Rollen-, Daten- und Qualitätsregeln entworfen. Nicht benötigte Optionen werden bewusst ausgeschlossen, damit der spätere Betrieb überschaubar bleibt.
3. Schritt 3 – Umsetzung durchführen: Hypothesen, Behebung, Regression und Wissensbasis werden schrittweise konfiguriert oder implementiert. Mehrere Störungsfälle werden mit einem festen Diagnosebaum bis zur belastbaren Ursache bearbeitet. Jeder Änderungsschritt wird mit Ausgangswert, Änderung und erwarteter Wirkung protokolliert.
4. Schritt 4 – Funktion und Grenzen prüfen: Der Normalfall wird durch Positivtests bestätigt. Anschließend werden fehlende Daten, ungültige Eingaben, unberechtigte Zugriffe, nicht verfügbare Abhängigkeiten und Wiederanlauf betrachtet.
5. Schritt 5 – Standard festschreiben: Konfiguration, Prüfergebnisse, offene Risiken, Rückfalloptionen und Verantwortungen werden konsolidiert. Als verbindlicher Dokumentationsstand entsteht: Troubleshooting-Playbook mit Regressionstests.

Die Übung endet erst nach einem reproduzierbaren Wiederholungstest. Dadurch bleibt nachvollziehbar, welche Voraussetzungen erfüllt sein müssen und wie Abweichungen systematisch erkannt werden.

Zielgruppe und Voraussetzungen

Inhaltsverzeichnis

• Adressierte Rollen
• Fachliche und technische Vorkenntnisse
• Labor- und Arbeitsmittel

Zielgruppe: Magnolia- und Frontend-Entwicklung, Test Engineering, DevOps, Plattformbetrieb, technische Qualitätssicherung und Release Management.

Voraussetzungen: Magnolia-Grundkenntnisse sowie Erfahrung mit Git, Buildprozessen, HTTP und mindestens einem Testframework oder Diagnosewerkzeug.

Für die Praxisanteile wird eine getrennte Magnolia-Umgebung mit Beispieldaten verwendet. Administrations- und Entwicklungsübungen werden mit nicht produktiven Konten durchgeführt. Vor jedem Eingriff werden Ausgangszustand, erwartete Wirkung und Rückfallmöglichkeit festgehalten.

Didaktik und Arbeitsweise

Inhaltsverzeichnis

• Fachimpuls und Demonstration
• Geführte Umsetzung
• Kontrollierte Fehlerfälle
• Abnahme und Dokumentation

Kurze Fachimpulse werden unmittelbar durch Demonstrationen und geführte Arbeitsschritte vertieft. Jede Übung enthält einen definierten Ausgangszustand, konkrete Prüfpunkte, mindestens einen Negativfall und eine schriftliche Abnahme. Wiederholbare Checklisten und Runbooks stehen im Mittelpunkt; reine Funktionsvorführungen ohne Prüfung sind nicht Bestandteil des Vorgehens.