TestRail — Egyedi beállítások a projekthez

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)

  1. Általános követelmények

    1. A tesztnek képesnek kell lennie arra, hogy bármelyik ember elvégezheti.

    2. A teszteknek lehetőség szerint minél tovább aktuálisnak kell maradniuk.

    3. 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.

  2. Elkülönítés TestCase és TestScenario szerint

  3. Gyors TestRun létrehozása különböző típusokban

    1. Smoke

    2. Regress

    3. Hatásvizsgálat, stb.

  4. A tesztelési esetek támogatásának optimalizálása

    1. 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:

TestRail — Egyedi beállítások a projekthez

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:

TestRail — Egyedi beállítások a projekthez

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:

TestRail — Egyedi beállítások a projekthez

A következő mezőkre lesz szükségünk:

A „Summary” mező (a teszteset feje)

TestRail — Egyedi beállítások a projekthez

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:

TestRail — Egyedi beállítások a projekthez

Filling in the components of the new field:

TestRail — Egyedi beállítások a projekthez

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

TestRail — Egyedi beállítások a projekthez

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,

TestRail — Egyedi beállítások a projekthez

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

TestRail — Egyedi beállítások a projekthez

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.

TestRail — Egyedi beállítások a projekthez

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:

  1. Links to current layouts (this is much better than making dead screenshots)

  2. Typical steps to the screen with the test situation

  3. SQL queries

  4. 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: a linken.

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:

TestRail — Egyedi beállítások a projekthez

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

TestRail — Egyedi beállítások a projekthez

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:

TestRail — Egyedi beállítások a projekthezTestRail — Egyedi beállítások a projekthez

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.

TestRail — Egyedi beállítások a projekthez

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.

TestRail — Egyedi beállítások a projekthez

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: 

  1. gyors TestRun létrehozásához különböző tipikus feladatokhoz: smoke, regresszió stb.

  2. lesznek-e a tesztek automatizálva vagy már automatizálták őket

  3. bármely más címke

Példa: Smoke, Automatizált, WhiteLabel, ForDelete stb.

TestRail — Egyedi beállítások a projekthezTestRail — Egyedi beállítások a projekthez

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:

TestRail — Egyedi beállítások a projekthez

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:

TestRail — Egyedi beállítások a projekthez

Egyéb hasznos tippek

  1. 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.

TestRail — Egyedi beállítások a projekthez

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

TestRail — Egyedi beállítások a projekthez

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:

A TestRail gyártójának weboldala

Könyv: „Tesztelés .COM” (szerző: Roman Savin)

Nagyon köszönöm a figyelmet!

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster