Hallo Habrowsk-Bürger!
Ich habe beschlossen, einen Artikel über den Interaktionsprozess zwischen unseren Testern und Analysten und über die Boni zu schreiben, die das SuperJob-Unternehmen durch diesen Prozess erhält.
Die Arbeit von Testern mit Anforderungen besteht aus drei Phasen: FT Review, FT Coverage, Case Review.
FT Review
Die Anforderungen werden von Analysten in Enterprise Architect verwaltet und von dort in Confluence kopiert. Nach dem Schreiben der Anforderungen werden sie zur Überprüfung an die Tester gesendet.
Während diese Interaktion über Google Sheets durchgeführt wird, gibt es:
- FT Name
- Link zu FT
- Verantwortlich für FT Analyst
- Status von Analysten
- Verantwortlicher Tester
- Status von Testern
Der Analyst setzt den Status "On Review" in den entsprechenden Absatz der Tabelle:
In dieser Phase werden im Rahmen von Confluence Fragen zu bestimmten Anforderungspunkten gestellt, da Sie mit dieser Funktion Kommentare zu beliebigen Teilen des Textes hinzufügen können. In den Kommentaren sind Diskussionen im Gange, wodurch die FT aktualisiert wird.
Nachdem die Anforderungen hinzugefügt und aktualisiert wurden, werden sie in die Entwicklung und das Testen übertragen.
FT-Abdeckung
Testfälle werden in TestRail geschrieben. Die Speicherarchitektur von Testfällen wiederholt die Anforderungsspeicherarchitektur vollständig. Dies ist für eine einfache Suche erforderlich. Um Ihr Fahrrad nicht neu zu erfinden, ist es einfacher, es einem Nachbarn eines Analytikers abzunehmen.
Das Testen deckt Anforderungen ab - jeder Anforderungsgegenstand, jedes Angebot wird abgedeckt.
Jedes Anforderungselement ist nummeriert, und es gibt eine Spur von Testfällen für Anforderungselemente. Unabhängig davon möchte ich darauf hinweisen, dass es in jedem Fall eine Version der FT gibt, auf die dieser Fall geschrieben wurde - die Anforderungen können sich ändern und auch die Punkte in ihnen. Wenn Sie die Version der FT nicht berücksichtigen, können Sie die Enden nicht finden.
Auf diese Weise:
- Es ist einfach, die Qualität der Fallabdeckung zu überprüfen. Vor meinen Augen befindet sich kein Blatt mit 50 Fällen und dasselbe FT-Blatt in der Nähe, aber Sie wählen einen Anforderungspunkt aus und sehen dann, welche Fälle diesen bestimmten Punkt abdecken.
- Im Falle einer Änderung der Anforderungen können Sie sofort sehen, welche Fälle korrigiert werden müssen.
Fälle werden in drei Versionen geschrieben:
- Überschriftenfälle (die meisten davon). Wenn der Fall nur eine Überschrift hat, anhand derer klar ist, was zu tun ist. Sie sind schneller zu schreiben als detaillierte Testfälle und gleichzeitig transparent:
- Testfälle. Ein detaillierter Testfall mit Schritten, bei denen der Fall viele Nuancen enthält und nicht alle in die Überschrift aufgenommen werden können.
- Fälle, Checklisten. Wenn ein Fall aus einer Checkliste zur Überprüfung einer Funktionsrichtung besteht. Verwenden Sie in der Kopfzeile (Fälle) Folgendes, um solche Fälle hervorzuheben:
In den Abschnitten der FT, in denen es Modelle gibt, wird der Testfall „Abstimmung mit Layout M ...“ erstellt. Es dient lediglich als Erinnerung daran, dass es ein Layout gibt und die Implementierung damit überprüft werden muss. Dieser Fall ohne interne Beschreibung - die Checkliste für den Abgleich mit dem Layout, das wir in den Vorschriften beschrieben haben.
Fallbesprechung
Nach dem Schreiben von Fällen wird der Status „Fallprüfung“ in die allgemeine Tabelle aufgenommen. Dies ist ein Zeichen dafür, dass ein anderer Tester diese FT nehmen und eine Fallprüfung durchführen kann. Dies ist notwendig, damit die Fälle für alle Tester gleich klar sind und um die Anforderungen mit einem frischen Aussehen zu durchlaufen.
Wenn beispielsweise die Überprüfung nicht erfolgreich abgeschlossen wurde, tauchten neue Fragen in der FT auf oder die Berichterstattung ist unzureichend - die Anforderung wird in den Status „Finalisieren“ versetzt. TestRail enthält nicht genügend Kommentare, um alle Ihre Wünsche zu beschreiben. Dies geschieht jedoch schriftlich in Slack, was für die Nachverfolgung nicht sehr praktisch ist.
Wenn die Überprüfung erfolgreich ist, befindet sich die FT im Status "Fertig stellen".
In seltenen Fällen wird die FT in den Status "Aktualisiert" versetzt, wenn die Anforderungen nach dem Schreiben von Testfällen aktualisiert wurden. Darüber hinaus abonniert der Tester, der die FT abdeckt, Aktualisierungen der Confluence-Seite. Wenn sich die Anforderungen stark geändert haben, wird eine Aufgabe für den Tester erstellt, um Fälle zu aktualisieren.
Fazit
Was gibt uns diesen Ansatz?
- Erstens fallen nachgewiesene Anforderungen in die Entwicklung. Dies spart Entwicklern Zeit, zu der Unlogiken, Mängel und Pfosten von FT einfach nicht gelangen.
- Zweitens bereiten sich Tester parallel zur Entwicklung auf das Testen vor, sodass wir die Zeit für die Freigabe von Funktionen verkürzen. Tester können ruhig und verantwortungsbewusst an den Prozess des Schreibens von Fällen herangehen und nicht in dem Format „Ahhh, ein riesiges Feature ist gefallen, Sie müssen es heute Abend einschenken. Lass uns schneller testen! “
- Drittens ist dies eine Verbesserung der Testqualität aufgrund der Überprüfung der Fälle. Sag "Nein!" ein verschwommener Blick.
Was magst du nicht?
- Zwischen dem Schreiben von Fällen und dem Ausführen von Fällen für eine Funktion besteht eine ziemlich große Zeitlücke. Obwohl die Fälle fertig sind und nur überprüft werden können, fällt der Tester dennoch aus dem Kontext.
- Wie ich bereits geschrieben habe - in TestRail gibt es nicht genügend Kommentare, wie in Confluence - können Sie den Problemort nicht einfach nehmen und markieren und einen Kommentar dafür hinterlassen.
Das ist alles für jetzt. Vielen Dank für Ihre Aufmerksamkeit!
Und wie ist der Prozess der Arbeit mit Ihren Anforderungen?