Bug Online

Pred testere se danas postavlja toliko prepreka da je dobro istestirati softver često nemoguća misija. Testeri s razvojnim timom vrlo često komuniciraju samo indirektno i nisu sigurni koji su dijelovi aplikacije stabilizirani i treba ih testirati, a na kojima programeri još rade. U današnjem svijetu agilnih metodologija i emerging dizajna u kojem je "kôd najbolja dokumentacija" često su specifikacije zastarjele, pa nije jasno ni kako bi se testirana aplikacija u svakom svom dijelu trebala ponašati. Zato se događa da testeri nepotrebno testiraju pojedine dijelove aplikacije koji još nisu spremni za testiranje, da prijavljuju pogreške koje to nisu ili da jednostavno nisu u stanju napraviti svoj posao jer ne znaju gdje bi započeli. Razvoj i testiranje, nažalost, nisu razdvojeni samo na ovom procesnom nivou. Još je veća podjela u alatima - alati za testere slabo su povezani s alatima za programere. Upravo manjak integracije alata sprečava integraciju procesa razvoja i testiranja i efikasnu suradnju na nivou cjelokupnog razvojnog tima.

Nova podrška za testiranje u Microsoft Visual Studiju 2010 ima za cilj riješiti sve opisane probleme. Testiranje se usklađuje s ostalim dijelovima razvojnog procesa. Ono postaje integrirani dio cjelokupnog razvojnog procesa, jednako važan kao i programiranje. Testeri postaju ravnopravni članovi razvojnog tima utoliko što su im dostupne sve informacije s Team Foundation Servera. Na taj način dobivaju uvid u ciljeve i status rada drugih rola, odnosno članova tima, i čine svoj rad transparentnim drugima. Status testiranja zajedno s rezultatima rada ostalih rola uključen je u izvještavanje o statusu cijelog projekta.

S testiranjem treba započeti od samog početka rada na projektu, a novi alati trebaju omogućiti efikasan rad kroz usku interakciju programera i testera, tj. kvalitetnu razmjenu informacija s jedne strane o tome što je napravljeno i što treba testirati u svakoj novoj verziji (buildu), a s druge strane takvih informacija o novootkrivenim bugovima koje će programerima omogućiti njihovo brzo rješavanje. Automatiziranjem dosadnih repetitivnih zadataka za testere i fokusiranjem testiranja na najvažnije dijelove aplikacije treba maksimalno iskoristili testne resurse.

S ove pomalo apstraktne razine visokih ciljeva pređimo na konkretnu razinu i opišimo pojedine alate i metode kojima su ovi ciljevi ostvareni u Visual Studiju 2010.

Testeri opće prakse

Ovisno o fazi razvoja u kojoj se provode, razlikujemo nekoliko vrsta testova: unit testiranje, integracijsko odnosno sistemsko testiranje te acceptance testiranje. Prve su dvije vrste i dosad bile podržane u Visual Studiju.

Unit testove u pravilu pišu programeri za vrijeme razvoja kôda. Za sistemsko se testiranje rabe Load i Web testovi za koje je također potrebno određeno programersko znanje, pa ih pišu ili programeri ili specijalizirani testeri. Svi se ovi tipovi testova daju automatizirati, što je jako bitno za regresijsko testiranje i za kontinuiranu svakodnevnu provjeru ispravnosti novog kôda.

Automatizirani testovi, očekivano, nisu rješenje za sve probleme. Možda je najbolji primjer za to sâm projekt razvoja Visual Studija 2010. Zbog neugodnih iskustava s lošim performansom i regresijama tijekom rada na prethodnim verzijama, kod razvoja Visual Studija 2010, Microsoftov je tim odlučio pripremiti velik broj automatiziranih testova koji će testirati sve bitne scenarije i svojstva. Programeri su uložili veliki trud da ti scenariji budu precizno definirani i ponovljivi te da se njima može dobro mjeriti performanse. Očekivali su da će se mogući problemi s performansama odmah vidjeti na rezultatima tih testova. Tim je pun pouzdanja u taj zaštitni mehanizam u listopadu 2009. izdao verziju Beta 2. Povratna informacija od korisnika bila je jednoznačna i porazna - Beta 2 je bila neprihvatljivo spora. Kao što znate, ovi su problemi u konačnici doveli čak i do odgađanja već najavljenog datuma izlaska nove verzije Visual Studija. Analiza je pokazala da su automatizirani testovi bili previše specijalizirani i da nisu testirali aplikaciju na način rada krajnjih korisnika. Microsoft je naknadno priznao da su se previše pouzdali u automatizaciju.

Nesumnjivoj važnosti automatizacije unatoč, testeri se većinu vremena bave istraživačkim testiranjem - ručnim traženjem bugova tako da koriste testiranu aplikaciju onako kako predviđaju da će je koristiti krajnji korisnici ili, još češće, tražeći scenarije koje programeri nisu predvidjeli. Ovi testeri opće prakse trebaju alate koji će im olakšati automatizaciju repetitivnih zadataka (npr. logiranja u testiranu aplikaciju ili unosa osnovnih testnih podataka), a istovremeno dati što bolju podršku tijekom istraživačke faze testiranja. Upravo tu novi alati za testiranje posebno dolaze do izražaja!