Teste Windows-applikasjoner: en praktisk plan

En Windows-applikasjon kan se ren ut i demomodus og likevel bremse driften mandag morgen. En ulagret følgeseddel, en bruker som blokkeres etter tre mislykkede forsøk, eller en utskriftsdialog som reagerer annerledes etter en oppdatering, er ikke kosmetiske feil. Den som vil vite hvordan man tester Windows-applikasjoner, bør derfor ikke begynne med enkeltstående knapper, men med prosessene som koster arbeid, penger, eller sporbarhet.

Nettopp i lager, verksted, utsendelse, og administrasjon går mange kritiske prosesser gjennom skrivebordsprogramvare som har vokst fram over årene. Der teller det ikke om et testtilfelle er imponerende formulert. Avgjørende er om medarbeidere pålitelig kan utføre sine oppgaver under realistiske forhold - også med ufullstendige data, skiftende rettigheter, trege nettverk, og uplanlagte avbrudd.

Å teste Windows-applikasjoner begynner med de kritiske prosessene

Ikke alle funksjoner fortjener samme testinnsats. En sjelden brukt eksport med manuelt etterarbeid bør vurderes annerledes enn bokføring av en varemottak, etikettoppretting, eller den daglige ordreavstemmingen. Start derfor med et enkelt spørsmål: hva skjer konkret hvis denne prosessen mislykkes?

Høy prioritet har prosesser med direkte innvirkning på lager, levering, fakturering, sikkerhet, eller kundekommunikasjon. Dit hører for eksempel innlogging og rettighetskontroll, opprettelse og endring av stamdata, transaksjonsbokføringer, dokumentutskrift, grensesnitt mot ERP- eller forsendelsestjenester, samt gjenoppretting etter en feil. Selv funksjoner som bare en liten gruppe bruker, kan være kritiske hvis de blokkerer en månedsavslutning eller frigivelse av varer.

Fra disse prosessene oppstår ikke abstrakte testlister, men sporbare arbeidstrinn. En varemottakstest kunne for eksempel begynne med en eksisterende ordre, registrere en dellevering, rapportere en avvikende mengde, tildele en lagerplass, og deretter kontrollere om lagerbeholdning, bokføringslogg, og utskrevet dokument stemmer overens. Slik tester du programvarens faktiske effekt, ikke bare enkeltstående innmatingsfelt.

Bygg et testgrunnlag som gjenspeiler driften

Mange feil blir først synlige når testmiljøet nærmer seg virkeligheten. En applikasjon oppfører seg ofte annerledes med en tom testleietaker enn med flere års bevegelsesdata, sperrede artikler, manglende obligatorisk informasjon, eller allerede åpnede transaksjoner.

Sett derfor opp testdata bevisst. Du trenger ikke nødvendigvis en fullstendig kopi av produksjonen. Mer fornuftig er en kontrollert datamengde med typiske, grense-, og bevisst feilaktige tilfeller: artikler med ulike måleenheter, kunder med spesialvilkår, ordrer med delleveranser, brukere med ulike roller, og transaksjoner som allerede er under behandling. Personopplysninger bør anonymiseres eller erstattes med realistiske eksempeldata.

Til testgrunnlaget hører også det tekniske miljøet. Dokumenter Windows-versjon, oppløsning, skalering, installerte skrivere, nettverksstasjoner, databaseversjon, tilkoblede tjenester, og rettigheter. Det høres nøkternt ut, men sparer tid senere. Hvis en feil bare oppstår på arbeidsstasjoner med 125 prosent skalering eller med en bestemt skriverdriver, må det være reproduserbart.

Ikke bare kontroller idealtilfellet

Idealtilfellet beviser først og fremst at applikasjonen er bygget for den forventede veien. I driften oppstår de vanskelige situasjonene ved siden av. Hva skjer hvis en bruker lar et obligatorisk felt stå tomt, utløser samme bokføring to ganger, eller mister forbindelsen under lagring? Forblir transaksjonen konsistent? Får personen en forståelig melding? Kan hen fortsette å arbeide trygt?

Ved Windows-applikasjoner er dessuten betjening og tilstand spesielt relevant. Dialogvinduer kan dukke opp i bakgrunnen, hurtigtaster kan overlappe, filvalgsdialoger kan blokkere forløpet. Kontroller om fokus, feilmeldinger, og sperrer er entydige. Et teknisk unntak uten handlingsanvisning hjelper ikke skiftlederen videre.

Bruk manuelle tester der det kreves skjønn

Manuelle tester er ikke et tegn på manglende modenhet. De er uunnværlige når en ny prosess oppstår, et grensesnitt bygges om, eller fagkunnskap avgjør kvaliteten. En erfaren lagersjef oppdager raskere enn et skript om en skjerm er forståelig under høyt tidspress, eller om en advarsel kommer for sent.

