Testiranje Windows aplikacija: praktičan plan

Windows aplikacija može izgledati uredno u demo načinu, a ipak usporiti poslovanje u ponedjeljak ujutro. Nespremljeni otpremni list, korisnik blokiran nakon tri neuspjela pokušaja, ili dijalog za ispis koji se drugačije ponaša nakon ažuriranja nisu kozmetičke greške. Tko želi znati kako testirati Windows aplikacije, stoga ne bi trebao početi od pojedinačnih gumba, već od procesa koji koštaju rada, novca, ili sljedivosti.

Upravo u skladištu, radionici, otpremi, i administraciji, mnogi kritični procesi odvijaju se kroz desktop softver razvijan tijekom godina. Ondje nije važno je li testni slučaj dojmljivo formuliran. Odlučujuće je mogu li zaposlenici pouzdano obavljati svoje zadatke u realističnim uvjetima - uključujući nepotpune podatke, promjenjiva ovlaštenja, spore mreže, i neplanirane prekide.

Testiranje Windows aplikacija počinje s kritičnim procesima

Ne zaslužuje svaka funkcija isti opseg testiranja. Rijetko korišten izvoz s ručnom doradom treba procijeniti drugačije nego knjiženje ulaza robe, izradu naljepnice, ili dnevno usklađivanje narudžbi. Stoga počnite jednostavnim pitanjem: što se konkretno događa ako taj proces ne uspije?

Visok prioritet imaju procesi s izravnim utjecajem na zalihe, dostavu, fakturiranje, sigurnost, ili komunikaciju s kupcima. Tu spadaju primjerice prijava i provjera prava, izrada i izmjena matičnih podataka, knjiženja transakcija, ispis dokumenata, sučelja prema ERP ili dostavnim uslugama, te oporavak nakon greške. Čak i funkcije koje koristi samo mala skupina ljudi mogu biti kritične ako blokiraju mjesečno zaključivanje ili oslobađanje robe.

Iz tih procesa ne nastaju apstraktne liste testova, već sljedivi radni koraci. Test ulaza robe mogao bi, primjerice, početi s postojećom narudžbom, evidentirati djelomičnu isporuku, prijaviti odstupajuću količinu, dodijeliti lokaciju skladišta, i potom provjeriti podudaraju li se zalihe, dnevnik knjiženja, i ispisani dokument. Time testirate stvarni 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 s praznim testnim najmom često ponaša drugačije nego s nekoliko godina podataka o kretanjima, blokiranim artiklima, nedostajućim obveznim informacijama, ili već otvorenim transakcijama.

Stoga svjesno izradite testne podatke. Ne trebate nužno potpunu kopiju produkcije. Smisleniji je kontrolirani skup podataka s tipičnim, graničnim, i namjerno pogrešnim slučajevima: artikli s različitim mjernim jedinicama, kupci s posebnim uvjetima, narudžbe s djelomičnim isporukama, korisnici s različitim ulogama, i transakcije koje su već u obradi. Osobne podatke pritom treba anonimizirati ili zamijeniti realističnim primjernim podacima.

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

Ne provjeravati samo idealni slučaj

Idealni slučaj prije svega dokazuje da je aplikacija izrađena za očekivani put. U poslovanju uz njega nastaju teške situacije. Što se događa ako korisnik ostavi obvezno polje praznim, pokrene istu transakciju dvaput, ili izgubi vezu tijekom spremanja? Ostaje li transakcija dosljedna? Prima li osoba razumljivu poruku? Može li sigurno nastaviti raditi?

Kod Windows aplikacija posebno su relevantni rukovanje i stanje. Dijaloški prozori mogu se pojaviti u pozadini, tipkovnički prečaci mogu se preklapati, dijalozi za odabir datoteka mogu blokirati tijek. Provjerite jesu li fokus, poruke o greškama, i blokade jednoznačni. Tehnička iznimka bez uputa o postupanju ne pomaže voditelju smjene.

Ručne testove primijeniti tamo gdje je potrebna prosudba

Ručni testovi nisu znak nedovoljne zrelosti. Neizostavni su kada nastaje novi proces, sučelje se pregrađuje, ili stručno znanje odlučuje o kvaliteti. Iskusan voditelj skladišta prepoznaje brže od skripte je li maska razumljiva pod visokim vremenskim pritiskom, ili se upozorenje pojavljuje prekasno.

Ručno testiranje ipak postaje skupo i nepouzdano kada se isti stabilni procesi ponavljaju prije svake verzije. Tada izdanje ovisi o dostupnim osobama, pamćenju, i raspršenim bilješkama. Pravi trenutak za prijelaz na automatizaciju obično se nalazi tamo gdje se proces često izvršava, može uzrokovati veliku štetu, i ima jasne očekivane rezultate.

