# Workflow: Testing - Team XWing

Version: 37 | Last modified: 2026-01-13T09:54:01.027+01:00
Source: confluence page ID 431628888

---

INLINEWorkflow (Siehe Confluence Workflow: Testing - Team XWing - O2C | Order2Cash - ariJa Confluence)
EntwicklerÂ hat Entwicklung abgeschlossen â EntwicklerÂ hat Unit Tests geschrieben ->Â Entwickler schiebt Ticket auf "ReadyForTest" -> Tester testet erfolgreich auf EU -> Tester dokumentiert Test und approved den MR -> MR Review findet durch zweiten Entwickler erfolgreich statt -> Merge erfolgt durch Entwickler auf TU -> (Ggf. je nach Ticket: Tester testet erfolgreich integrativ auf TU (ggf. Ã¼ber UI) und dokumentiert den Retest ->) Tester schiebt Ticket auf "Done"
Die Rolle des Testers kann natÃ¼rlich auch von einem Entwickler erfÃ¼llt werden hier, aber den Workflow sollten wir hier definitiv beachten. Und es ist essentiell, dass die 3 genannten Rollen von 3 verschiedenen Personen erfÃ¼llt werden.
Dokumentation
Stories werden durch einen dedizierten Test in XRay samt Execution abgedeckt. Beispiel hier: O2CXW-6485 mit dem Test O2CAP-2911 und der Execution O2CAP-2912. (In diesem Fall ist der Test direkt in O2CAP erstellt worden, weil er direkt als Regressionstest konzipiert wurde. Im Normalfall erstellen wir den Test im selben Projekt der Story)
Bei Bugs, Enablern und Co. reicht eine Dokumentation in Form von Kommentaren. Dort beschreiben wir das Vorgehen, das Ergebnis und hinterlegen mÃ¶glichst noch die Testdaten. Manchmal ergibt es auch Sinn, den Bug einmal auf einer betroffenen Umgebung zum Vergleich zu reproduzieren und das nochmal aufzuzeigen. Beispiel hier: O2CXW-6690 (siehe Bild)
Das folgende Diagramm zeigt den optimalen Ablauf einer TestdurchfÃ¼hrung fÃ¼r eine regulÃ¤re Feature-Story bzw. einen Bug.
Der gezeigte Workflow ist rein aus Testersicht gestaltet. Zur Einordnung ist auf den generellen Feature Workflow inÂ  zu verweisen.
trueMerge Workflow Testingfalseautotoptrue2491113125
