Uvod
U mnogim projektima na kojima sam radio, ljudi nisu prilagodili TestRail i koristili su standardne postavke. Zbog toga ću u ovom članku opisati primer prilagođenih postavki koje mogu pomoći da povećate efikasnost svog rada. Uzet ćemo kao primer projekat razvoja mobilne aplikacije.
Mali disclaimer. U ovom članku nema opisa osnovne funkcionalnosti TestRail-a (za to postoji mnogo vodiča) niti prodajnih izraza koji slikovito opisuju zašto odabrati ovog dobavljača za kreiranje repozitorijuma sa testovima.
Plan opravdanja (šta će biti realizovano)
Opšti zahtevi
Kejsevi moraju moći proći apsolutno svaka osoba
Kejsevi moraju zadržati relevantnost što duže
Kejsevi treba da pokriju funkcionalnost mobilne aplikacije što je moguće temeljitije, u onoj meri u kojoj to ne protivreči prva dva stava
Podela na TestCase i TestScenario
Brzo formiranje TestRun-ova različitih tipova
Smoke
Regress
Impact testiranje itd.
Optimizacija podrške kejsevima
Odustajanje od „mrtvih“ hardkodiranih screenshotova i prelazak na „movable data“
Zahtevi
Za uređivanje polja biće vam potreban administratorski pristup
Izbor tipa projekta
Možete izabrati tri tipa projekta:
Izabrat ćemo tip po defaultu. U njemu će biti dostupni svi kejsevi istovremeno. Koristićemo pametno filtriranje i dinamički upravljati svim kejsevima odjednom.
Dodavanje polja za pregled liste test kejseva
Dodajmo polje za prikaz prioriteta test kejseva:
Takođe se mogu dodati i druga polja.
Podešavanje polja i tagova test kejsa
Otvaramo meni postavki:
Biće nam potrebna sledeća polja:
Polje „Summary“ (naslov test kejsa)
Ovo polje već postoji, samo ćemo sistematizovati njegovu upotrebu. Razdvojićemo kejseve na TestCase i TestScenario. Za bolju čitljivost velikog spiska kejseva, bolje je unapred se dogovoriti o pravilima za pisanje svrhe.
TestScenario:
Primer: TestScenario — Glavni scenario korišćenja mobilne aplikacije
TestCase:
Primer: MainScreen — Odsek za autentifikaciju — Unos korisničkog imena
Na koncu vidimo v povzetku primera klasično razumevanje: „kaj, kje, kdaj“. Prav tako vizualno razdelimo vrhnje testne scenarije in nizkonožne testne primere na način, ki je najbolj primeren za avtomatizacijo.
Oznaka «StartScreen» (zaslon, s katerega se začne TestScenario, prav tako mnogi testni primeri lahko obravnavajo sosednje zaslone)
Zakaj je to potrebno: iz besedila testnih primerov bomo odstranili standardne korake, ki uporabnika pripeljejo na zaslon trenutnega testnega primera. (standardni koraki za ustvarjanje določenih testnih situacij) Vse standardne korake za vse testne primere bomo zapisali v enem dokumentu. O njem bom podrobneje napisal ločeno.
Ustvarimo novo polje:
Izpolnimo komponente novega polja:
V tem primeru ustvarjamo polje izbire iz seznama vrednosti. Vnesemo vrednosti tega polja:
Upoštevajte, da id vrednosti ne začnejo z enico in ne gredo zaporedno. Zakaj je tako? Gre za to, da če bomo zapisali testne primere z vnešenim id,
in po tem bomo potrebovali ustvariti tretji zaslon med obema obstoječima,
bomo morali prepisati id, in ker so že povezani z oznakami obstoječih testnih primerov, se bodo preprosto izbrisali. To bo zelo neprijetno.
Oznaka «Screen» (ime zaslona, ki ga zajema TestCase)
Zakaj je to potrebno: ena od sidrnih točk za testiranje vpliva. Na primer, razvijalci so naredili novo odlično funkcionalnost. Moramo jo testirati, vendar moramo najprej razumeti, katero točno funkcionalnost bi lahko vplivala. Po privzetku se lahko naslonimo na paradigmo, da različni zasloni (Activity) aplikacije imajo različne razrede in torej predstavljajo različne komponente aplikacije. Seveda je v tem primeru potreben individualen pristop.
Primer: home_screen, MapScreen, PayScreen itd.
Polje «MovableData» (povezava na proxy BDP z spremenljivimi testnimi podatki)
Nato se bomo potrudili rešiti težavo z ohranjanjem aktualnosti podatkov v testnih primerih:
Povezave na aktualne makete (to je veliko boljše kot ustvarjanje mrtvih posnetkov zaslona)
Standardni koraki do zaslona s testno situacijo
SQL poizvedbe
Povezave na zunanje podatke in druge podatke
Namesto vnosa testnih podatkov znotraj vsakega testnega primera bomo ustvarili eno zunanjo datoteko in na vseh testnih primerih bomo naredili povezavo nanjo. Ob posodobitvi teh podatkov nam ne bo treba pregledovati vseh testnih primerov in jih spreminjati, temveč bomo lahko spremenili te podatke le na enem mestu. Če nekdo, ki ni pripravljen, odpre testni primer, bo videl v telesu testnega primera povezavo na datoteko in namig, da naj gre tja po testne podatke.
Vse te podatke bomo pakirali v eno zunanjo datoteko, ki bo dostopna vsem zainteresiranim v projektu. Na primer, lahko uporabimo Google Sheet ali Excel in znotraj datoteke nastavimo iskanje. Zakaj ravno ti ponudniki? Gre za to, da se opiramo na paradigmo, da mora vsak v ekipi lahko odpreti in preiti skozi testni primer brez potrebe po predhodni namestitvi kakršnih koli orodij.
Za Google Sheet lahko uporabimo SQL poizvedbe. Primer:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Za Excel lahko nastavimo priročne makre za takojšnje iskanje. (filtriranje) Primer .
Ideja pravzaprav ni nova in je opisana v prvi knjigi testnika “Testiranje dot com”. (avtor Savin Roman) Le integriramo v TestRail metodike, ki jih je predlagal Roman Savin. Za to bomo ustvarili polje s povezavo na ustvarjeno datoteko:
izpolnimo privzeto vrednost povezave, da bo v vsakem novem testnem primeru že povezava:
Če se bo lokacija zunanje datoteke spremenila (predvidevamo vsako izredno situacijo), lahko enostavno spremenimo eno ali več polj v vseh testnih primerih hkrati:
Polje “Descriptions” (opis ali ideja testnega primera, tipične instrukcije)
Za kaj bi bilo lahko potrebno: V to besedilno polje bomo vključili kratki opis testnega primera in tipične instrukcije.
Primer: Vsi testni podatki (aktualni modeli, uporaba orodij in drugi podatki) iz tega testnega primera so označeni s povezavami {…} in se nahajajo v datoteki MovableData. Povezava na MovableData je v ustreznem polju zgoraj.
Oznaka „Component“ (komponenta mobilne aplikacije)
Za šta može biti potrebno: za impakt testiranje. Ako se mobilna aplikacija može podeliti na komponente (koje međusobno što manje utiču jedna na drugu), tada će biti dovoljno (uz određene rizike) proveriti promene u jednoj komponenti u okviru te iste komponente, a osnovi za sveobuhvatno regresijsko testiranje će biti manje. Ako postoji informacija da jedna komponenta može uticati na drugu, tada se sastavlja matrica impakt testiranja.
Primeri komponenti: GooglePay, Narudžbina, Korisnici, Karta, Autorizacija itd.
Tag „TAG“ (Ostali tagovi za filtriranje)
Tagiranje test slučaja oznakama za proizvoljno filtriranje.
Veoma korisno za:
brzo sastavljanje TestRun-a za različite tipične zadatke: smoke, regresija itd.
da li će testovi biti automatizovani ili su već automatizovani
bilo koje druge oznake
Primer: Smoke, Automatizovano, WhiteLabel, ZaBrisanje itd.
Podešavanje redosleda prikazivanja polja u test slučaju
Napravili smo mnogo novih polja, vreme je da ih postavimo u zgodan redosled:
Kreiranje TestRun-a
Sada ćemo kreirati novi test run sa aktuelnim slučajevima za izvođenje smoke testiranja u tri kliknuta:
Druge korisne preporuke
Ako u TestRail-u postoji više projekata, ne zaboravite da kreirate nova polja samo za Vaš projekat, inače će kolege iz susednih timova biti veoma iznenađene pojavom novih neobičnih polja. Mogući su lokalni nesvesni trenutci.
2. Slučajevi sa velikim brojem polja su lakši za kopiranje iz slične grupe nego za kreiranje novih:
3. Možete zajednički koristiti naloge. Na primer: jedan administratorski, nekoliko korisničkih.
Zaključek
Gore opisani primeri su implementirani na nekoliko projekata i pokazali su svoju efikasnost. Nadam se da će vam pomoći da poboljšate svoje razumevanje ovog alata i olakšate stvaranje efikasnih i udobnih 'test skladišta'. Biću veoma zahvalan ako u komentarima podelite svoje iskustvo korišćenja TestRail-a i korisne savete.
Linkovi:
Knjiga:
Hvala vam puno na pažnji!
Izvor: habr.com
