Testiranje Windows aplikacija: praktičan plan

Windows aplikacija može izgledati uredno u demo režimu, a ipak usporiti poslovanje u ponedeljak ujutro. Nesačuvan otpremni list, korisnik blokiran nakon tri neuspela pokušaja, ili dijalog za štampu koji se drugačije ponaša nakon ažuriranja, nisu kozmetičke greške. Ko želi da zna kako da testira Windows aplikacije, stoga ne bi trebalo da počne od pojedinačnih dugmadi, već od procesa koji koštaju rada, novca, ili sledljivosti.

Upravo u skladištu, radionici, otpremi, i administraciji, mnogi kritični procesi odvijaju se kroz desktop softver razvijan tokom godina. Tamo nije važno da li je testni slučaj upečatljivo formulisan. Odlučujuće je da li zaposleni mogu pouzdano da obavljaju svoje zadatke u realističnim uslovima - uključujući nepotpune podatke, promenljiva ovlašćenja, spore mreže, i neplanirane prekide.

Testiranje Windows aplikacija počinje kritičnim procesima

Ne zaslužuje svaka funkcija isti obim testiranja. Retko korišćen izvoz sa ručnom doradom treba proceniti drugačije nego knjiženje ulaza robe, izradu nalepnice, ili dnevno usklađivanje narudžbina. Stoga počnite jednostavnim pitanjem: šta se konkretno dešava ako taj proces ne uspe?

Visok prioritet imaju procesi sa direktnim uticajem na zalihe, isporuku, fakturisanje, bezbednost, ili komunikaciju sa kupcima. Tu spadaju na primer prijava i provera prava, izrada i izmena matičnih podataka, knjiženja transakcija, štampa dokumenata, interfejsi prema ERP ili uslugama isporuke, kao i oporavak nakon greške. Čak i funkcije koje koristi samo mala grupa ljudi mogu biti kritične ako blokiraju mesečno zaključivanje ili oslobađanje robe.

Iz tih procesa ne nastaju apstraktne liste testova, već sledljivi radni koraci. Test ulaza robe mogao bi, na primer, da počne sa postojećom narudžbinom, evidentira delimičnu isporuku, prijavi odstupajuću količinu, dodeli lokaciju skladišta, i potom proveri da li se zalihe, dnevnik knjiženja, i odštampan dokument poklapaju. Time testirate stvaran učinak softvera, ne samo pojedinačna polja unosa.

Izraditi testnu osnovu koja odražava poslovanje

Mnoge greške postaju vidljive tek kada se testno okruženje približi stvarnosti. Aplikacija se sa praznim testnim zakupcem često ponaša drugačije nego sa nekoliko godina podataka o kretanjima, blokiranim artiklima, nedostajućim obaveznim informacijama, ili već otvorenim transakcijama.

Stoga svesno izradite testne podatke. Ne morate nužno da imate potpunu kopiju produkcije. Smislenije je kontrolisan skup podataka sa tipičnim, graničnim, i namerno pogrešnim slučajevima: artikli sa različitim jedinicama mere, kupci sa posebnim uslovima, narudžbine sa delimičnim isporukama, korisnici sa različitim ulogama, i transakcije koje su već u obradi. Lične podatke pritom treba anonimizovati ili zameniti realističnim primerima podataka.

Testnoj osnovi pripada i tehničko okruženje. Dokumentujte verziju Windowsa, rezoluciju, skaliranje, instalirane štampače, mrežne diskove, verziju baze podataka, povezane usluge, i ovlašćenja. To zvuči suvoparno, ali kasnije štedi vreme. Ako se greška pojavljuje samo na radnim mestima sa skaliranjem od 125% ili sa određenim upravljačkim programom štampača, to mora biti reproducibilno.

Ne proveravati samo idealan slučaj

Idealan slučaj pre svega dokazuje da je aplikacija izrađena za očekivani put. U poslovanju pored njega nastaju teške situacije. Šta se dešava ako korisnik ostavi obavezno polje prazno, pokrene isto knjiženje dvaput, ili izgubi vezu tokom čuvanja? Da li transakcija ostaje dosledna? Da li osoba dobija razumljivu poruku? Može li bezbedno da nastavi da radi?

Kod Windows aplikacija posebno su relevantni rukovanje i stanje. Dijaloški prozori mogu se pojaviti u pozadini, prečice na tastaturi mogu se preklapati, dijalozi za izbor datoteka mogu blokirati tok. Proverite da li su fokus, poruke o greškama, i blokade jednoznačni. Tehnički izuzetak bez uputstva za postupanje ne pomaže vođi smene.

Ručne testove primeniti tamo gde je potrebna procena

Ručni testovi nisu znak nedovoljne zrelosti. Neizostavni su kada nastaje novi proces, interfejs se prepravlja, ili stručno znanje odlučuje o kvalitetu. Iskusan upravnik skladišta prepoznaje brže od skripte da li je maska razumljiva pod velikim vremenskim pritiskom, ili se upozorenje pojavljuje prekasno.

Ručno testiranje ipak postaje skupo i nepouzdano kada se isti stabilni procesi ponavljaju pre svake verzije. Tada izdanje zavisi od dostupnih osoba, pamćenja, i raspršenih beleški. Pravi trenutak za prelazak na automatizaciju obično se nalazi tamo gde se proces često izvršava, može prouzrokovati veliku štetu, i ima jasne očekivane rezultate.

Dobar ručni test slučaj opisuje početnu situaciju, korake, očekivan rezultat, i potrebne podatke. Kod greške dodajte snimak ekrana, vremensku oznaku, verziju aplikacije i build-a, kao i tačnu radnju. "Štampanje ne radi" nije upotrebljiv opis greške. "Nakon promene adrese isporuke dijalog štampe ostaje otvoren, narudžbina 4711 ne dobija PDF, i ne pojavljuje se nikakva poruka" jeste.

Automatizovani regresioni testovi za ponavljajuće rizike

Automatizacija ne proverava da li je softver u osnovi dobar. Proverava da li prethodno funkcionalni, definisani procesi i dalje rade nakon promene. To je posebno vredno kod Windows softvera čiji se interfejsi, logika baze podataka, i spoljni interfejsi razvijaju godinama.

Počnite malo. Odaberite najpre pet do deset poslovno kritičnih procesa koji bi trebalo da se proveravaju pri svakom izdanju. Tu mogu spadati prijava sa account-lockout tokom, unos narudžbina, skladišno knjiženje, štampa PDF-a ili nalepnica, promena uloge, i centralni uvoz. Tek kada ti testovi pouzdano rade, isplati se proširenje na posebne slučajeve.

Kod desktop aplikacija, automatizovani testovi često upravljaju vidljivim elementima interfejsa: prozorima, poljima unosa, tabelama, dugmadima, i dijalozima. To funkcioniše, ali je osetljivije od čistog testa interfejsa. Male promene rasporeda, sporiji računari, ili neujednačeno nazvani elementi mogu da prekinu testove. Zato bi programeri, stručni odsek, i odgovorni za testiranje trebalo zajednički da odrede koji su elementi stabilno adresibilni, a koje korake provere je bolje osigurati putem baze podataka, zapisnika, ili interfejsa.

Smislen test uz to ne proverava samo da li je dugme moglo da se klikne. Kontroliše stručnu posledicu: da li je knjiženje sačuvano? Da li je zaliha ispravna? Da li je stvoren dokument? Nije li stvoren duplirani zapis? Vidljiva interakcija i proverljiv rezultat idu zajedno.

Dokazi su deo rezultata testa

Zeleni status sam po sebi retko je dovoljan kod kritičnih aplikacija. Kada test ne uspe, timovima brzo treba odgovor na tri pitanja: kakva je bila početna situacija? Na kom je koraku proces zakazao? Šta je aplikacija prikazivala u tom trenutku?

Snimci ekrana, zapisnici izvršavanja, i po potrebi snimanja ekrana čine greške predmetom razgovora. Znatno skraćuju predaju između poslovanja, QA, i razvoja. Za regulisane ili bezbednosno osvešćene kompanije, oni su i čvrsta osnova za praćenje odobrenja i odstupanja.

Pritom lokacija čuvanja nije sporedno pitanje. Testna izvršavanja mogu sadržati interne podatke kupaca, cenovnike, informacije o narudžbinama, ili prikaze ekrana. Ko automatizovano testira osetljive Windows aplikacije, trebalo bi da razjasni da li ti podaci smeju da napuste sopstvenu infrastrukturu. Samostalno hostovano okruženje poput COCO ovde može biti smisleno, jer izvršavanje testova, dokazi, i procena ostaju pod sopstvenom kontrolom. Da li je to potrebno zavisi od zahteva zaštite podataka, ugovorne situacije, i potrebe za zaštitom - ne treba svaki tim istu arhitekturu za to.

Ugraditi testiranje u proces izdavanja

Najbolji katalog testova gubi vrednost ako se koristi tek nakon haotičnog uvođenja u produkciju. Odredite fiksni trenutak: automatizovane osnovne regresije izvršavaju se pre svakog izdanja, ručno preuzimanje proverava nove ili izmenjene procese, a poznata ograničenja se otvoreno dokumentuju.

Ne mora svaki neuspeo test da zaustavi izdanje. Greška u retko korišćenom administrativnom prikazu može biti prihvatljiva ako postoji siguran zaobilazni put i pogođeno je područje jasno informisano. Greška koja pogrešno knjiži zalihe ili neprimetno blokira korisnike treba se tretirati drugačije. Ta bi odluka trebalo da se donese prema poslovnom uticaju, ne prema pukom broju crvenih testova.

Održavajte testove zajedno sa aplikacijom. Kada se proces namerno menja, ažurirajte test slučaj, test podatke, i očekivan rezultat zajedno sa zahtevom. Zastareli testovi stvaraju buku i sa vremenom se ignorišu. Nekoliko pouzdanih provera vrednije je od stotina automatizovanih procesa čije rezultate niko više ne shvata ozbiljno.

Na kraju se ne radi o simuliranju svakog zamislivog unosa. Radi se o zaštiti posla koji sledećeg jutra ponovo mora da funkcioniše. Počnite sa jednim jedinim kritičnim procesom, učinite njegov rezultat dokazivim, i gradite dalje odande.