Dobar ručni testni slučaj opisuje početnu situaciju, korake, očekivani rezultat, i potrebne podatke. Kod greške dodajte snimku zaslona, vremensku oznaku, verziju aplikacije i builda, te točnu radnju. "Ispis ne radi" nije upotrebljiv opis greške. "Nakon promjene dostavne adrese dijalog ispisa ostaje otvoren, narudžba 4711 ne dobiva PDF, i ne pojavljuje se nikakva poruka" jest.

Automatizirani regresijski testovi za ponavljajuće rizike

Automatizacija ne provjerava je li softver u osnovi dobar. Provjerava rade li prethodno funkcionalni, definirani procesi i dalje nakon promjene. To je posebno vrijedno kod Windows softvera čija se sučelja, logika baze podataka, i vanjska sučelja razvijaju godinama.

Počnite malo. Odaberite najprije pet do deset poslovno kritičnih procesa koji bi se trebali provjeravati pri svakom izdanju. Tu mogu spadati prijava s account-lockout tijekom, unos narudžbi, skladišno knjiženje, ispis PDF-a ili naljepnica, promjena uloge, i središnji uvoz. Tek kada ti testovi pouzdano rade, isplati se proširenje na posebne slučajeve.

Kod desktop aplikacija, automatizirani testovi često upravljaju vidljivim elementima sučelja: prozorima, poljima unosa, tablicama, gumbima, i dijalozima. To funkcionira, ali je osjetljivije od čistog testa sučelja. Male promjene rasporeda, sporija računala, ili neujednačeno nazvani elementi mogu prekinuti testove. Zato bi programeri, stručni odjel, i odgovorni za testiranje trebali zajednički odrediti koji su elementi stabilno adresibilni, a koje je korake provjere bolje osigurati putem baze podataka, zapisnika, ili sučelja.

Smislen test uz to ne provjerava samo je li se gumb mogao kliknuti. Kontrolira stručnu posljedicu: je li knjiženje spremljeno? Je li zaliha ispravna? Je li stvoren dokument? Nije li stvoren dvostruki zapis? Vidljiva interakcija i provjerljiv rezultat idu zajedno.

Dokazi su dio rezultata testa

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

Snimke zaslona, zapisnici izvođenja, i po potrebi snimanja zaslona čine greške razgovorljivima. Znatno skraćuju predaju između poslovanja, QA, i razvoja. Za regulirane ili sigurnosno osviještene tvrtke, oni su i čvrsta osnova za praćenje odobrenja i odstupanja.

Pritom lokacija pohrane nije sporedno pitanje. Testna izvođenja mogu sadržavati interne podatke kupaca, cjenike, informacije o narudžbama, ili prikaze zaslona. Tko automatizirano testira osjetljive Windows aplikacije, trebao bi razjasniti smiju li ti podaci napustiti vlastitu infrastrukturu. Samostalno hostirano okruženje poput COCOa ovdje može biti smisleno, jer izvođenje testova, dokazi, i procjena ostaju pod vlastitom kontrolom. Je li to potrebno ovisi o zahtjevima zaštite podataka, ugovornoj situaciji, i potrebi za zaštitom - ne treba svaki tim istu arhitekturu za to.

Ugraditi testiranje u proces izdavanja

Najbolji katalog testova gubi vrijednost ako se koristi tek nakon kaotičnog uvođenja u produkciju. Odredite fiksni trenutak: automatizirane osnovne regresije izvode se prije svakog izdanja, ručno preuzimanje provjerava nove ili izmijenjene procese, a poznata ograničenja se otvoreno dokumentiraju.

Ne mora svaki neuspjeli test zaustaviti izdanje. Greška u rijetko korištenom administrativnom prikazu može biti prihvatljiva ako postoji siguran zaobilazni put i pogođeno je područje jasno informirano. Greška koja pogrešno knjiži zalihe ili neprimjetno blokira korisnike treba se tretirati drugačije. Ta bi se odluka trebala donijeti prema poslovnom utjecaju, ne prema pukom broju crvenih testova.

Održavajte testove zajedno s aplikacijom. Kada se proces namjerno mijenja, ažurirajte testni slučaj, testne podatke, i očekivani rezultat zajedno sa zahtjevom. Zastarjeli testovi stvaraju buku i s vremenom ih se ignorira. Nekoliko pouzdanih provjera vrijednije je od stotina automatiziranih procesa čije rezultate nitko više ne shvaća ozbiljno.

Na kraju se ne radi o simuliranju svakog zamislivog unosa. Radi se o zaštiti posla koji sljedećeg jutra opet mora funkcionirati. Počnite s jednim jedinim kritičnim procesom, učinite njegov rezultat dokazivim, i gradite dalje odande.