Kvalitet je obilježje svakog proizvoda. Kontrola kvaliteta u razvoju softvera, kao cjelokupna aktivnost evaluacije softvera, osigurava da aplikacija zadovoljava ili premašuje unaprijed određene standarde kvalitete. Za svaki proizvod ili manje taskove, definiraju se očekivani rezultati.
Većina bugova su plod pogrešne izvedbe u izvornom kodu ili dizajnu. Bugovi se dijele na interne i eksterne (odbijenice), a može se reći da je odbijenica u proizvodnji zapravo bug u softverskom razmišljanju
Pitanje plana kontrole kvalitete
Pisanje plana kontrole kvalitete u IT sektoru je vrlo važno za dalji proces. Plan je tu da nam pokaže kako se upravljanje kvalitetom primjenjuje u praksi. Za svaki proizvod ili taskove definiraju se očekivani rezultati, i ako nešto od toga ne ispunjava očekivani rezultat, znači da ne prolazi testiranje i kontrolu kvalitete. Prof. Jure Begić, QA engineer u tvrtki Galileo d.o.o., Mostar, upoznao nas je sa procesom kontrole kvalitete, kao inicijalnog faktora u proizvodnji softvera.
“U IT sektoru je prednost što imamo mogućnost prilaganja privitaka uz svaku akciju koju moramo proizvesti, kao što su link, gifovi ili videi, tako da programer koji gleda linije koda ne mora uopće znati kako softver korisničke strane funkcionira”, naveo je prof. Begić.
Da bi se određeni radni nalog u proizvodnji izvršio, potrebno ga je razložiti na manje dijelove, odnosno operacije. Ako se za primjer uzme instagram story, user story se razlaže na manje taskove. Jedan user story može imati više taskova, i naravno, više taskova se može odnositi na više djelatnika.
“Tu je i vrijednost svakog user storiya i planirane i neplanirane aktivnosti. Bez obzira koristite li stranu metodologiju, ukoliko isplanirate neki sprint (periodicni vremenski interval razvoja softvera), uvijek se dogode neplanirane aktivnosti, koje naravno utječu i na vaš raspored i na evidenciju. Zbog toga imamo dvije podjele: to su planirane aktivnosti, one koje se u nekom dosljednom sprintu isplaniraju, i neplanirane aktivnosti.”
Prilagodba zadataka prema kvalifikaciji djelatnika
Svi zadaci se prvenstveno raspoređuju djelatnicima u timu, na osnovu njihovih kompetencija. Potrebno je gledati iskustvo i kvalitet djelatnika, te da li može izvršiti određeni zadatak i u kojem vremenskom intervalu. U svakom tasku i u svakoj operaciji radnog naloga, postoje tačno definirani koraci i očekivane vrijednosti. U svakom trenutku je jasno koji dio tima radi na kojem dijelu i koje su očekivane vrijednosti na kraju tog zadatka.
“Isto kao i u proizvodnji gdje imate radnika koji radi na stroju 15 godina i dobro poznaje CNC mašinu, tako i u IT sektoru programer sa većim iskustvom sigurno može uraditi task brže i jednostavnije u odnosu na onog koji je počeo prije godinu dana. Za svaki korisnički zahtjev, za svaki task predviđamo resurse za vršenje, koliko ljudi treba, koliko vremena, da bi naravno mogli kasnije sve uzvratiti i kupcu dati povratnu informaciju.”
Postoji mogućnost neograničenog unosa broja akcija. Što je više akcija uneseno za određeni task, to je manja šansa za propuštenim bugovima, odnosno greškama. Da bi sve te akcije nakon proizvodnje softvera proveli, postoji alati za automatsko ponavljanje.
“Danas su popularni video recorderi, gdje tester snimi šta softver treba odraditi, svaku akciju. Ukoliko se desi neka inormna promjena, tester neće svaki put prolaziti kroz te korake, nego ide automatsko izvršavanje akcija. Mi imamo u cilju ispunjavanje zahtjeva kupaca i smanjenje grešaka, budući da se kvaliteta različito gleda sa stajališta kupca, proizvođača ili tržišta.”
Većina bugova su plod pogrešne izvedbe u izvornom kodu ili dizajnu. Bugovi se dijele na interne i eksterne (odbijenice), a može se reći da je odbijenica u proizvodnji zapravo bug u softverskom razmišljanju.
Eksterni bugovi se uvijek odnose na neplanirane zahtjeve i prioritet su u odnosu na ostale stvari da se riješe. Interni bugovi su bugovi primjećeni u toku razvoja softvera. Međutim eksterni bugovi su neplanirani zahtjevi od klijenta i prioriteti se redefinišu. Zbog toga su isprva navedeni prioriteti rješavanja isporuka. Svaki korisnik prioritizira bug sa kojim se trenutno suočava i želi da se adresira što prije, međutim to u stvarnosti nije izvodivo i prioritet nije realan.
