Kako programirati softver koji se može naplatiti: 4 koraka u procesu testiranja

Predstavljam Vam Sašu Mihajlovića.

Saša radi na čelu softverske firme i on će opisati 4 koraka neophodna da softver koji projektujete i kreirate, bez obzira na veličinu, radi na način da su korisnici spremni da ga plate:

Zdravo. Saša ovde.

Pošto sam ja na čelu firme koja se bavi projektivanjem, izradom i implementacijom softverskih proizvoda, uzeću primer rada naše firme i time Vam opisati kako smo primenili softversko testiranje za razvoj našeg softvera.

Pokušaću da na primerima kako smo radili i kako bi trebalo da radimo u skladu sa onim što sam učio na ITAcademy pokažem koliko se dobija u uštedi vremena i troškova razvoja softvera pravilnim testiranjem tokom svakog koraka razvoja.

Funkcionalno testiranje i naše realno iskustvo

Uzeću za primer naš sofver za praćenje i analizu poslovanja u firmama, i to recimo, deo koji se bavi fakturisanjem roba i usluga kupcima, kao i sve elemente koji su za to vezani.

Do sada, kada smo radili funkcionalne testove išli smo mnogo daleko pa smo, na primer, umesto da proveravamo funkcionalnost rada fakture kao jedne celine poslovnog programa proveravali funkcionalnosti korisničkog interfejsa, lakoće pristupa nekim funkcijama kao i sam izgled i popunjenost štampanog obrasca.

Kasnije se ispostavljalo da smo tu mnogo vremena trošili na te detalje, a oko 80% stvari se menjalo u kasnijim fazama testiranja kod korisnika.

Poučeni iskustvom, namera nam je da funkcionalno testiranje svedemo na samu proveru rada opcije za fakturisanje na način koji ću opisati u sledećem delu, a da se ne zadržavamo na testiranju nečega što po pravilima ne pripada ovoj fazi.

Ušteda u troškovima razvoja je velika, a rezultat za korisnike je bolji.

Funkcionalno testiranje, kako bi bilo idealno (ah, idealno)

Ako se razumete u obradu porudžbina u preduzeću, znate da nam za potrebe fakturisanja bilo čega trebaju šifarnici kupaca, robe i usluga. Magacina takođe, kada je roba u pitanju. Ako sve ovo podelim na delove, tu se izdvajaju tri glavne celine: rad sa šifarnicima, rad sa magacinskim poslovanjem i porudžbine kupaca.

Ako se sada nalazimo u fazi funkcionalnog testiranja to znači da su ova tri modula već testirani pojedinačno, svaki za sebe. Došli smo u fazu kada zajedno treba da stavimo u funkciju šifarnike roba i usluga i kupaca kao i porudžbine kupaca, u svrhu fakturisanja.

Treba da utvrdimo da li se prilikom izrade fakture pravilno evidentira magacin iz koga se roba izdaje, da li se cenovnik roba i usluga pravilno prikazuje za zadatog kupca, da li je na osnovu porudžbine moguće izdati sve količine, da li se na pravi način prikazuje i obračunava cena, popust, porez i vrednost koju kupac treba da plati, kao da li na pravilan način se generiše izveštaj za štampu.

Ukoliko sve ovo funkcioniše prilikom normalnog testa, možemo da probamo i nekoliko varijanti sa pogrešnim parametrima, na primer prodata količina 0, popust 150%, ili da pokušamo da izdamo veću količinu od poručene. Ukoliko sve ovo prođe kako treba smatramo da je celina koju smo obradili prošla funkcionalno testiranje.

Nećemo se zadržavati na tome kako izgleda korisnički interfejs, kako izgleda štampa dokumenta ili slično.

Kako testirati performanse

U sledećem koraku testiranja, testiranju performansi, bavimo se, na primer, konkretnom brzinom kojom forma za fakturisanje može da dobije podatke iz baze podataka.

Ako uzmemo primer firme koja godišnje izdaje i do nekoliko hiljada faktura nećemo da idemo na rešenje da prilikom poziva liste faktura dobijemo sve fakture, nego ćemo da definišemo koliki vremenski period, računat od danas, uzimamo u obzir da bi dobili tražene podatke, a da se nijedan resurs ne opterećuje više nego što je to potrebno.

Korisnik će tada za jednu, dve sekunde dobiti pregled faktura. Neće morati da čeka 20 sekundi ili više, što bi bilo loše. I dosadno.

Druga stvar koja je vezana za preuzimanje podata iz baze, a gde se dosta greši u različitim softverskim rešenjima koje sam vidio je preuzimanje stavki iz fakture.

