TestRail – Individuelle Einstellungen für Projekte

Einführung

In vielen Projekten, an denen ich gearbeitet habe, haben die Menschen TestRail nicht auf ihre Bedürfnisse eingestellt und mit den Standardkonfigurationen gearbeitet. Daher werde ich in diesem Artikel versuchen, ein Beispiel für individuelle Einstellungen zu beschreiben, die Ihnen helfen können, Ihre Arbeit effizienter zu gestalten. Zur Veranschaulichung nehmen wir ein Projekt zur Entwicklung einer mobilen Anwendung.

Ein kurzer Disclaimer. In diesem Artikel gibt es keine Beschreibung der grundlegenden Funktionen von TestRail (dafür gibt es viele Anleitungen) und keine verkaufsfördernden Aussagen, die schön beschreiben, warum man diesen Anbieter für das Erstellen eines Testrepositories wählen sollte.

Planbegründung (was umgesetzt werden soll)

1. Allgemeine Anforderungen

   1. Der Testfall muss von absolut jeder Person durchgeführt werden können

   2. Die Testfälle sollten so lange wie möglich aktuell bleiben

   3. Die Testfälle sollten den Funktionsumfang der mobilen Anwendung so gründlich 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. Regression

   3. Impact-Testung usw.

4. Optimierung der Unterstützung von Testfällen

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

Anforderungen

Für die Bearbeitung der Felder benötigen Sie Administratorzugang

Auswahl des Projekttyps

Es können drei Projekttypen ausgewählt werden:

Wir wählen den Standardtyp aus. In diesem werden gleichzeitig alle Testfälle verfügbar sein. Wir werden intelligente Filterung nutzen und dynamisch alle Testfälle gleichzeitig 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 weitere Felder hinzugefügt werden.

Einstellung der Felder und Tags des Testfalls

Öffnen Sie das Einstellungsmenü:

Wir benötigen folgende Felder:

Feld „Zusammenfassung“ (Kopf des Testfalls)

Dieses Feld existiert bereits, wir systematisieren nur seine Verwendung. Wir werden die Fälle in TestCase und TestScenario unterteilen. Für besser lesbare große Listen von Testfällen sollten wir vorher eine Vereinbarung über die Richtlinien für das Schreiben der Zusammenfassung treffen.

TestScenario:

Beispiel: TestScenario – Hauptszenario der Nutzung der mobilen Anwendung

TestCase:

Beispiel: MainScreen – Abschnitt Authentifizierung – Eingabe des Benutzernamens

Zusammenfassend sehen wir in der Zusammenfassung des Falls das klassische Verständnis: „was, wo, wann“. Visuell unterteilen wir auch hochrangige Testszenarien und niedrigstufige Testfälle in der am besten für die Automatisierung geeigneten Form.

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

Wofür es benötigt werden kann: Wir werden aus dem Text der Testfälle typische Schritte entfernen, die den Benutzer auf den Bildschirm des aktuellen Testfalls führen. (typische Schritte zur Erstellung einer bestimmten Testsituation) Alle typischen Schritte für alle Testfälle werden in einer Datei festgehalten. Darüber werde ich separat ausführlicher schreiben.

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 ID der Werte nicht mit eins beginnt und nicht aufeinanderfolgend ist. Warum ist das so? Das liegt daran, dass wir, falls Testfälle mit einer eingegebenen ID geschrieben sind,

und wir danach einen dritten Bildschirm zwischen zwei bestehenden erstellen müssen,

wir die IDs umschreiben müssen, und da diese bereits an die Tags der bestehenden Testfälle gebunden sind, würden sie einfach gelöscht werden. Das wäre sehr unangenehm.

Das Tag „Screen“ (der Name des Bildschirms, der den TestCase betrifft)

Wofür es benötigt werden kann: einer der Anker für das Impakt-Testen. Zum Beispiel haben die Entwickler ein neues, tolles Feature erstellt. Wir müssen es testen, aber dafür muss klar sein, welches Feature betroffen sein könnte. Standardmäßig können wir davon ausgehen, dass verschiedene Bildschirme (Activity) der Anwendung verschiedene Klassen haben und somit unterschiedliche Komponenten der Anwendung darstellen. Natürlich ist in diesem Fall ein individueller Ansatz erforderlich.

Beispiel: home_screen, MapScreen, PayScreen usw.

