Arbeitsablauf
Anhand eines Beispiels werden wir die Erstellung benutzerdefinierter Anwendungen kennen lernen. Wir werden eine einfache Anwendung zur Fehlerverfolgung erstellen. Wir gehen davon aus, dass wir zwei Teams haben: Entwickler - sie beheben Fehler, und QA (kurz für Quality Assurance) - sie testen die Fehlerbehebungen durch die Entwickler. Wir werden dem Modell den folgenden Fehler-Workflow zugrunde legen:
In einfachem Englisch übersetzt das Diagramm auf:
- Wenn ein Fehler gemeldet wird, befindet er sich im Zustand Neu.
- Die QA verifiziert den Fehler. Wenn es sich nicht um einen Fehler handelt, wird der Fehler in den Geschlossenen Zustand verschoben, andernfalls in den Verifizierten Zustand.
- Ein verifizierter Fehler, der von einem Entwickler behoben wurde, geht in den Status Behoben über.
- Die Korrektur wird dann von der QA getestet und der Fehler wird wieder geöffnet, wenn der Test fehlschlägt; oder geschlossen, wenn der Test bestanden wird.
- Ein wiedereröffneter Fehler, der vom Entwickler behoben wurde, geht in den Status Repariert über.
Wir selbst verwenden unsere eigene Fehlerdatenbank, aber wir haben noch viel mehr Zustände, die anzeigen, ob ein Testfall vorhanden war, ob die Dokumentation aktualisiert wurde, ob ein Testfall hinzugefügt wurde, usw. Ebenso können Sie den Arbeitsablauf so komplex oder einfach gestalten, wie Sie wollen. Aber halten wir uns vorerst an den einfachen Arbeitsablauf, den wir oben besprochen haben.
Erstellen einer App
Um eine App zu erstellen, gehen Sie zu Oberes Menü ▸ ▸ Administrator ▸ Benutzerdefinierte Anwendungen ▸ Anwendungen und klicken Sie auf hinzufügen. Sie sehen ein Formular mit vielen Registern. Wir werden jede Registerkarte unten behandeln.
Die Registerkarte Basic
Diese Registerkarte definiert einige grundlegende Eigenschaften der Anwendung. Darüber hinaus steuert es auch bestimmte Verhaltensweisen der App.
| Name | Der Name Ihrer App. Wir werden Bug hier eintragen. |
| Mehrzahl | Der Pluralname für den Namen. |
| Anfänglich zugewiesen zu | Wählen Sie den Benutzer aus, der automatisch neuen Instanzen zugeordnet wird. |
| Das Feld Antragsteller benutzen | Standardmäßig ist der Ersteller eines App-Elements auch der Anforderer für dieses App-Element. Es könnte jedoch Fälle geben, in denen Sie eine Anwendung im Namen eines anderen Benutzers initiieren und Benachrichtigungen und Updates an diese Person und nicht an den Ersteller senden lassen möchten. In unserer App möchten wir, dass unsere Support-Mitarbeiter in der Lage sind, Fehler im Namen eines Kunden zu öffnen, aber wir möchten, dass Updates an den Kunden geschickt werden. Also schalten wir es ein. Wenn diese Option aktiviert ist, sehen Sie ein Requestor-Feld, das während der Erstellung einer neuen Instanz einer Anwendung aktiviert ist. |
| Zeitprotokollierung zulassen | Ob die Protokollierung des App-Elements erlaubt werden soll. Wir möchten, dass unsere Entwickler und unser QA-Team die Zeit protokollieren, deshalb markieren wir diese Option. |
| Kunden können diese App initiieren | Ob Sie wollen, dass Ihre Kunden neue Instanzen erstellen. Wir möchten, dass unsere Kunden Fehler melden, daher prüfen wir diese Option. |
| Beschreibung | Eine kurze Beschreibung für Ihre App. |
| Anhänger | Wählen Sie die Standardfolger aus. Die Anhänger werden benachrichtigt, wenn es eine Neuzuweisung, eine Änderung des Staates oder neue Kommentare gibt. |
| Aktiv | Ob Sie Ihre Anwendung aktivieren oder deaktivieren sollen. Die Markierung als inaktiv löscht keine bestehenden Instanzen dieser App. |
Die Registerkarte Staaten
Diese Registerkarte definiert die Zustände der Anwendung. Sie können auch den Start- und Endzustand im Workflow markieren. Wir haben alle Zustände in unserem Bug-Workflow aufgelistet.
| Anfangsstatus | Wenn ein App-Element erstellt wird, wird es in diesen Zustand versetzt. In unserem Fall ist es neu. |
| Endzustand | Wenn ein App-Element in diesen Zustand übergeht, gilt der Prozess als abgeschlossen. In unserem Fall ist sie geschlossen. |
Die Registerkarte Workflow
Diese Registerkarte definiert alle Pfeile im Workflow-Diagramm. Jeder Pfeil stellt eine Aktion des Endbenutzers dar. Wir werden später in der Dokumentation mehr über seine Verwendung sehen.
| Aktion | Der Name für die Aktion. Dies wird in Aktionsmenüs für Bugs verwendet. |
| Von | Der Staat, aus dem der Pfeil stammt. |
| An | Der Zustand, in dem der Pfeil endet. Sobald die Aktion ausgeführt wird, wird unser Fehler in diesen Zustand versetzt. |
| Zuweisen zu | Der Benutzer, dem der Workflow nach Durchführung der Aktion zugeordnet wird. Prompt in der Rolle: Der Entwickler gibt an, dass dem Benutzer, der die Verify-Aktion für den Fehler durchführt, eine Liste von Entwicklern vorgelegt wird, aus der er den neuen Beauftragten auswählen kann. |
| Benutzer zulassen | Bestimmt, ob diese Aktion von einem Benutzer durchgeführt werden kann. In einigen Fällen würden wir nicht wollen, dass die Endbenutzer die Aktion durchführen. So werden z.B. in Helpdesk-Systemen nicht reagierende Tickets nach einigen Tagen der Inaktivität automatisch geschlossen. |
Die Registerkarte "Auslöser".
In unserer Bug-Tracking-App benötigen wir keine Auslöser. Nehmen wir jedoch zum Beispiel diesen Helpdesk-Workflow. Im Falle der Helpdesk-App ist der Antragsteller die Person, die eine Frage gestellt hat. Wenn diese Person per E-Mail antwortet, möchten wir, dass das Ticket automatisch in den Status Ungelöst überführt wird, da es dann dem Support-Team zur Kenntnis gebracht wird. Mit anderen Worten, wir würden wollen, dass die Übergänge von Reopen stattfinden. In diesem Fall würden wir unsere Auslöser so definieren:
Die Registerkarte "Staatsmanager".
Ein State Manager ist ein Benutzer, der wie ein Manager behandelt wird, wenn sich eine App in einem bestimmten Zustand befindet. Sie werden benachrichtigt, wenn mit einem Gegenstand in diesem Zustand etwas passiert. In unserem Beispiel unten ist Mark der QA-Manager, also ist er für die Zustände Neu und Fest verantwortlich, in denen das QA-Team arbeiten soll.