Veliki broj rešenja ovakve prirode sa zagljavljem faktura „prevlače“ i stavke, i time paketi informacija postaju veliki, forma se jako sporo otvara i sporo se vrše operacije nad listom faktura, pregled i pretraga.

Zato smo za te potrebe odvojili zaglavlje faktura od stavki, kako bi korisnik na zahtev mogao da dobije stavke tačno određene fakture.

Istovremeno smo time omogućili korisniku da brže vrši pretragu i pregled faktura.

Dalje, kada želimo da prikažemo sumarne podatke fakture znamo da nam relacione baze podataka omogućavaju da odvojimo podatke kao što su vrednost robe, popust i porez od pojedinačnih faktura i da ih ne čuvamo u tabelama sa fakturama, već ih možemo dobiti spajanjem sa drugim tabelama.

Kako mi ne bismo svaki put pozivali pregled koji bi na formi prikazivao te podatke posle svake ubačene stavke, mi smo kreirali klasu koja nam vrši obračun tih vrednosti prilikom unosa, ažuriranja i brisanja stavki iz fakture i lokalno ih prikazuje na formi.

Na taj način smo smanjili broj poziva prema bazi i ubrzali rad korisniku prilikom izrade fakture.

Naše iskustvo: Kako ne testirati performanse

Do sada, kao i mnogo veće softverske firme, najviše smo se saplitali oko količine prenetih podataka prilikom poziva forme za fakturisanje.

Rešavali smo to na razne načine pomoću korisničkih kontrola i gubili vreme na preširoko gledanje na ceo problem. Pitali smo se kako bi korisnicima bilo lakše da ne gledaju ono što im ne treba, ali da imaju sve što im je potrebno.

Kao i kod testa funkcionalnosti, oko 80% rešenja do kojih smo došli su kasnije menjana , da bi se došlo do rešenja koje je prihvatljivo krajnjem korisniku.

Pri tom, tu ima još jedan momenat koji se zove „sto ljudi sto ćudi“, tako da smo i zbog toga gledali mnogo široko. Neka rešenja su nam se kasnije sudarala, jer korisnici različito gledaju na temu „lakše bi mi bilo...“.

Nadalje ćemo pitanja testiranja performansi raditi samo u tehničkom smislu te reči, što bi na ovom primeru značilo da se ne bavimo time „šta bi bilo kada bi bilo“ nego da se potrudimo da postavimo sistem da sa što manje zauzimanja svih resursa računara da zahtevani rezultat, a da ostalo prepustimo onim fazama testiranja kojima i pripadaju.

„Široko zatvorenih očiju“: Testiranje prihvatanja

Ova faza je kod nas bila najbolnija faza jer smo bili ubeđeni  da na tržište izlazimo sa dovoljno prilagođenim programskim rešenjem za fakturisanje roba i usluga i da onako kako smo mi mislili da je najlakše i najfunkcionalnije da se radi da će ljudi tako prihvatiti i povinovati se tome.

Ovo i ne bi bio toliko veliki problem da jedan od glavnih postulata rada naše firme jeste da korisnik softvera mora da se izjasni da je zadovoljan sa svime što mu naš softver nudi, da mu je prilagođen i da je dobio ono što je tražio u 95% slučajeva i više.

U ovoj fazi smo mnogo puta vraćali softver na doradu.

Susretali smo se i sa problemima gde mnogi korisnici neznajući šta je to tačno što im treba pokušavaju da dobiju ono što traže, a pri tom, njihovi pogledi na problem nisu isti kao drugim korisnicima.

Na primer, dešavalo se da je nekome lakše da koristi miš da prelazi iz polja u polje, a nekome strogo tastatura. Nekome je taster „enter“ taj magični taster „dalje“, a neko je navikao na numerički „+“ taster.  

Po meni, ovde je najbolje da se pažljivo slušaju zapažanja i ideje koje daju krajnji korisnici, pošto  imamo nameru da su nam svi korisnici zadovoljni i da se u skladu sa nihovim željama rukovodimo u daljem radu.

Naravno, u ovoj fazi dolazi do razilaženja od početnog zahteva i programskog rešenja.

Kako se uglavnom nedovoljno strogo koriste prethodne dve faze testiranja i onda pokušava da se umesto krajnjih korisnika odradi faza testiranja prihvatanja, mnogo vremena i truda se kasnije troši na nova rešenja koja su i dalje više-manje nedovoljna, pa se tako lagano dolazi do kompromisnog rešenja kojima često nisu u potpunusti zadovoljni ni kreatori softvera ni korisnici.

