TestRail — Individuelle Einstellungen für Ihr Projekt

Einführung

In vielen Projekten, an denen ich gearbeitet habe, haben die Leute TestRail nicht individuell angepasst und sich mit den Standardkonfigurationen begnügt. In diesem Artikel möchte ich daher ein Beispiel für individuelle Einstellungen beschreiben, die Ihnen helfen können, Ihre Effizienz zu steigern. Als Beispiel nehmen wir ein Projekt zur Entwicklung einer mobilen Anwendung.

Kleiner Hinweis: In diesem Artikel wird die grundlegende Funktionalität von TestRail nicht beschrieben (darüber gibt es viele Anleitungen) und es gibt keine verkaufsfördernden Aussagen, die bunt beschreiben, warum Sie gerade diesen Anbieter für die Erstellung eines Testrepositories wählen sollten.

Planungsgrundlage (was umgesetzt wird)

1. Allgemeine Anforderungen

   1. Jeder Mensch muss in der Lage sein, den Case zu durchlaufen

   2. Die Cases müssen so lange wie möglich relevant bleiben

   3. Die Cases sollten den Funktionsumfang der mobilen Anwendung so umfassend wie möglich abdecken, solange dies nicht den ersten beiden Punkten widerspricht

2. Unterteilung in TestCase und TestScenario

3. Schnelle Erstellung von TestRuns verschiedener Typen

   1. Smoke

   2. Regress

   3. Impact-Testung usw.

4. Optimierung der Unterstützung von Cases

   1. Verzicht auf 'tote' fest kodierte Screenshots und Umstieg auf 'movable data'

Anforderungen

Um die Felder zu bearbeiten, benötigen Sie Administratorrechte.

Wählen Sie den Projekttyp aus.

Es können drei Typen von Projekten ausgewählt werden:

Wir wählen den Standardtyp. In diesem können alle Fälle gleichzeitig verfügbar sein. Wir werden intelligente Filterung nutzen und alle Fälle dynamisch verwalten.

Hinzufügen von Feldern zur Anzeige der Liste der Testfälle.

Wir fügen ein Feld zur Anzeige der Priorität der Testfälle hinzu:

Es können auch andere Felder hinzugefügt werden.

Einstellung der Felder und Tags für den Testfall.

Öffnen Sie das Einstellungsmenü:

Wir benötigen folgende Felder:

Feld „Zusammenfassung“ (Kopf des Testfalls)

Dieses Feld existiert bereits, wir systematisieren lediglich dessen Verwendung. Wir werden die Fälle in TestCase und TestScenario unterteilen. Um die Lesbarkeit einer langen Liste von Fällen zu verbessern, sollten wir im Voraus eine Regelung zur Erstellung von Zusammenfassungen vereinbaren.

TestScenario:

Beispiel: TestScenario – Hauptnutzungsszenario der mobilen Anwendung

TestCase:

Beispiel: Hauptbildschirm – Anmeldeseite – Eingabe des Benutzernamens

In der Zusammenfassung des Falls sehen wir ein klassisches Verständnis: „was, wo, wann“. Zudem unterteilen wir optisch die hochrangigen Testszenarien und die nieder-rangigen Testfälle in der am besten für die Automatisierung geeigneten Form.

Das Tag „StartScreen“ (der Bildschirm, von dem aus das TestScenario beginnt; viele Testfälle können auch angrenzende Bildschirme betreffen)

Wofür könnte das benötigt werden: Wir werden aus dem Text der Testfälle die typischen Schritte entfernen, die den Nutzer auf den Bildschirm des aktuellen Testfalls führen. (typische Schritte zur Schaffung einer bestimmten Testsituation) Alle typischen Schritte für alle Testfälle werden in einer Datei dokumentiert. Darüber werde ich gesondert näher berichten.

Wir erstellen ein neues Feld:

Wir füllen die Komponenten des neuen Feldes aus:

In diesem Fall erstellen wir ein Auswahlfeld aus einer Liste von Werten. Wir geben die Werte dieses Feldes ein:

Bitte beachten Sie, dass die IDs der Werte nicht mit eins beginnen und nicht aufeinanderfolgend sind. Warum ist das so? Der Grund ist, dass, wenn wir Testfälle mit einer gegebenen ID aufzeichnen,

und wir anschließend einen dritten Bildschirm zwischen zwei bestehenden benötigen,

Dann müssen wir die ID neu schreiben, und da tags für die bestehenden Testfälle bereits daran gebunden sind, werden sie einfach gelöscht. Das wäre sehr unangenehm.

Tag «Screen» (Bezeichnung des Bildschirms, der den Testfall betrifft)

Wozu das benötigt werden könnte: einer der Anker für Impact-Tests. Zum Beispiel haben die Entwickler ein cooles neues Feature erstellt. Wir müssen es testen, aber dafür müssen wir verstehen, was genau dieses Feature beeinflussen könnte. Standardmäßig können wir davon ausgehen, dass verschiedene Bildschirme (Activities) der App unterschiedliche Klassen haben und somit verschiedene Komponenten der Anwendung bilden. Natürlich ist in diesem Fall ein individueller Ansatz erforderlich.

Beispiel: home_screen, MapScreen, PayScreen usw.

Feld „MovableData“ (Verweis auf die Proxy-Datenbank mit veränderbaren Testdaten)

Als nächstes versuchen wir, das Problem der Aktualität der Daten in den Testfällen zu lösen:

