Quality Assurance - QA

DAN 3
O firmama

 Savetujem da za prvi posao izbegavate startup kompanije i freelance poslove.

 Razlog zašto izbegavati startup kompanije je taj što često nisu stabilne, ne znate koliko
dugo ćete raditi, koliko ćete imati posla i učiti. Sa druge strane pitanje je i koliko biste
radili baš QA posao, jer vas možda zaduže i drugim stvarima koje se ne tiču testiranja.
 Razlog zašto izbegavati freelance je taj što u početku tamo nemate ogromnu pomoć
kolega QA i ostalih članova tima. Mnogo brže će vam pokazati kako se radi i za prvi
posao nije zdravo baš raditi sam. Ako radite freelance preko neke platforme bez iskustva,
može se desiti da ne odradite dobro posao i dobijete loše ocene, pa možete da imate
problem kasnije da nađete klijente.
 Outsource firma

 QA Outsource firma se bavi samo testiranjem, u timovima nema developera, project managera, BA, PO. Već firmu
angažuje druga firma koja je odradila development, pa treba samo izvršiti testiranje.
 Kod ovakvih firmi komunikacija sa klijentima koji su nas angažovali je najbitnija.
 Negativni aspekti: Ako bude bug na produkciji mi smo uvek krivi, nema deljenja krivice kao kod timskog rada u firmi koja
u developmentu ima i QA. Firme koje našu angažuju mogu biti ’razmažene’, u smislu da traže neke nerelane uslove ili
rokove, takve firme često znaju da naplaćuju penale i samo traže razloge da plate što manje uslugu testiranja. One se često
vode pravilom ’kupac je uvek u pravu’ i da mora biti kako oni kažu. Outsource firme često popuštaju klijentima iz straha
da ih ne izgube kao klijenta. Komunikacija može biti ozbiljan problem, jer ako ne testiramo nešto kako su oni hteli, mogu
da koriste argument ’Zašto niste pitali?’ i tu se takođe naplaćuju neki penali.
 Pozitivni aspekti: Svi su okrenuti ka testiranju i tu je glavni fokus. Uvek ćete imati kolege koji će vam uvek pomagati,
mnogo više može da se nauči, pogotovo za početnike. Podaci su transparentni i svaki bug se prijavljuje (u development
firmama se takođe svaki prijavljuje ali nekad je brže rešiti problem usmeno sa developerom).
Outsource firma
Oglasi za posao

 HR često ubacuje prevelike zahteve za posao u oglasima. Ovo rade namerno zbog prijava.
 Zamislite skalu znanja od 1 do 100.
Ako HR u oglasu traži 10, dobiće osobu sa znanjem 10.
Ako HR u oglasu traži 100, prijave se osobe koje ispunjavaju samo pola onda će dobiti
osobu sa znanjem 50.
Kada se uporedi, bolje je imati osobu sa znanjem 50 nego 10.
Svesno znaju da ne mogu naći osobu koja sve to ispunjava, ali traže osoba za posao da
bude barem približno dobra u odnosu na to šta su tražili.
Test Strategija

 Test strategija nalaže kakav će proces testiranja biti. Strategiju kreira project manager i
nakon kreiranja nije moguće menjati stategiju. Test strategija se piše kao dugoročni plan
na koji će se oslanjati dok traju projekti.
 U test strategiji se određuje kada i koliko sastanaka će biti, kakve su procedure i
komunikacije sa klijentom. Kroz strategiju se lakše prati rad na projektu.
 Test strategija može biti kreirana da važi i za više projekata.
 Ukratko, test strategija je dokument u kom piše kako treba odraditi testiranje na
organizacionom nivou.
Test Plan

 Test plan je dokument koji određuje scope, cilj i metodu testiranja. Ovaj dokument piše
QA lead ili QA senior i nakon kreiranja je moguće praviti izmene u ovom dokumentu.
 Ovaj dokument nalaže ko testira, šta testira, kada testira i na koji način.
 Test plan se kreira posebno za svaki projekat.
 Ukratko, test plan je dokument koji sadrži sve potrebne informacije za testiranje
određenog projekta.
Test Case

 Test case (TC) je dokument u kome izvršavamo jedan određen test i u kom pišemo svaki
korak testiranja, očekivano ponašanje, preduslove za testiranje i korišćene inpute.
 Test case MORA da sadrži sledeće elemente:
Test Case ID (jedinstven broj)
Test Case Name (jedinstven naziv)
Korake (akcije)
Očekivano ponašanje (za svaki korak)
Inpute
Test Case Name Forma

 Verify that “action“ produces “expected result“ + (when “condition“)

 Verify that click on back button returns user to previous page

 Verify that text is visible when we open a document
 Verify that clicking on “Log out” button logs out user when they are logged in

 Test case name mora biti unikatan, da bi se po imenu moglo znati šta se tačno testira.
 Test Case nepisana pravila

 Za pisanje kejseva izbegavamo “he” ili “she”, već koristimo neutralni rod.
 Za očekivani rezultat ne sme da se piše “Nothing happens”, već moramo da opišemo kakvo je stanje.
 Svaki korak MORA da ima očekivani rezultat iako je korak jednostavan.
