Tokom višedecenijskog postojanja softvera razvili su se dobri i loši obrasci njegovog testiranja. Današnji članak posvećujemo ovim drugim.
Koji su najučestaliji loši obrasci testiranja softvera?
1. Testiranje posle razvoja
Ovakav pristup je čest, ali pogrešan. Rizikujemo dosta toga. Pre svega, nećemo imati vremena da ispravimo sve greške. Nije nemoguće i da shvatimo da nešto mora da se piše ispočetka. Testeri i programeri treba da rade zajedno tokom celog životnog ciklusa proizvoda. Neophodni su stalna diskusija i rane povratne informacije, a ne da se tek na kraju shvati da se sve vreme imao pogrešan pristup. Greške treba da se uhvate što je pre moguće.
2. Ručno regresiono testiranje
Kod kompleksnih aplikacija ručno testiranje svih funkcionalnosti može da potraje nedeljama, i onda se postavlja pitanje koja je uopšte svrha takvog testiranja. Ono je dugoročno neodrživo, jer niti imatmo vremena da sve istestiramo, niti da popravimo bagove. Bolje je zameniti ga brzinskim zdravorazumskim testiranjem glavnih funkcionalnosti i usredsrediti se na automatizaciju. Regresiono testiranje ima svrhu samo ako je automatizovano i izvršava se redovno.
3. Nestabilni testovi i okruženje
Nestabilni testovi su oni koji čas padaju čas prolaze, na istoj verziji koda. Kada prođu znamo da je sve u redu, ali kada padnu nikad nismo sigurni da li je to zbog baga u sistemu ili su prosto nestabilni. Dodatno istraživanje zahteva vreme i resurse, i zato ti testovi donose više štete nego koristi. Isto važi i za okruženje na kome se testovi izvršavaju. Ako i ono zakuca s vremena na vreme, tada svako testiranje gubi svrhu.
4. Bagovi nisu pokriveni testovima
Nakon popravke baga moramo da se osiguramo da se on neće ponoviti, što činimo pisanjem testa koji će pasti kada se to desi. Nekad moramo da učinimo i više od toga, da proverimo koliko je cela funkcionalnost pokrivena testovima, jer po svoj prilici, u tom delu koda postoji još problema. Ukoliko samo ispravimo bag ne napisavši test, nemamo garanciju da se ista stvar neće ponoviti u budućim izdanjima softvera.
5. Testovi utiču jedni na druge
Testovi treba da budu samodovoljni, to jest da mogu da se izvršavaju sami za sebe, ne treba da očekuju da drugi test nešto uradi pre njih. Kada god postoji međuzavisnost, stvari se komplikuju i svako ispitivanje pada tih testove može da potraje. Isto tako, ne smemo da dozvolimo da test promeni podatke ili bazu, tako da utiče na test koji se izvršava posle njega. Tako samo gubimo vreme na analizu lažnih bagova.