Što se nas tiče, nadalje ćemo implementirati dovoljan broj funkcija koje je moguće podesiti prilikom implementacije sofvera kod krajnjeg korisnika kako bi se softver maksimalno prilagodio njihovim potrebama, a da ne narušimo rad u prethodne dve faze.

Odnosno, na primer, koliko god krajnji korisnik tražio da mu se do detalja prilagodi forma on neće moći da proda neki artikal ili uslugu sa cenom od 0 dinara ili da da popust veći od 100%, ali mu se zato za prilagođavanje korisničkog iterfejsa ostavlja prilično veliki „manevarski prostor“.

Zašto sam ovakvog mišljenja?

Ako želimo da postignemo da softverski proizvod bude prihvaćen i korišćen, ovu fazu treba da prođemo blizu stopostotnom uspehu jer znam da različite vrste delatnosti imaju različite navike i interne procese.

U ovoj fazi smo uglavnom dolazili do problema koji se dešavaju u „stvarnom životu“.

U našem primeru fakturisanja, na primer, problem je mogao da bude mnogo spora ili ograničena propusna moć računarske mreže ili jako slabi resursi na kojima bi softver trebao da radi.

Tu smo se opet vratili na početak.

Konkretno, mi smo u tom momentu došli do zaključka da bi trebalo da sa klijent-server arhitekture, koja je jako glomazna na klijentskoj strani i neupotrebljiva za naš primer fakturisanja, pređemo na višeslojnu arhitekturu i izmestimo poslovnu logiku iz klijentskog dela softvera.

Morali smo malo da se vratimo na prva dva koraka kako bi se uskladili sa novim sistemom rada, mada nam je razvojni alat nudio veliku mogućnost da i sa ovolikom suštinskom izmenom u radu softvera nemamo velikih problema u test fazi.

Sa druge strane, zadržali smo korisnički interfejs kako njegovom izmenom  ne bi pravili dodatne troškove razvoja softvera.

Naravno da smo sa prelaskom na višeslojnu arhitekturu dobili i neke nove mogućnosti da poboljšamo performanse i time iskoristili priliku da ono oko čega smo se lomili u drugom koraku testiranja još više dovedemo do savršenstva. Ovom izmenom smo prevazišli problem slabih računara ili malog protoka podataka na mreži u kojoj ti računari rade.

Mnoga softverska preduzeća manjak iskustva u testiranju dovodi do toga da na ovom koraku testiranja imaju probleme i da se ponovo vraćaju u razvoj i doradu softvera koji je do ove faze razvijen.

To se opet odražava na dodatni utrošak vremena i investicije na već razvijenim modelima koji su radili u kancelarijskim uslovima i  prošli funkcionalan test kod kranjih korisnika.

A praksa je pokazala da se testovi u bilo kojoj fazi, posebno kada se koristi baza podataka, najbolje rade na „pravim podacima“. Nema ozbiljnih testova sa test podacima, sve se to na kraju završi kao na primeru koji sam obradio.

Kada se ponovo vratim i pročitam sve što sam napisao i imajući u vidu da sam sve to prošao, uvideo sam da je značaj softverskog testiranja jako bitan faktor u razvoju softvera.

Druga bitna stvar je da testiranje softvera mora da počne zajedno sa razvojem i moraju da se ispoštuju svi principi softverskog testiranja, od najmanjih modula kao što su procedura, funkcija i klasa, do gotovih modula kao što su forme, izveštaji i aplikacije.

Uvideo sam koliko je neophodan proces testiranja softvera  u vremenu kada raste potražnja za brzim i efikasnim softverskim rešenjima sa niskom cenom.

Ovaj pristup štedi i vreme i investicije u razvoj i programiranje takvog softvera. To je još jedan pokazatelj koliko dobro kreiran algoritam može da pomogne u rešavanju svakodnevnih izazova.

Smatram da ste na pravi i jednostavan način formirali ITAcademy i da kursevi sadrže suštinu a da su oslobođeni suvišnog teoretisanja i suvoparnih detalja.

Mislim da ovakav način radova na teme prikazuje koliko su polaznici naučili i koliko vladaju materijom, naročito u oblasti kao što je ova i to u vreme kada su svi kursevi završeni i kada bi morali da imaju kompletnu sliku o tome kako sve te tehnologije rade, kako da ih primene pravilno i da na što efikasniji način dođu do gotovog rešenja sa svim elementima o kojima smo ovde učili.

Saša Mihajlović, profesionalni programer i vođa razvojnog tima kompanije koja nudi poslovne softverske pakete manjim i srednjim preduzećima. Polaznik ITAcademy.