Recimo, ako je korak Otvori browser, onda očekivani rezultat mora biti Browser se otvorio. Koliko god da zvuči glupo,
pisanje očekivanog rezultata za svaki korak je OBAVEZAN!
 Preduslov se piše ako je neko stanje bitno pre početka testiranja, recimo povećan font, upaljen dark mode, konekcija je
isključivo preko Wi-fi...
 Preduslov takođe može da se piše kao odrađene akcije na aplikaciji da bi se došlo do dela koji testiramo. Ali je obavezno
testiranje tih akcija PRE pisanja ovog kejsa. Na primer, ako testiramo na Fejsbuku komentarisanje slika i da skratimo posao
da ne pišemo korake za registraciju i log in, onda možemo u preduslov napisati “Korisnik je registrovan i ulogovan na svoj
nalog”.
 QA koji kvalitetno i detaljno piše test kejseve se pokazuje kao dobar QA i dobija poštovanje od drugih kolega.
 Test case nepisana pravila

 Test kejseve je bitno pisati što detaljnije da bi mogle ostale kolege ili naslednici na našim pozicijama da razumeju sve. Pišete
tako da može da razume i neko “koga uzmete sa ulice”.
 Uvreda je kada neko pita šta ste mislili kada ste nešto napisali, jer to znači da to nije razumljivo i da ne radimo dobro svoj
posao.
 Input za svaki korak može, a i ne mora, da ima posebno polje. To polje se naziva “Input data” i popunjava se samo sa
informacijama koje unesete sa tastature, recimo koji tačno username ili šifru ste uneli. Treba i naznačiti da li je ta
informacija validna ili ne. Naznaku da li je informacija tačna ili ne, možete upisati i u sklopu akcije. Takođe u sklopu akcije
možete napisati input.
 Naziv polja i dugmića pisati pod navodnicima.
 Obratiti pažnju na detalje u pisanju očekivanog ponašanja. Obavezno je napisati ŠTA tačno je očekivano ponašanje,
pogotovo kod nevalidnih unosa.
 Očekivano ponašanje
POGREŠNO
 Test case name: Verify that user cannot log in with invalid
username
 Step 1: Input invalid username (example: 111)
 Expected result: Username is entered and visible
 Step 2: Input valid password (example: pass)
 Expected result: Password is entered and visible
 Step 3: Click “Log in” button
 Expected result: Notification appears that username is
invalid
ISPRAVNO
 Test case name: Verify that user cannot log in with invalid
username
 Step 1: Input invalid username (example: 111)
 Expected result: Username is entered and visible
 Step 2: Input valid password (example: pass)
 Expected result: Password is entered and visible
 Step 3: Click “Log in” button
 Expected result: User did not log in and notification
appears that username is invalid
 Input data primer

Način 1 Način 2
 Test case name: Verify that user can log in with valid credentials  Test case name: Verify that user can log in with valid
 Step 1: Input valid username credentials
 Input data 1: “Hodor”  Step 1: Input valid username (example: Hodor)
 Expected result: Username is entered and visible  Expected result: Username is entered and visible
 Step 2: Input valid password  Step 2: Input valid password (example: hodorhodor)
 Input data 2: “hodorhodor”  Expected result: Password is entered, visible and covered
 Expected result: Password is entered, visible and covered in dots in dots
 Step 3: Click “Log in” button  Step 3: Click “Log in” button
 Input data 3: /  Expected result: User is logged in
 Expected result: User is logged in
Nazivi ekrana
Test Scenario

 Test Scenario predstavlja skup test kejseva za određenu funkcionalnost. Ako je

funkcionalnost malog obima, onda test kejs može da se smatra kao test scenario.
 Primer: Test scenario za login stranicu može biti ’Proveri da li korisnik može da se
uloguje samo sa ispravnim kredencijalima.’
Ako login stranica ima samo polje Username i Password, onda u to spadaju sledeći test
kejsevi:
Verify that user can log in with valid credentials
Verify that user cannot log in with invalid username
Verify that user cannot log in with invalid password
Verify that user cannot log in with invalid username and invalid password
Test Suite

 Kolekcija test kejseva za proveru određenog dela aplikacije. Da bi taj određen deo
funkcionisao kako treba svi test kejsevi moraju da prođu bez greške. Bitan je redosled
kojim se prolaze test kejsevi.
 Primer: Ako izaberemo test suite za testiranje dodavanje slika na Fejsbuku, onda treba da
proverimo test case za uspešnu registraciju, zatim za uspešan log in, za uspešno otvaranje
mogućnosti dodvanja slike i na kraju test case za uspešno dodavanje slike. Dakle, ovim
redosledom mora se odraditi testiranje i test suite će pasti ako bilo koji kejs padne.
Treba primetiti da test kejsevi su za različite funkcionalnosti.
 U Test Suite-u jedan Test Case je smatran kao korak do određenog rezultata.
Krivica i kazna

 QA može biti odgovoran u dve situacije ako nešto ne radi kako treba.
1) Ako nije obavio testiranje.
2) Ako je pronašao bug i nije prijavio. Ili pronašao bug i smatrao da nije bug.
 Kazne uglavnom budu usmene opomene, ponekad finansijske kazne (5-10% plate) i u baš
retkim slučajevima otkaz.
Test case primeri