Feld „MovableData“ (Link zu einer 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 Mockups (das ist viel besser als tote Screenshots)

2. Typische Schritte bis zum Bildschirm mit der Testsituation

3. SQL-Abfragen

4. Links zu externen Daten und anderen Daten

Anstatt Testdaten in jeden einzelnen Testfall zu schreiben, erstellen wir eine externe Datei und verlinken auf diese in allen Testfällen. Wenn wir diese Daten aktualisieren, müssen wir nicht alle Testfälle durchgehen und sie ändern, sondern können die Daten nur an einem Ort ändern. Wenn jemand ohne Vorbereitung einen Testfall öffnet, sieht er im Text des Testfalls einen Link zur Datei und einen Hinweis, dass er dort nach Testdaten suchen muss.

Alle diese Daten packen wir in eine externe Datei, die allen Interessierten im Projekt zur Verfügung steht. Man kann beispielsweise Google Sheets oder Excel verwenden und die Suche innerhalb der Datei einrichten. Warum genau diese Anbieter? Weil wir davon ausgehen, dass jeder im Team in der Lage sein sollte, einen Testfall zu öffnen und durchzugehen, ohne vorher irgendwelche Tools installieren zu müssen.

Für Google Sheet Es können SQL-Anfragen verwendet werden. Beispiel:

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

Für Excel Es können bequeme Makros für die sofortige Suche (Filtrierung) eingerichtet werden. Beispiel: unter diesem Link.

Die Idee ist nicht neu und wird im ersten Buch über Tester “Testing dot com” beschrieben. (Autor: Roman Savin) Wir integrieren nur die von Roman Savin vorgeschlagenen Methoden in TestRail. Dafür erstellen wir ein Feld mit einem Link zur erstellten Datei:

Wir füllen den Standardwert des Links aus, sodass in jedem neuen Testfall bereits ein Link vorhanden ist:

Wenn sich der Standort der externen Datei ändert (wir erwarten jeden Notfall), kann man bequem in allen Testfällen gleichzeitig ein oder mehrere Felder ändern:

Feld “Descriptions” (Beschreibung oder Idee des Testfalls, standardisierte Anweisungen)

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

Beispiel: Alle Testdaten (aktuelle Layouts, Nutzung von Tools und weitere Daten) aus diesem Testfall sind mit 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 es benötigt werden kann: für Impact-Tests. Wenn eine mobile Anwendung in Komponenten unterteilt werden kann (die sich gegenseitig so wenig wie möglich beeinflussen), reicht es aus, Änderungen in einer Komponente (mit bestimmten Risiken) innerhalb dieser Komponente zu überprüfen, und es gibt weniger Gründe, umfassende Regressionstests für alles und jeden durchzuführen. Wenn Informationen vorliegen, dass eine Komponente eine andere beeinflussen kann, wird eine Impact-Testmatrix erstellt.

Beispiele für Komponenten: GooglePay, Bestellung, Benutzer, Karte, Authentifizierung usw.

Tag 'TAG' (Weitere Tags zur Filterung)

Tagging von Testfällen mit Tags zur beliebigen Filterung. 

Sehr nützlich für: 

1. schnelles Erstellen von Testläufen für verschiedene Standardaufgaben: Smoke, Regression usw.

2. ob Tests automatisiert werden oder bereits automatisiert sind

3. beliebige andere Tags

Beispiel: Smoke, Automatisiert, WhiteLabel, ForDelete usw.

Wir stellen die Reihenfolge der Felder im Testfall ein

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

Erstellung eines Testlaufs

Jetzt erstellen wir einen neuen Testlauf mit aktuellen Fällen für das Smoke-Testing 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, andernfalls werden Kollegen aus benachbarten Teams sehr überrascht über das Erscheinen neuer, ungewöhnlicher Felder sein. Lokale Ohnmachtsanfälle sind möglich.

2. Fälle mit einer großen Anzahl von Feldern lassen sich einfacher aus einer ähnlichen Gruppe kopieren als neue zu erstellen:

3. Gemeinsame Nutzung von Konten ist möglich. Zum Beispiel: ein Administratorkonto, mehrere Benutzerkonten.

Fazit

Die oben beschriebenen 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 "Testlager" zu erstellen. Ich wäre Ihnen sehr dankbar, wenn Sie in den Kommentaren Ihre Erfahrungen mit der Nutzung von TestRail und nützliche Tipps beschreiben könnten.

Links:

Website des Anbieters TestRail

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

Vielen Dank für Ihre Aufmerksamkeit!

Quelle: habr.com