Da li je QA neophodan?
Iako na prvi pogled deluje moguće da programeri testiraju svoj kod ta praksa se pokazala neodrživom na duži vremenski period i veoma štetnom za kompaniju u celini.
Pokazalo se da programeri kad prave testove i inače vrše testiranja nemaju dobru logiku za pronalaženje Bug-ova. Njihovi testovi pokrivaju samo pozitivne Test Case-eve izbacujući sva testiranja preko negativnih Test Case-eva i sva testiranja manje verovatnih akcija korisnika. Programeri prave plan za testiranje i sama testiranja na način da Test Case-evi prolaze uvek što povlači za sobom lažnu predstavu da Aplikacija nema Bug-ova.
Na kraće staze testiranje od strane programera je održivo medjutim na duže staze u Produkciji Aplikacija kreće da pokazuje Bug-ove koji mogu da postanu opasni i jako štetni kad krajnji korisnici Aplikacija dodju u dodir sa Bug-ovima. Kompanija koja proizvodi Aplikaciju kreće da plaća penale, njen rejting kreće drastično da opada. Šteta proizvedena zbog pojave Bug-ova u Produkciji nekad bude i 1000 puta veća od troškova QA podrške.
Komunikacione veštine QA inženjera
Iako zvuči možda kao preterano QA inženjer mora da poseduje veštine u komunikaciji u timu jer je on član tima koji nalazi greške u tudjem radu što dosta puta nije prijatno pa se komunikacija mora odvijatu u smeru da programeri shvate pronadjen Bug ne kao kritiku već kao podršku u radu.
Ukoliko je pronadjeni Bug u Produkciji QA mora da izvrši velik pritisak na tim da se Bug odmah reši jer postoji opasnost da klijent i krajnji korisnici Aplikacije imaju problem.
Ukoliko je pronadjeni Bug čisto kozmetičke prirode, pronadjen je na Staging okruženju i neće u skorije vreme otići u Produkciju QA bi trebao da postavi minorni prioritet za rešavanje problema i da se tako postavi prema programeru koji treba da reši Bug.
Preciznost, brzina i širina u davanju informacija
Jedan od glavnih problema pri izveštavanju tima ili konkretnog programera je neshvatanje šta je QA hteo da kaže ili nedostatak potrebnih informacija za reprodukciju Bug-a.
QA mora da u Bug izveštaju pruži sve potrebne informacije za reprodukciju Bug-a, šta je očekivano ponašanje, video, screenshot, HAR file…
Problemi mogu nastati i zbog kasnog nalaženja i izveštavanja o Bug-u. QA mora da izvrši testiranje tiketa čim je sve spremno za testiranje kako ne bi došlo do situacije da programeri nemaju vremena za rešavanje Bug-a usled skorog Deployment-a u Produkciju.
Pored testiranja tiketa QA mora da održava nivo u preciznosti, brzini i širini davanja informacija i u drugim QA sferama na projektu.
Svaki Test Case mora biti napisan tako da svako može da ga reprodukuje. Sve potrebne informacije za reprodukciju Test Case-a moraju biti napisane.
Automatski testovi moraju biti napisani tako da se pokriva širok aspekt testiranja, prost primer je da preko screenshot opcije ako QA radi u Playwright-u se proverava cela stranica a ne samo preko url-a da li je učitan ili ne jer stranica može biti učitana ali odredjeni Web elementi mogu da budu izostavljeni ili da imaju loš dizajn pri učitavanju.
Sposobnosti logičkog rasudjivanja
Da bi QA mogao uspešno da obavlja svakodnevne zadatke mora da poseduje odredjeni nivo logičkog rasudjivanja iz sfere testiranja. QA mora da razmišlja ne samo o na prvi pogled realnim akcijama koje bi uradio krajnji korisnik već i o manje realnim akcijama koje bi izveo kranji korisnik jer upravo Test Case-evi koji pokrivaju takve akcije neće biti testirani od strane nikog ukoliko ih QA ne pokrije.
Velik deo Aplikacija na tržištu je radjen za potrebe bankarskog, finansijskog sektora gde svaka greška može biti jako skupa i gde se traže sve moguće rupe u sistemu i ako QA nema logiku da testira sve moguće rupe u sistemu Aplikacija može da ode u Produkciju sa mogućnošću da neko “provali” u sistem i nanese ogromnu štetu u jako kratkom vremenskom periodu.
Svest o bitnim datumima
U razvoju Aplikacije u odredjenim vremenskim periodima dolazi do velikih Deployment-a (velikih promena u Aplikaciji u Produkciji). Ovo su jako bitni datumi za celu kompaniju jer se dešava da zbog odredjene promene čak nekad i cela Aplikacija prestane da radi što je ogromna šteta za kompaniju, klijenta, krajnje korisnike.
Dobar QA je svestan svih bitnih datuma na svom projektu i prilagodjava svoje radno vreme i resurse da bude najspremniji i najviše prisutan pred velike Deployment-e.