Manuell testing blir imidlertid dyr og upålitelig når de samme stabile prosessene gjentas før hver versjon. Da avhenger utgivelsen av tilgjengelige personer, hukommelse, og spredte notater. Det riktige overgangspunktet til automatisering ligger som regel der en prosess kjøres ofte, kan forårsake stor skade, og har klare forventede resultater.

Et godt manuelt testtilfelle beskriver utgangssituasjon, trinn, forventet resultat, og nødvendige data. Ved en feil, legg til et skjermbilde, tidsstempel, applikasjons- og byggversjon, samt den nøyaktige handlingen. «Utskrift virker ikke» er ikke en brukbar feilbeskrivelse. «Etter endring av leveringsadressen forblir utskriftsdialogen åpen, ordre 4711 får ingen PDF, og det vises ingen melding» er det.

Automatiserte regresjonstester for tilbakevendende risikoer

Automatisering kontrollerer ikke om programvare grunnleggende sett er god. Den kontrollerer om tidligere fungerende, definerte prosesser fortsatt fungerer etter en endring. Det er spesielt verdifullt for Windows-programvare hvis grensesnitt, databaselogikk, og eksterne grensesnitt videreutvikles over årene.

Start smått. Velg først fem til ti forretningskritiske prosesser som bør kontrolleres ved hver utgivelse. Dit kan innlogging med en account-lockout-flyt, ordreregistrering, lagerbokføring, PDF- eller etikettutskrift, rollebytte, og en sentral import høre. Først når disse testene kjører pålitelig, lønner det seg å utvide til spesialtilfeller.

Ved skrivebordsapplikasjoner styrer automatiserte tester ofte synlige grensesnittelementer: vinduer, innmatingsfelt, tabeller, knapper, og dialoger. Det fungerer, men er mer sårbart enn en ren grensesnittstest. Små layoutendringer, tregere maskiner, eller tvetydig navngitte elementer kan bryte tester. Derfor bør utviklere, fagavdeling, og testansvarlige i fellesskap fastsette hvilke elementer som er stabilt adresserbare, og hvilke kontrolltrinn som bedre sikres via database, logg, eller grensesnitt.

En fornuftig test kontrollerer dessuten ikke bare at en knapp kunne klikkes. Den kontrollerer den forretningsmessige konsekvensen: ble bokføringen lagret? Er lagerbeholdningen korrekt? Ble et dokument generert? Ble ingen duplikat opprettet? Synlig interaksjon og verifiserbart resultat hører sammen.

Bevis er en del av testresultatet

En grønn status alene er sjelden nok for kritiske applikasjoner. Når en test mislykkes, trenger team raskt svar på tre spørsmål: hva var utgangssituasjonen? Ved hvilket trinn mislyktes prosessen? Hva viste applikasjonen på det tidspunktet?

Skjermbilder, kjøringslogger, og eventuelt skjermopptak gjør feil diskuterbare. De forkorter overleveringen mellom drift, QA, og utvikling betydelig. For regulerte eller sikkerhetsbevisste selskaper er de dessuten et solid grunnlag for å spore godkjenninger og avvik.

Lagringsstedet er ikke en bisak her. Testkjøringer kan inneholde interne kundedata, prislister, ordreinformasjon, eller skjermvisninger. Den som automatisert tester sensitive Windows-applikasjoner, bør avklare om disse dataene får forlate egen infrastruktur. Et selvhostet miljø som COCO kan være fornuftig her, fordi testkjøring, bevis, og evaluering forblir under egen kontroll. Om det er nødvendig, avhenger av personvernkrav, avtalesituasjon, og beskyttelsesbehov - ikke alle team trenger samme arkitektur for det.

Bygg testing inn i utgivelsesprosessen

Den beste testkatalogen mister verdi hvis den først brukes etter en hektisk produksjonssetting. Definer et fast tidspunkt: automatiserte kjerneregresjoner kjøres før hver utgivelse, manuell akseptanse kontrollerer nye eller endrede prosesser, og kjente begrensninger dokumenteres åpent.

Ikke hver mislykkede test trenger å stoppe en utgivelse. En feil i en sjelden brukt administrasjonsvisning kan være akseptabel hvis en trygg omvei finnes og det berørte området er tydelig informert. En feil som bokfører lagerbeholdning feil eller ubemerket blokkerer brukere, må behandles annerledes. Denne beslutningen bør tas basert på forretningspåvirkning, ikke bare antallet røde tester.

Vedlikehold testene sammen med applikasjonen. Når en prosess bevisst endres, oppdater testtilfelle, testdata, og forventet resultat sammen med kravet. Utdaterte tester skaper støy og blir til slutt ignorert. Noen få pålitelige kontroller er mer verdifulle enn hundrevis av automatiserte prosesser hvis resultater ingen lenger tar på alvor.

Til syvende og sist handler det ikke om å simulere hver tenkelige inndata. Det handler om å beskytte arbeidet som må fungere igjen neste morgen. Start med én eneste kritisk prosess, gjør resultatet dens bevisbart, og bygg videre derfra.