Tema: Programiranje,Karijera & zarada
» Prosledite prijatelju
Kako programirati softver koji se može naplatiti: 4 koraka u procesu testiranja
Objavio: Nikola Subotić 4 Komentara
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.
Iskustvo većine kompanija
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.
Instalaciono testiranje
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.
Zaključak
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.
Zašto sam napisao ovakav rad?
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.
Objavljeno: 21. Avgust 2009. 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.
Iskustvo većine kompanija
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.
Instalaciono testiranje
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.
Zaključak
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.
Zašto sam napisao ovakav rad?
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.
» Prosledite prijatelju
Komentari za Kako programirati softver koji se može naplatiti: 4 koraka u procesu testiranja
Programiranje je dosta težak, a kvalitetan posao. Programer stvara svoj softverski paket koji će izvršavati ulogu korisnika. Ja bih programiranje podelio na 2 dela: teško i lako programiranje. Teško programiranje npr. programiranje igrice za računar, lako programiranje npr. player za muziku. U programiranje se uključuje izgled, boja, stil onoga što kreiramo odnosno pravimo.
Lepo napisano i pre svega poucno, no ...
Ja bih temu pogledao iz malo otvorenijeg ugla. Iz samog davanja saveta tj. opisa softvera kojim se bavite vidim da se radi o ERP ili nekoj vrsti ERP sistema. Ne mogu a da ne primetim da je najveci dao nasih softverskih firmi i okrenut upravo takvim resenjima.
ALI! Posotoji sasvim drugaciji nacin da se od klijenata uzme novac. ITERNET! Npr. probajte sa e-commerce sajtovima koji mogu da prodaju bilo sta. Naravno sve sto vam je potrebno je da, naostrite C da malo odlepite dok radite bazu i stored procedure i zarada je maltene zagarantovana. Ima posla, ali samo prvi put kad radite od pocetka. Posle ostaju prilagodjavanja svakom kupcu ponaosob u zavisnosti od kupcevih potreba (ako stvar uradite kako treba od pocteka onda se to odnosi samo na Master page, ispravke DIV-ova, SKINa, CSS klasa, promenu slika veznaih za bazu i ko razume shvatice ... ) Jos nesto, sajt ne prodaje samo sadrzaj nego i izgled! Svaki piksel mora da je na mestu. Ne sme da smara. Mora da bude jednostavan korisniku. MNOGO JEDNOOSTAVAN! Mora da bude MNOGO lep (lepota i jeste u jednostavnosti) , da ima sveze informacije, kontinuirano poboljsavanje i dalje prilagodjavanje kupcu, kao i citavu nauku o advertajzingu iza sebe. Logo bi trebalo da bude u gornjem levom uglu u savrsenom skladu sa okolinom web programa ali dovoljno upadljiv da bude prvi primecen. To je pecat i mora da ima snagu. Za razliku od dosadasnje prakse predlazem da se umesto monitoringa 'view product' radi monitoring 'product add to cart'. Time se postize veca efektivnost prilikom sugestije kupovine kupcu za neki drugi proizvod koji mu preporucujete a da pri tom korisnicke korpe pratite od ranije. Naime, proizvodi koji su na neki nacin vec bili u korpi kod jednog potrosaca, cesce zavrsavaju u korpama drugih ako im ih preporucite. Google analitics je must have alat.
Takva vrsta web programa zahteva konstante promocije jednog ili grupe prizvoda. Dalje razmisljajte kao da imate pravu prodavnicu koja stoji cvrsto na zemlji ali isto tako ne zaboravite da je kupac na internetu potpuno slobodan i anonimam (niko ga nije video gde i sta je kupio) i da se daleko jednostavnije odlucuje za kupovinu nego da je u masi sveta, vodjen "logikom mase".
Postoji realan problem nepoverenja u sajtove koji se bave bilo kakvom vrstom naplate zbog ugozavanja integriteta podataka, no ako na sajtu na pravi nacin zastitite potrosace, hesovanjem lozinki (sto vise to bolje bita), SSL ili TLS sigurnosnim kanalom, predvidite npr. SQL Injection, kvalitetno upravljate kukijima i sesijama i verifikujete se kod nekog od garanta sigurnosti transakcija na Internetu (VeriSign, DataCashPayment system, Paypall ... ) i sve to dobro izreklamirate i propratite originalnom elektronski potpisanom dokumentacijom koju dobijate od granata transakcija, sigurno ce se stvari odvojati daleko povoljnije po vas. Takodje, preporuka je da uradite i sopostveni sertifikat i to kod sto je moguce veceg provajdera CA (Certification Authority - AOL npr.).
Za kontinuirano privlacenje unique usera potrebno je da prezentaciona stranica prati najnove Internet trendove. Neke od pozeljnih tehnologija su AJAX, JQuery, EXTjs, JSON, ActionSript 3.0, ASP.NET, CSS, xHTML, AIR i jos ponesto). Malo inovativnosti u srpsko programerstvo apsolutno ne bi bilo na odmet (sad ce mnogi reci: "Pa mi se ovim bavimo!"). Nesto mi gr'ko u ustima od ove poslednje.
Uzgred, dobar e-comerrce site moze da kosta poprilicno; jesi lav ili nisi? Kamo gadget-i za Vistu, Windows server 2008 ili ne daj Boze Windows 7! Da su samo gadget-i pa da pevamo. Moj utisak je da MNOGO zaostajemo za svetskim IT-jem. ERP ce svim kreativnim programerima kod nas samo ubiti kreativnost.
Eh, da, olaksavajuca okolnost, kad je e-commerce u pitanju koliko mi se cini a skoro sam potpuno uveren, zakon o elektronskom poslovanju jos uvek nije donet i ceka u debelom redu u skupstinkoj proceduri. Tenutno ovakva vrsta poslovanja moze imati puno prednosti. Npr. takse koje potrosaci placaju prilikom dostave robe variraju od zemlje do zemlje. Kod nas ne postoji zakon o tome ... (Western Union, City Express, FEDEX, ...)
Za ostale koji umeju da citaju izmedju redova, Internet daje nebrojene mogucnosti.
Po mojoj proceni onih 1.500.000.000 (i slovima: milijardu ipo) korisnika Interneta predstavljaju daleko veci potencijal od ovih lepih saveta.
HVALA LEPO NA NJIMA! A sad stvarno? Gde je ta lova?
Ah da, jel se seca neko gumice?
Postovani kolega, zaista ste me zaintrigirali teksom koji ste napisali. Nadam se da nisam bio previse grub u kvalifikacijama softvera koji nase programerske firme proizvode (racunajuci tu i Vasu) ali prosto mi je neverovatno da se tema zove KAKO PROGRAMIRATI SOFTVER KOJI SE MOZE NAPLATITI a vrlo dobro znate kakva je konkurecinja u sistemima koje vi preporucujete. Manje grandiozno, vise u sustinu problema, mnogo vise analiticki i konacno pricajte realno. To Vam savetujem .... Proces proizvodnje koji Vi opisujete moguc je samo u strikno organizovanoj hijerarhiji .... Takvih hijerarhija kod nas ima samo u snovima. Ima nas koji projekte radimo sami od pocetka do kraja. Najvise nas je takvih. Govoreci u moje ime nikad necu zaglupeti u kalupima koje vi predlazete kao poslovnu politiku. Covek nije roblje. Narocito ne programer.
Negoslave, kako da vas kontaktiram?
pozdrav.
Ostavite komentar ili pitanje
Pravila za ostavljanje komentara: Želimo da razgovor bude opušten. Nemamo nameru da se mešamo u komentarisanje, ali komentari van konteksta posta, neučtivi ili napadni mogu biti obrisani. Molimo Vas da se potpisujete ličnim imenom ili inicijalima, a ne poslovnim nazivom. Uživajte i hvala Vam što doprinosite ovom razgovoru.
