Uvod
U mnogim projektima na kojima sam radio, ljudi nisu prilagođavali TestRail svojoj potrebi i koristili su standardne postavke. U ovom članku ću pokušati opisati primjer prilagođenih postavki koje vam mogu pomoći da povećate učinkovitost svog rada. Kao primjer uzeću projekt razvoja mobilne aplikacije.
Mali disclaimer. U ovom članku nema opisa osnovne funkcionalnosti TestRail-a (za to postoji mnogo vodiča) i prodajnih izraza koji slikovito opisuju zašto odabrati upravo ovog dobavljača za kreiranje repozitorija sa testovima.
Plan realizacije (što će biti ostvareno)
Opći zahtjevi
Kao osoba, svatko bi trebao moći proći kroz slučaj
Slučajevi bi trebali održavati aktualnost što je duže moguće
Slučajevi bi trebali što bolje pokrivati funkcionalnosti mobilne aplikacije u onoj mjeri u kojoj to ne proturječi prva dva stava
Podjela na TestCase i TestScenario
Brza kreacija TestRun različitih tipova
Smoke
Regress
Impact testiranje itd.
Optimizacija podrške slučajevima
Odustajanje od "mrtvih" hardkodiranih snimaka i prelazak na "pokretne podatke"
Zahtjevi
Za uređivanje polja bit će vam potrebna administratorska prava
Odabir tipa projekta
Možete odabrati tri tipa projekata:
Odabrati ćemo zadani tip. U njemu će biti dostupni svi slučajevi. Koristit ćemo pametno filtriranje i dinamički upravljati svim slučajevima odjednom.
Dodavanje polja za prikaz liste test slučajeva
Dodajmo polje za prikaz prioriteta test slučajeva:
Također možemo dodati i druga polja.
Postavke polja i oznaka testnog slučaja
Otvorite izbornik postavki:
Trebat će nam sljedeća polja:
Polje "Summary" (zaglavlje testnog slučaja)
Ovo polje već postoji, samo sistematiziramo njegovu upotrebu. Razdvojit ćemo slučajeve na TestCase i TestScenario. Za bolju čitljivost velikog popisa slučajeva bolje je unaprijed dogovoriti se o regulativi pisanja sažetka.
TestScenario:
Primjer: TestScenario — Glavni scenarij korištenja mobilne aplikacije
TestCase:
Primjer: MainScreen — Odjeljak za prijavu — Unos korisničkog imena
Na kraju, vidimo u sažetku slučaja klasično razumijevanje: "što, gdje, kada". Također vizualno razdvajamo višerazinske testne scenarije i nižerazinske testne slučajeve na najprikladniji način za automatizaciju.
Tag «StartScreen» (ekran s kojeg počinje TestScenario, također mnogi test slučajevi mogu se odnositi na susjedne ekrane)
Čemu može poslužiti: uklonit ćemo iz teksta test slučajeva tipične korake koji vode korisnika na ekran trenutnog test slučaja. (tipični koraci za stvaranje određene testne situacije) Svi tipični koraci za sve test slučajeve bit će navedeni u jednoj datoteci. O tome ću detaljnije pisati posebno.
Stvaramo novo polje:
Ispunjavamo komponente novog polja:
U ovom slučaju stvaramo polje za odabir iz liste vrijednosti. Unosimo vrijednosti ovog polja:
Obratite pažnju da id vrijednosti ne počinju od jedan i ne idu uzastopno. Zašto je to tako? Riječ je o tome da ako imamo zabilježene test slučajeve s unesenim id-om,
i nakon toga ćemo morati stvoriti treći ekran između dva postojeća,
morat ćemo prepisati id, a budući da su mu već pridruženi tagovi postojećih test slučajeva, oni će jednostavno nestati. To će biti vrlo neugodno.
Tag «Screen» (naziv ekrana koji se dotiče TestCase)
Čemu može poslužiti: jedan od sidara za impakt testiranje. Na primjer, programeri su napravili novu cool funkciju. Moramo je testirati, ali da bismo to učinili, moramo shvatiti što je točno ova funkcija mogla utjecati. Po defaultu se možemo osloniti na paradigmu da različiti ekrani (Activity) aplikacije imaju različite klase i stoga čine različite komponente aplikacije. Naravno, u ovom slučaju je potreban individualan pristup.
Primjer: home_screen, MapScreen, PayScreen itd.
Polje «MovableData» (veza na proxy BDP s promjenjivim testnim podacima)
Zatim ćemo pokušati riješiti problem održavanja ažurnosti podataka u test slučajevima:
Linkovi na ažurirane makete (to je daleko bolje nego raditi mrtve snimke zaslona)
Tipični koraci do ekrana s testnom situacijom
SQL upiti
Linkovi na vanjske podatke i druge podatke
Umjesto da unosimo testne podatke unutar svakog testa, kreirat ćemo jednu vanjsku datoteku na koju će se svi testovi pozivati. Kada ažuriramo te podatke, nećemo morati prolaziti kroz sve testove i mijenjati ih, nego ćemo moći promijeniti te podatke samo na jednom mjestu. Ako netko neupućen otvori test, vidjet će u tijelu testa vezu na datoteku i savjet da treba ići po testne podatke.
Sve te podatke upakirat ćemo u jednu vanjsku datoteku koja će biti dostupna svima u projektu. Na primjer, možemo koristiti Google Sheet ili Excel i unutar datoteke postaviti pretraživanje. Zašto baš ti pružatelji? Stvar je u tome da polazimo od paradigme da svaki član tima treba moći otvoriti i proći kroz test bez potrebe za instaliranjem alata unaprijed.
Za Google Sheet možemo koristiti SQL upite. Primjer:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Za Excel možemo postaviti praktične makroe za trenutna pretraživanja. (filtriranje) Primjer .
Ideja nije nova i opisana je u prvoj knjizi testera "Testiranje dot com". (autor Savin Roman) Samo integriramo metode koje je predložio Roman Savin u TestRail. Za to ćemo stvoriti polje s vezom na kreiranu datoteku:
ispunjujemo zadanu vrijednost veze, tako da u svakom novom testu već bude veza:
Ako se lokacija vanjske datoteke promijeni (predviđamo bilo kakav nepredviđeni slučaj), možemo lako promijeniti jedno ili više polja u svim testovima:
Polje "Descriptions" (opis ili ideja testa, standardne upute)
Za što može biti potrebno: U ovo tekstualno polje stavit ćemo kratki opis testa i standardne upute.
Primjer: Svi testni podaci (aktualni modeli, korištenje alata i drugi podaci) iz ovog testa označeni su vezama {…} i nalaze se u datoteci MovableData. Veza na MovableData nalazi se u odgovarajućem polju na vrhu.
Tag "Component" (komponenta mobilne aplikacije)
Za što može biti potrebno: za impakt testiranje. Ako se mobilna aplikacija može podijeliti na komponente (koje što manje međusobno utječu) onda će promjene u jednoj komponenti biti dovoljne (uz određene rizike) da se provjere unutar te iste komponente, što smanjuje potrebu za provođenjem sveobuhvatnih regresija svega i svačega. Ako postoji informacija da jedna komponenta može utjecati na drugu, tada se sastavlja matrica impakt testiranja.
Primjer komponenti: GooglePay, Narudžba, Korisnici, Mapa, Autorizacija i sl.
Tag «TAG» (Ostali tagovi za filtriranje)
Označavanje testnog slučaja tagovima za proizvoljno filtriranje.
Vrlo korisno za:
brzo sastavljanje TestRun za razne tipične zadatke: smoke, regresija i sl.
hoće li testovi biti automatizirani ili su već automatizirani
bilo koje druge oznake
Primjer: Smoke, Automatizirani, WhiteLabel, ZaBrisati i sl.
Postavljanje reda prikazivanja polja u testnom slučaju
Kreatili smo mnogo novih polja, došlo je vrijeme da ih poredamo u praktičnom redu:
Izrada TestRun-a
Sada ćemo stvoriti novi test run s aktualnim slučajevima za provođenje smoke testiranja u tri klika:
Ostali korisni savjeti
Ako u TestRail-u ima nekoliko projekata, ne zaboravite stvarati nova polja samo za Vaš projekt, inače će kolege iz susjednih timova biti vrlo iznenađene pojavom novih neobičnih polja. Mogući su lokalni kolapsi.
2. Slučajeve s velikim brojem polja lakše je kopirati iz slične grupe nego stvarati nove:
3. Možete zajednički koristiti korisničke račune. Na primjer: jedan administratorski, nekoliko korisničkih.
Zaključak
Gore navedeni primjeri implementirani su na nekoliko projekata i pokazali su svoju učinkovitost. Nadam se da će Vam pomoći poboljšati razumijevanje ovog alata i pomoći u stvaranju učinkovitih i praktičnih 'test pohrana'. Bio bih vrlo zahvalan ako u komentarima opišete Vaše iskustvo korištenja TestRail-a i korisne savjete.
Linkovi:
Knjiga:
Hvala vam puno na pažnji!
Izvor: habr.com