1. Links zu aktuellen Layouts (das ist viel besser als tote Screenshots zu erstellen)

2. Standard-Schritte bis zum Bildschirm mit der Testsituation

3. SQL-Abfragen

4. Links zu externen Daten und anderen Daten

Anstatt Testdaten in jeden Testfall aufzunehmen, erstellen wir eine externe Datei, auf die wir in allen Testfällen verweisen. Wenn wir diese Daten aktualisieren, müssen wir nicht jeden Testfall einzeln durchgehen und anpassen, sondern können die Daten an einem zentralen Ort ändern. Wenn jemand, der nicht vorbereitet ist, den Testfall öffnet, sieht er einen Verweis auf die Datei und einen Hinweis, dass er dort die Testdaten einsehen soll.

All diese Daten werden wir in einer externen Datei bündeln, die für alle, die am Projekt teilnehmen, zugänglich ist. Man könnte beispielsweise Google Sheets oder Excel verwenden und innerhalb der Datei eine Suche einrichten. Warum gerade diese Anbieter? Wir gehen davon aus, dass jede Person im Team in der Lage sein sollte, einen Testfall zu öffnen und durchzuführen, ohne vorher verschiedene Tools installieren zu müssen.

Für Google Sheet SQL-Abfragen können ebenfalls genutzt werden. Beispiel:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'"

Für Excel bequeme Makros für Sofortsuche (Filterung) können eingerichtet werden. Beispiel über den Link.

Die Grundidee ist nicht neu und wird im ersten Buch des Testers "Testing dot com" (Autor: Roman Savin) beschrieben. Wir integrieren lediglich die von Roman Savin vorgeschlagenen Methoden in TestRail. Dazu erstellen wir ein Feld mit einem Link zur erstellten Datei:

Wir fügen den Standardwert des Links ein, sodass in jedem neuen Testfall bereits der Link enthalten ist:

Wenn sich der Speicherort der externen Datei ändert (wir berücksichtigen alle Eventualitäten), kann man bequem in allen Testfällen mehrere Felder gleichzeitig ändern:

Das Feld "Descriptions" (Beschreibung oder Idee des Testfalls, standardisierte Anleitungen)

Wozu könnte das benötigt werden: In dieses Textfeld fügen wir eine kurze Beschreibung des Testfalls und standardisierte Anleitungen ein.

Beispiel: Alle Testdaten (aktuelle Mockups, Toolverwendung und weitere Daten) aus diesem Testfall sind durch Links {…} gekennzeichnet und befinden sich in der Datei MovableData. Der Link zu MovableData befindet sich im entsprechenden Feld oben.

Tag "Component" (Komponente der mobilen Anwendung)

Wofür kann es nützlich sein: für Impact-Tests. Wenn eine mobile Anwendung in Komponenten unterteilt werden kann (die sich möglichst wenig gegenseitig beeinflussen), reicht es aus, Änderungen in einer Komponente (mit gewissen Risiken) innerhalb dieser Komponente zu überprüfen, wodurch die Notwendigkeit für umfassende Regressionstests verringert wird. Wenn Informationen vorliegen, dass eine Komponente eine andere beeinflussen könnte, wird eine Impact-Testmatrix erstellt.

Beispiel für Komponenten: GooglePay, Bestellungen, Benutzer, Karte, Autorisierung usw.

Tag „TAG“ (Weitere Tags zur Filterung)

Tagging von Testfällen mit Labels für beliebige Filterungen. 

Sehr nützlich für: 

1. schnelle Erstellung von Testläufen für verschiedene Typaufgaben: Smoke, Regression usw.

2. ob Tests automatisiert werden oder bereits automatisiert sind

3. alle anderen Tags

Beispiel: Smoke, Automatisiert, WhiteLabel, FürLöschen usw.

Wir passen die Reihenfolge der Anzeige der Felder im Testfall an

Wir haben viele neue Felder erstellt, es ist an der Zeit, sie in einer bequemen Reihenfolge anzuordnen:

Erstellung von Testläufen

Jetzt erstellen wir einen neuen Testlauf mit den aktuellen Fällen für die Durchführung von Smoke-Tests in drei Klicks:

Weitere nützliche Tipps

1. Wenn es in TestRail mehrere Projekte gibt, vergessen Sie nicht, neue Felder nur für Ihr Projekt zu erstellen, da sonst Ihre Kollegen aus benachbarten Teams von den neuen, ungewöhnlichen Feldern sehr überrascht sein könnten. Es sind lokale Ohnmachtsanfälle möglich.

2. Fälle mit vielen Feldern lassen sich einfacher aus einer ähnlichen Gruppe kopieren als neue zu erstellen:

3. Konten können gemeinsam genutzt werden. Zum Beispiel: ein Administratorenkonto, mehrere Benutzerkonten.

Fazit

Die oben genannten Beispiele wurden in mehreren Projekten implementiert und haben sich als effektiv erwiesen. Ich hoffe, sie helfen Ihnen, Ihr Verständnis dieses Tools zu verbessern und effektive und benutzerfreundliche "Test-Speicher" zu erstellen. Ich wäre Ihnen sehr dankbar, wenn Sie in den Kommentaren Ihre Erfahrungen mit TestRail und nützliche Tipps beschreiben würden.

Links:

Website des Anbieters TestRail

Buch: „Testen .COM“ (Autor Roman Savin)

Vielen Dank für Ihre Aufmerksamkeit!

Quelle: habr.com