Kako izgleda proces testiranja softvera
Pre nego što uđem u priču kako izgleda taj proces testiranja softvera ili aplikacije, moram brzinski da se osvrnem na određene pojmove koji se koriste u testiranju, kao što je na primer QA u reči ‘’QA tester’’ i šta uopšte znači testirati neki softver. Siguran sam da znaš, ali da napomenem, QA označava Quality Assurance, a to bukvalno znači garancija kvaliteta.
Dolazimo do logičnog zaključka da je posao QA testera da garantuje ili osigura da kvalitet proizvoda zadovoljava ili potvrđuje poslovne i tehničke zahteve klijenata ili korisnika proizvoda. To je jedna od definicija, ali plastično rečeno u softver svetu, zadatak je, pored ostalog, da se osigura da određeni softver nema bagova ili grešaka prilikom rada. Neka vrsta bug hunter – a :). U ostalo spada na primer, preporuka za promene u izradi kako bi se dostigao bolji kvalitet proizvoda.
Testiranje je glavni, primarni put da se ispita da li određeni softver ispunjava zahteve QA, stoga je važno detaljno isplanirati ceo proces testiranja, kako bi se slučajno ne bi prikrio neki esencijalni bag koji može da ugrozi krajnjeg korisnika. Postoje primeri iz realnog života koji su jezivi, od ne tako strašnih (ali opet esencijalnih), kao što je na primer googlov Nest termostat, gde posle softver apdejta, korisnici nisu mogli da zagreju prostorije, jer novi apdejt ‘’suši’’ bateriju uređaja, do rušenja aviona u Španiji 2015-te godine, gde je posada poginula usled softver baga.
Nije to samo sedi, lupaj po aplikaciji, igraj se i zapiši šta si radio. Ne ide to baš tako, iako postoje elementi ovog naklapanja u sastavu poslovnog dana softver testera. Naravno da će tester isprobavati određenu funkcionalnost aplikacije, da će testirati i pretumbati celu aplikaciju uzduž i popreko, usput će voditi dokumentaciju oko celog procesa, ali nemoj misliti ni u jednom trenutku da je to besmislen posao. Ako tester naleti na neki bag (a hoće), dokumentovaće ga tako što će u najsitnije detalje opisati ceo proces pronalaska, kako bi developer ispravio grešku u kodu. Ono što je ključno razumeti – nijedan softver nije bug free.
Koji skillovi su ti potrebni za QA testera?
Kada govorimo o ličnosti pojedinca, generalino, možemo istaći:
Analitičke veštine, gde se deli određeni sistem na više manjih modula ili celina, kako bi se bolje razumelo šta treba da se testira i u kojim uslovima.
Komunikacione veštine, što mislim da je jasno, jer u principu, ovo treba svuda, čak i kad ideš u prodavnicu po namirnice, a kamoli kad radiš u nekom timu koji izrađuje softver.
Organizacione veštine, pogotovo time management, gde se definiše koliko je potrebno vremena za određene testove, jer se tako lakše orgainizuje obim posla, povećava produktivnost i slično.
Stav, gde ti ovo možda deluje smešno, ali u suštini jako bitna osobina, jer ako imaš stav da ćeš ‘’polomiti’’ softver da nađeš bag, olakšaće proces u daljem radu kroz karijeru i jako je važno da imaš ‘’drčnost’’ u odbrani svog testa, jer ti si taj koji treba da osigura kvalitetan proizvod.
Spremnost za učenje, što je u principu jako bitno kojim god poslom da se baviš u IT sferi, jer ako si spreman da uložiš slobodno vreme u učenju novih tehnologija, nećeš morati da brines za dalji napredak.
Šta ti je potrebno da znaš da postaneš QA tester?
Potrebno je osnovno znanje o bazama podataka/SQL, jer su podaci sačuvani u određenim tipovima baza, gde se često pišu kveriji (queries) za pozivanje iz baze, pogotovu kad se dogura do automatizacije testova. Osnove linux komandi će dobro doći, jer su veb servisi uglavnom razvijani na linux operativnim sistemima. Različiti test management alati se uče u zavisnosti od tehnika testiranja, kompanije i tima u kojem se radi, ali to će ti neko iz tima već detaljnije objasniti kad uspeš da se uglaviš. Na kraju krajeva, možeš izguglati šta je od tih softvera potrebno naučiti, pa piči samostalno da budeš što spremniji :).
Kasnije ćeš sticati znanje o automatizaciji i alatima koji će ti pomoći oko testiranja, ali isto važi i ovde kao u prethodnom koraku, gde testovi zavise od tima i kompanije, pa i softvera koji se izrađuje i tako dalje… Veliki plus će ti doneti znanje iz jezika poput javascripta, pythona, jave, C# (koji nije jezik nego frejmvork, da se ne naljute neki 🙂 ).
Proces testiranja
Ovde se susrećemo sa pojmom STLC ili Software Testing Life Cycle. STLC predstavlja niz specifičnih aktivnosti koje se sprovode tokom procesa testiranja, kako bi se osiguralo da su ispunjeni svi kriterijumi i ciljevi kvaliteta softvera. Nije samo kliktanje i ‘’lupanje’’ po aplikaciji da bi ulovio bag, već postoje neke aktivnosti koje moraju da se metodološki sprovode kako bi se testiranje obavilo kako dolikuje.
Faze koje su zastupljene u procesu testiranja su:
- Analiza zahteva (Requirements),
- Planiranje testa (Test Planing),
- Razvoj test slučaja (Test case),
- Postavljanje test okruženja (Environment setup),
- Izvršenje testa (Execution),
- Zatvaranje procesa testiranja (Cycle closure).
Svaka faza ima svoj ulazni i izlazni kriterijum na svim nivoima u procesu testiranja. Često se na ovo u praksi i ne obraća toliko pažnje, jer je svakako to u sklopu test faze, ali rek’o da pomenem :).
Svaki test se obavlja pojedinačno i ne sme biti u bilo kakvoj vezi sa drugim testovima. Ukratko ću proleteti kroz ove faze da otprilike stekneš utisak o čemu se tu zapravo radi.
Analiza zahteva
U pitanju je aktivnost gde tim analizira određene kriterijume po kojima se vrše ispitivanja, odnosno pregleda se kompletna dokumentacija koja se odnosi na proizvod da bi se ustanovile koji tipovi testiranja su potrebni i u kom obimu. QA tim je u konstantnoj komunikaciji sa stejkholderima (glavešinama kompanije) oko ovih detalja. Zahtevi mogu biti za funkcionalno ili nefunkcionalno testiranje, a ovde se odlučuje i da li će se i gde, vršiti automatizacija testiranja.
Planiranje testa
Faza u kojoj senior QA menadžer utvrđuje strategiju plana testa, kao i procenu troškova i potrebnog vremena da se projekat završi. Odlučuje o resursima, okruženju za testiranje, rasporedima i silčno.
Razvoj test slučaja
Uključuje verifikaciju testova i skripti kroz dokumentaciju, nakon što se planiranje završi. Identifikuju se relevantni podaci za testiranje, kreira se test dokumentacija, kao i skripte za automatizaciju i QA tim započinje testove za pojedinačne module.
Postavljanje test okruženja
Faza gde se određuju softverski i hardverski uslovi testiranja određenog proizvoda. Ova faza se u nekim slučajevima radi paralelno sa fazom razvoja test slučaja.
Faza izvršavanja testa
Sprovode je testeri po prethodnom planu i kreiranim slučajevima (cases). Proces se sastoji od izvršenja test skripti kao i njihovo održavanje i prilagođavanje, ukoliko je potrebno, izveštavanju o eventualnim bagovima, prijava istih i vraćanje na ponovno testiranje nakon ispravke.
Faza zatvaranja procesa testa
U ovoj fazi dolazi do završetka izvođenja testa, gde se izveštava o završetku i rezultatima testiranja. Prikupljaju se relevantni podaci i članovi tima se sastaju da bi raspravili i analizirali završene testove i odlučuju o eventualnim promenama plana testiranja, njihovom adaptiranju, strategiji i slično, kako bi se napravio prostor za nova testiranja.
Postoje metodologije koje zavise od organizacije tima po kojima se testiranje obavlja. U svim fazama postoje odstupanja u načinu organizovanja testa, tako na primer, u nekim timovima ne postoje test slučajevi, ili se ne obavljaju testiranja nakon izrade pojedinačne funkcionalnosti aplikacije, nego u celini kad se aplikacija pusti u rad pre predavanja krajnjem korisniku. To zavisi od pomenutih metodologija, a najzastupljeniji su ‘’Agile’’, ‘’Scrum’’ i ‘’Waterfall’’.
Ko je sve uključen u tim?
Tim zavisi od kompanije i metodologije rada, ali neka generalizacija tima bi bila saradnja sa developerima – oni (siguran sam da znaš), izrađuju softver koji ćeš da testiraš :), product owneri – kontrolišu ceo postupak izrade, project menadžeri, negde i SCRUM masteri – planiraju i usmeravaju projekat, određuju prioritete, komuniciraju sa svima u timu, dizajneri – koji, logično, dizajniraju izgled aplikacije, QA testeri – su uključeni u skoro svaki sastanak kako bi bili upoznati sa softverom koji se izrađuje i testira i tako dalje.
To bi bila neka generalizacija tima, gde ćeš u nekim okruženjima videti manje članova, a negde i mnogo više. U svakom slučaju, kao QA tester, ne gine ti mnogo utrošenih sati na različite sastanke.
Mitovi i predrasude
Neki od mitova koji se vezuju za ovu poziciju u IT sektoru: softver testiranje je dosadno, slabo plaćeno, da se slabo ili minimalno može napredovati, da nema poentu i slično. Po meni, ovo su gluposti, jer iako sam neko ko ne voli suvu teoriju, meni deluje zanimljivo i ljudi sa kojima sam pričao na tu temu, koji rade kao QA, potvrđuju isto. Nekome može biti dosadno, nekome ne, tu se pozivam na deo teksta o stavu i učenju, a što se poente ove pozicije tiče, mislim da iz prvog dela teksta gde sam opisao neke primere, jasno govori da je ovo jedna od ključnih pozicija u softver development-u, a i da te podsetim na čuveni majkrosoftov klip gde im se srušio operativni sistem na predstavljanju nove verzije. Tad očigledno nisu imali pozicije testera u kompaniji. Što se napredovanja tiče, sve zavisi od tebe i tvoje spremnosti na učenje, ali ako ti ovo ne deluje dosadno, svakako je dobar prvi korak da se ubaciš u IT i softver testiranje.
Izvor: Helloworld, Ivan Kuzmanović
