Koliko ti treba vremena da za svaku klasu napises testove i da pokrijes rubne slucajeve i da pokrijes sve vrste testiranja?
Sw ce nakon svih testiranja mozda opet imati bugove.
Kako god, opet se sw mora rucno testirati, ako znas sto radis i ako imas dokumentaciju kao developer onda je ovo jako brzo, a pokriju se i rubni slucajevi.
Ne znam za vrijeme, ovisi o aplikaciji s kojom radis. Ako radis s nekom legacy aplikacijom gdje produkcijski kod nije bas testabilan, onda je to tesko (ne i nemoguce) testirati i vise vremena uzima.
Ako je u pitanju dobar i testabilan kod, manje vremena odlazi i na pisanje testova.
Testovi ne bi trebali biti after-thought, nego nesto sto jednostavno imas na pameti uvijek i ukljucujes u procjenu kao i pisanje samog produkcijskog koda.
I nakon rucnih testiranja ce opet mozda imati bugove, pa ne kuzim bas poantu ovog komentara? 
Ne mozes iskljuciti mogucnost postojanja bugova, ali mozes ih s testovima eliminirati onako kako se otkriju i hvatati bugove prije nego dodju na produkciju.
Pa i ne bas, ako testovi pokrivaju sve ono sto bi kao developer morao rucno testirati, onda zasto bih rucno to testirao?
Ne bih se slozio.
U vecem sustavu (npr neki bankarski sustav) nakon svake promjene u kodu ici rucno testirati apsolutno cijeli sustav da nesto nije strgano je horor i uzima previse vremena te je podlozno ljudskoj pogresci.
Zato su tu automatizirani testovi koji ce nakon svake promjene istestirati sustav jako brzo i uhvatiti na vrijeme ako je nesto strgano prije nego zavrsi na produkciji.
Za rubne slucajeve takodjer moram priznati da nisam skuzio poantu? Napises testove i za njih i imas sve pokriveno.
Evo moj tim u firmi ima jednog Software Arhitekta i opet testiramo kod.Rade se unit testovi koje pise developer i Integration testovi, koje pise QA (u Selenium-u, koliko znam).
Na koji nacin ce to neka dokumentacija pokriti ono sto pokriju automatizirani testovi ?
Ako je aplikacija modularna i imas izmjenu u jednoj klasi u nekom modulu, znas sto je input, sto je output i to se brzo testira.
Tako da se predvide sve situacije.
I sta sad ti trebas nabubat svu tu dokumentaciju na pamet, i svaki put kada radis neko refaktoriranje, moras manuelno proci kroz sve i uvjeriti se da nista nije potrgano ?
Nisi shvatio, nema veze.
Svugdje postoje tri vrste ljudi, za, protiv i suzdrzani.
Pa sta testovi rade nego da predvidjaju neke stvari i ocekuju da predvidjeno bude zadovoljeno ?
Naravno samo mi nije jasno kako ce ovaj tvoj prijedlog sa dokumentacijom dugorocno biti brzi, precizniji i temeljitiji u odnosu na nesto sto je automatizirano.
Ajde ro majstore napisi i dokazi tu rvoju tezu firmama poput SAP, MS, Apple, Google, FB itd. Koji prilinom svakog releasa minor ili major ne bitno voze po nekoliko desetina tisuca testova, nema veze koji su, dal je unit, end to end, acceptance itd.
Na mobitelu sam pa mi se neda puno tipkati ali procitaj malo sto pisu @belmin i @tony decki su sasvim u pravu. Na temu testiranja software imas preko nekolino stotina knjiga napisanih, da je onako kako ti kazes ne bih bilo ni desetina.
Mi u firmi sad takodjer trazimo full time sw tester osobu koja nece raditi nista drugo nego pisati i automatizirati testiranje naseg SWa koje nam sad oduzima po nekoliko dana, a o bugovima koje imamo nakon tjednog releasa ne zelim niti pricati.
Cini mi se da si jos jako mlad i neiskusan pa zato to tako pises, ali doci ce vrijeme kad ces se sam sebi smijati, to govorim iz iskustva
Cijeli dan razbijam glavu kako testirati mali code (par klasa, 50-ak linija codea) i nemrem prokužit. Ako ima tko volje i vremena pomoć? Ne kužim da ga hebeš.
Ajde ti nama daj taj kod koji zelis testirati i tvoje testove do sada.
Ovaj kurs vrijedi pogledati i platiti za njega nekih 20tak Eurica
A mislim da ima nesto i na laracasts.
Ja to sve razumijem.
Koliko ono ima bugova u svakoj novoj verziji windowsima, pa čak i u zakrpama i koliko su velike zakrpe?
Hvala
Ajmo ovako.
Koliko bi tek bilo da nema testova i da se vodi sve po nekoj dokumentaciji ?
My two cents
Kad sam se sreo prvi puta sa pojmom testiranja, svidila mi se ideja i odlučio se poigrati sa time.
Napravio sam vlastiti engine za testiranje (ne vjerujem da baš po pravilima struke) …ali ono, radilo je.
Onda sam jedno mjesec dana pisao testove da istestiram čitavu funkcionalnost tadašnjeg servisa kojeg sam razvijao i bilo je poprilično cool kliknuti button i gledati pred očima kako se testovi vrte. Testiranje je trajalo čak jedno 15-ak sekudni i nakon toga bi dobio čitavu analizu kako su koji prošli, ako je negdje nešto puklo…itd.
Tih 15 sekundi računala je bilo zamjena za minimalno sat vremena posla ručnog testiranja.
Ono, sve…od kreiranja novog usera, verifikacije registracije…do akcija sa tim userom …pa do u konačnici brisanja tog usera iz baze …bez da se išta sprčka.
Testove sam vrtio na frontend strani i oni su doslovno šaltali podstranice projekta i prolazili kroz sve funkcionalnosti. Na taj način i backend funkckionalnost je morala odrađivati svoj dio posla da bi neki kompletni zadatak bio uspješno izvršen…tako da je u suštini sve bilo testirano.
Nakon toga sam postao ovisan o testiranju. Ako sam razvio i najmanju novu funkcionalnost imao sam potrebu pokrenuti testove da vidim jel što potrgano. I bilo je baš pozitivno oduševljenje na taj način otkriti kada se neka sitničica potrga skroz neočekivano.
S druge strane, ja sam postao ovisan pisati testove i za neke glupe detalje i bilo je upitno ono što @jorgovan kaže. Koliko je to sve bilo isplativno.
Slažem se i sa @belmin ovom opaskom
Mislim da je dobro pokriti s testovima barem neke veće cjeline i onda ako baš nešto kritično pukne unutar te veće cjeline, lako će se otkriti da je u sustav upao neki kardinalni bug koji sve stopira.
A testirati baš svaki detalj koji se razvija, to je onda duplo teži razvoj i veliko pitanje isplativosti.
Da bi se išta testiralo, unaprijed se treba znati da će aplikacija preći određenu kompleksnost…i onda su testovi isplativiji što se ranije s njima krenulo. Jer se time štedi svo ono vrijeme koje će biti izgubljeno nedostatkom testova, a prije ili kasnije će ionako postati potrebni.
S druge strane, ako sustav neće biti prekompleksan, onda su testovi u startu samo teret što se tiče efektivnosti posla. Ali procjena ovoga može biti varljiva i to je onda opet veliki plus za testove.
Sve zajedno da bi se postigla efektivnost sa testovima, treba dobro istražiti i koje su sve opcije i načini testiranja. Kako neki standardi pomažu testiranju.
…načuo sam čak nešto kada se drži nekih standarada, da se testovi mogu automatski kreirati i dodavati na projekt. To mi je za sada recimo ne zamislivo kako se izvodi…
Kako god, nebi bilo efikasno niti pročitati 100 knjiga o testiranju, ali ako ih već ima stotinjak, sigurno da bi bilo korisno ući dublje u tematiku prije osmišljavanja vlastitih rješenja. (Kao što sam ja, kada sam bio nadobudan xd)
Suma sumaru:
Ozbiljan sustav bi definitivno pokrivao testovima, ali površnim testovima.
Također bi testirao kritične točke.
Za sve ostalo su testeri korisnici koji će se žaliti ako nešto ne radi.
Za neko generalno pravilo struke kako se to radi, nemam pojma. (Ali planiram baš i ja detaljnije istraživati ovu tematiku)
Ja sam krenuo od toga da ako logički znam kakav output trebam dobiti za nekakav input, onda bi nekom procesu zadao poznat input i provjerio bi output. Ako output zadovoljava, test je prošao.
Recimo, testiraš registraciju korisnika.
Test 1:
Test 2:
Ponavljaš test 1, ali u ovom slučaju ideš sa istom email adresom kao gore, stoga očekuje drugačiji output. Ovog puta očekuješ da se korisnik neće upisati, jer nije moguće imati dva korisnika sa istim emailom.
Stoga, drugačiji output se postavlja koji zadovoljava prolazak testa 2.
itd…itd. svaki test se osmišlja i time provjerava neka logika za koju se očekuje da je ugrađena u sustav.
Sada primjeti da je svaki test mali programčić koji nešto također radi…zato je pisanje testova “pain in the ass”.
Ali meni se brzo iskristaliziralo da su svi testovi se pisali na sličan način, pa ako se prilagodi engine da ti još to malo olakša…išlo je pisanje testova i dosta brzo.
Ali ono, bilo je i tu mudrolije. Pak za test očekuješ da može proći captchu i tako, 
Tjera te da se nadmudruješ sam sa sobom i u konačnici dobiješ još kompleksniji sustav…potencijalno više bugovit, ali zato imaš testove koji će ti reći ako si nešto skršio, hehe.
(A i ja sam moguće zakomplicirao jer sam radio sve na svoju ruku…igrao se.)
Definitivno nakon što se projekt pokrije testovima, dobije se jedno veliko olakšanje na duši da se “bezobrazno i brzopleto” programira. A i to je onda jedan veliki plus za efikasnost, kada si slobodan raditi brzopoleto, a imaš “anđela čuvara” koji kaže ako je nastala greška.
P.S. Jedina stvar koju nisam testirao, je provjera vizualnih elemenata da se ne raspadaju. Tu je oko ipak Bog, ali moguće bi bilo napraviti alate i za to…da odrade barem neku grubu provjeru. A software bi mogao i bacati screenove pred osobu koja je pokrenula test i pitati ga pitanja tipa:
“Da li je pred tvojim očima ispravna forma za to i to?”
Pa tester lako da feedback računalu da potvrdi sve vizuale na brzaka…
PS.2
Fora je i da testovi testiraju sami sebe
Npr. ako krivo napišeš neki test…onda će taj test puknuti i ukazati na grešku programa.
Ako analizom onoga što se desilo ustvrdiš da program nema grešku, onda je test zapravo ukazao na grešku unutar sebe.
Jedino što se može desiti da se greška i greška ponište. Jel, minus + minus = plus.
Ali to mi se pokazalo prespecifičnim slučajem koji se ne pojavljuje, pa je ta problematika zanemariva.
Morala bi se na specifičan način desiti greška unutar programa i na specifičan način postaviti kriva pretpostavka unutar testa…da bi sve u konačnici izgledlo kao uspješan test.
Da li imate kakve preporuke za knjige?
Uglavnom me zanima testiranje za php i go lang.