Deckung der Anforderungen von Fällen. Die Realitäten von SuperJob

Hi, Habrovchane!

Ich beschloss, einen Artikel über den Interaktionsprozess zwischen Testern und Analysten und die Boni zu schreiben, die SuperJob durch diesen Prozess erhält.

Die Arbeit der Tester mit den Anforderungen besteht aus drei Phasen: der FT-Überprüfung, der FT-Abdeckung und der Fallprüfung.

Bild

FT Review


Anforderungen werden von Analysten in Enterprise Architect ausgeführt und von dort in Confluence kopiert. Nach dem Schreiben der Anforderungen werden sie an die Testerprüfung gesendet.

Bild

Während diese Interaktion über Google Sheets durchgeführt wird, gibt es Folgendes:

  • FT-Name
  • Link zu FT
  • FT-Analyst
  • Analystenstatus
  • Verantwortlicher Tester
  • Status von Testern

Der Analytiker des entsprechenden Elements der Tabelle gibt den Status "Überarbeitung" an:

Bild

In Confluence werden zu diesem Zeitpunkt Fragen zu bestimmten Elementen der Anforderungen gestellt, da Sie mit dieser Funktion beliebigen Teilen des Textes Kommentare hinzufügen können. In den Kommentaren gibt es Diskussionen, deren Ergebnis FT aktualisiert wird.

Nachdem die Anforderungen hinzugefügt und aktualisiert wurden, werden sie in die Entwicklung und in das Testen übernommen.

FT-Beschichtung


Testfälle werden in TestRail geschrieben, die Speicherarchitektur des Testfalls wiederholt die Speicherarchitektur für Anforderungen. Dies ist notwendig, um die Suche zu erleichtern und um das eigene Fahrrad nicht neu zu erfinden - es ist einfacher, es von einem Nachbarn des Analytikers zu nehmen.

Bild

Die Prüfung deckt Anforderungen ab - jedes Anforderungselement wird abgedeckt, jedes Angebot.

Jedes Anforderungselement ist nummeriert, es gibt eine Spur von Testfällen für Anforderungselemente. Unabhängig davon möchte ich anmerken, dass in jedem Fall die FT-Version angebracht ist, auf die dieser Fall geschrieben wurde - die Anforderungen können sich ändern und auch die Punkte darin, wenn Sie die FT-Version nicht berücksichtigen, können Sie sie nicht finden.

Bild

Auf diese Weise:

  • Die Anforderungen an die Deckungsqualität von Fällen können leicht überprüft werden. Vor den Augen gibt es nicht ein Blatt mit 50 Fällen und das gleiche Blatt FT, sondern wählen Sie einen Artikel aus und sehen Sie sofort, welche Fälle diesen Artikel abdecken.
  • Bei geänderten Anforderungen ist sofort ersichtlich, welche Fälle korrigiert werden müssen.

Die Fälle werden in drei Versionen geschrieben:

  • Überschriften der Fälle (meistens). Wenn ein Fall nur einen Titel hat, ist klar, was zu tun ist. Sie sind schneller zu schreiben als detaillierte Testfälle und gleichzeitig eine transparente Beschichtung:

Bild

  • Testfälle. Detaillierter Testfall mit Schritten, wenn der Fall viele Nuancen aufweist und nicht alle in die Überschrift passen;
  • Fall-Checklisten. Wenn ein Fall aus einer Checkliste zur Überprüfung einer bestimmten Richtung der Funktion besteht. Um solche Fälle auszuwählen, verwenden wir im Titel (Fälle):

Bild

In den Bereichen von FT, in denen Modelle vorhanden sind, wird ein Testfall erstellt: "Matching with the M layout ...". Es dient als einfache Erinnerung daran, dass ein Layout vorhanden ist und die Implementierung damit überprüft werden muss. Dieser Fall ohne interne Beschreibung - die Checkliste zur Überprüfung des Layouts ist in den Vorschriften beschrieben.

Überprüfung der Fälle


Nachdem die Fälle in die allgemeine Tabelle geschrieben wurden, wird der Status "Überprüfung der Fälle" hinzugefügt. Dies ist ein Zeichen dafür, dass ein anderer Tester diese FT nehmen und eine Überprüfung der Fälle durchführen kann. Dies ist notwendig, damit die Fälle allen Testern gleichermaßen klar sind und die Anforderungen neu betrachtet werden.

Bild

Im Falle einer nicht erfolgreichen Überprüfung sind zum Beispiel neue Probleme in der TF aufgetreten oder die Abdeckung reicht nicht aus - die Anforderung wird in den Status „Finalisieren“ überführt. Es gibt nicht genügend Kommentare in TestRail, um alle Ihre Wünsche zu beschreiben - sofern dies in Slack schriftlich geschieht, was für das Tracking nicht sehr praktisch ist.

Wenn die Überprüfung erfolgreich ist, wechselt FT in den Status "Bereit".

In seltenen Fällen, wenn die Anforderungen nach dem Schreiben von Testfällen aktualisiert wurden, wird FT in den Status „Aktualisiert“ versetzt. Darüber hinaus abonniert ein Tester für FT Aktualisierungen der Confluence-Seite. Wenn sich die Anforderungen stark geändert haben, wird eine Aufgabe für den Tester erstellt, um die Fälle zu aktualisieren.

Fazit


Was gibt uns diesen Ansatz?

  • Erstens die Entwicklung bewährter Anforderungen. Dies erspart den Entwicklern die Zeit, zu der Unlogik, Mängel und FT-Untiefen einfach nicht reichen.
  • Zweitens bereiten sich die Tester parallel zur Entwicklung auf Tests vor. Daher reduzieren wir die Release-Zeitfunktionen. Tester können den Prozess des Schreibens von Fällen ruhig und verantwortungsbewusst angehen, und nicht in dem Format „Aaaa, ein riesiges Feature ist gefallen, Sie müssen es heute abend einschenken. Lass uns schneller testen! "
  • Drittens ist dies eine Steigerung der Testqualität aufgrund einer Überprüfung der Fälle. Sag "Nein!" Zu einem starren Blick.

Was magst du nicht?


  • Es besteht eine ziemlich große zeitliche Lücke zwischen dem Schreiben von Fällen und ihrer Ausführung für das Feature - obwohl die Fälle bereits bereit sind und nur überprüft werden können, der Tester jedoch immer noch aus dem Zusammenhang gerät;
  • Wie ich bereits schrieb - in TestRail gibt es nicht genügend Kommentare, wie in Confluence -, Sie können nicht nur den Problembereich zur Kenntnis nehmen und einen Kommentar hinterlassen.

Das ist alles für jetzt. Vielen Dank für Ihre Aufmerksamkeit!

Und wie läuft die Arbeit mit den Anforderungen von Ihnen ab?

Jetzt auch beliebt: