Bevezetés
Sok projektben, amellyel dolgoztam, az emberek nem állították be maguknak a TestRail-t, és megelégedtek a standard beállításokkal. Ezért ebben a cikkben megpróbálom leírni azokat az egyedi beállításokat, amelyek segíthetnek Önnek növelni a munkája hatékonyságát. Példának vegyük egy mobilalkalmazás fejlesztési projektet.
Egy kis diszklámer. Ebben a cikkben nem talál információt a TestRail alapfunkcióiról (erről sok útmutató létezik) és a színes, eladási kifejezésekről, amelyek arról szólnak, hogy miért érdemes éppen ezt a szolgáltatót választani a tesztjei tárolására.
Tervezett indoklás (mi fog megvalósulni)
Általános követelmények
A tesztnek képesnek kell lennie arra, hogy bármelyik ember elvégezheti.
A teszteknek lehetőség szerint minél tovább aktuálisnak kell maradniuk.
A tesztelési eseteknek maximálisan át kell takarnia a mobilalkalmazás funkcionalitását, amennyiben ez nem ellentétes az első két ponttal.
Elkülönítés TestCase és TestScenario szerint
Gyors TestRun létrehozása különböző típusokban
Smoke
Regress
Hatásvizsgálat, stb.
A tesztelési esetek támogatásának optimalizálása
A „halott” hardkódolt képernyőképek elhagyása és a „mozgatható adatokra” való áttérés
Követelmények
A mezők szerkesztéséhez adminisztrátori hozzáférés szükséges.
Projekt típusa
Három projekt típust választhat:

Az alapértelmezett típust választjuk. Ebben egyszerre lesznek elérhetők az összes teszteset. Okos szűrést fogunk használni, és dinamikusan kezeljük az összes tesztesetet egyidejűleg.
Mezők hozzáadása a tesztesetek listájának megtekintéséhez
Hozzáadunk egy mezőt a tesztesetek prioritásának megjelenítéséhez:

Egyéb mezők is hozzáadhatók.
A teszteset mezőinek és címkéinek beállítása
Nyissuk meg a beállítások menüt:

A következő mezőkre lesz szükségünk:
A „Summary” mező (a teszteset feje)
![]()
Ez a mező már létezik, csak a használatát szeretnénk rendszerezni. A teszteseteket TestCase és TestScenario kategóriákra fogjuk osztani. A nagyméretű tesztesetek listájának jobb olvashatósága érdekében jobban, ha előre megállapodunk a summary írási irányelveiben.
TestScenario:
Példa: TestScenario — A mobilalkalmazás fő használati forgatókönyve
TestCase:
Példa: MainScreen — Bejelentkezési rész — Felhasználónév beírása
Végül a teszteset summary-jában a klasszikus megértést látjuk: “mi, hol, mikor”. Emellett vizuálisan megkülönböztetjük a magas szintű tesztforgatókönyveket az alacsony szintű tesztesetektől a legmegfelelőbb automatizálási formában.
A «StartScreen» tag (the screen from which the TestScenario begins; many test cases may touch adjacent screens)
Possible use: we will remove typical steps from the text of test cases that lead the user to the current test case's screen. (typical steps for creating a specific test situation) All typical steps for all test cases will be written in one file. I will write about it separately in more detail.
Creating a new field:

Filling in the components of the new field:

In this case, we are creating a selection field from a list of values. We enter the values for this field:

Note that the id values do not start from one and are not sequential. Why is this done? The point is that if we have test cases recorded with entered ids,

and afterwards we need to create a third screen between two existing ones,

we will have to rewrite the ids, and since they are already linked to the tags of existing test cases, they will simply be deleted. This would be very unpleasant.
A «Screen» tag (the name of the screen affected by the TestCase)
Possible use: one of the anchors for impact testing. For example, developers have created a new cool feature. We need to test it, but for this, we need to understand what this feature might have affected. By default, we can take the paradigm that different application screens (Activities) have different classes and therefore constitute different components of the application. Of course, in this case, an individual approach is required.
Example: home_screen, MapScreen, PayScreen, etc.

Field «MovableData» (link to the proxy DB with changeable test data)
Next, we will try to solve the problem of maintaining the relevance of data in test cases:
Links to current layouts (this is much better than making dead screenshots)
Typical steps to the screen with the test situation
SQL queries
Links to external data and other data
A tesztadatok minden teszt esetbe való beírása helyett létrehozunk egy külső fájlt, és minden teszt esetben hivatkozunk erre. Az adatok frissítésekor nem kell végigböngészni a teszt eseteket és módosítani azokat, elég csak egy helyen változtatni az adatokat. Ha valaki, aki nincs felkészülve, megnyit egy teszt esetet, látni fogja a teszt eset tartalmában a fájlra mutató hivatkozást, valamint egy megjegyzést, hogy oda kell menni a tesztadatokért.
Mindezeket az adatokat egy külső fájlba csomagoljuk, amelyet bárki elérhet a projekt során. Például használhatunk Google Sheets-t vagy Excelt, és beállíthatunk a fájlon belül keresést. Miért éppen ezek a szolgáltatók? Azért, mert abban a paradigmában mozgunk, hogy a teszt esetet bárkinek a csapatban meg kell tudnia nyitni és végigcsinálni anélkül, hogy előzetesen bármilyen eszközt telepítene.
A Google Sheets SQL lekérdezéseket lehet használni. Példa:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")A Excel kényelmes makrókat állíthatunk be az azonnali kereséshez. (szűrés) Példa: .
Egyébként az ötlet nem új, és le van írva az első tesztelő könyvben, "Tesztelés dot com" (szerző: Roman Savin). Mi csupán integráljuk TestRailbe Roman Savin javaslatait. Ehhez létrehozunk egy mezőt, amely hivatkozik a létrehozott fájlra:

kitöltjük a hivatkozás alapértelmezett értékét, hogy minden új teszt esetben már legyen hivatkozás:

Ha a külső fájl helye megváltozik (mindent figyelembe veszünk), akkor egyszerűen módosíthatunk egy vagy több mezőt az összes teszt esetben:


A "Descriptions" mező (a teszt eset leírása vagy ötlete, tipikus utasítások)
Mire lehet szükség: Ebbe a szöveges mezőbe rövid leírást és tipikus utasításokat fogunk elhelyezni a teszt esetről.
Példa: Minden tesztadat (aktuális makettek, eszközhasználat és egyéb adatok) ebből a teszt esetből hivatkozással vannak megjelölve {…}, és a MovableData fájlban találhatóak. A MovableData hivatkozása a megfelelő mezőben található a tetején.

A "Component" címke (mobilalkalmazás komponense)
Mire lehet szükség: impakt teszteléshez. Ha a mobilalkalmazás részekre osztható (amelyek a lehető legkevésbé hatnak egymásra), akkor egy komponensben végrehajtott változtatás elegendő (valamilyen kockázattal) a keretein belül ellenőrizni, és kevesebb alapja lesz az általános regressziós tesztek végrehajtásának. Ha van információ arról, hogy az egyik komponens hatással lehet a másikra, akkor impakt tesztelési mátrixot kell készíteni.
Komponens példák: GooglePay, Megrendelés, Felhasználók, Térkép, Hitelesítés stb.

TAG jelölés (Egyéb címkék szűréshez)
A teszt eset címkézése szabad szűréshez.
Nagyon hasznos a:
gyors TestRun létrehozásához különböző tipikus feladatokhoz: smoke, regresszió stb.
lesznek-e a tesztek automatizálva vagy már automatizálták őket
bármely más címke
Példa: Smoke, Automatizált, WhiteLabel, ForDelete stb.


A mezők megjelenítési sorrendjének beállítása a teszt esetben
Sok új mezőt hoztunk létre, itt az idő, hogy kényelmes sorrendbe helyezzük őket:

TestRun létrehozása
Most új test run-t fogunk létrehozni a megfelelő esetekkel smoke tesztelés végrehajtásához három kattintással:

Egyéb hasznos tippek
Ha a TestRail-ben több projekt van, ne felejtsen el új mezőket csak az Ön projektjéhez létrehozni, különben a szomszédos csapatok tagjai nagyon meglepődnek az új, szokatlan mezők megjelenésén. Helyi zavarok is előfordulhatnak.

2. Azok az esetek, amelyek sok mezőt tartalmaznak, könnyebben másolhatók egy hasonló típusú csoportból, mint újakat létrehozni:

3. Közösen lehet használni a fiókokat. Például: egy adminisztrátori, több felhasználói.
Zárás
A fent leírt példákat több projektben valósították meg, és bizonyították hatékonyságukat. Remélem, hogy segítenek javítani a TestRail megértését és hatékony, kényelmes "teszt tárolók" létrehozását. Nagyon hálás lennék, ha megosztaná a TestRail használatával kapcsolatos tapasztalatait és hasznos tanácsait a megjegyzésekben.
Linkek:
Könyv:
Nagyon köszönöm a figyelmet!
Forrás: habr.com
