En softwaretester undersøger, om et program fungerer som forventet, og hvor det kan gå galt. Det kan være en app til tidsbestilling, et lønsystem eller en netbutik. Arbejdet handler om mere end at klikke på knapper, indtil noget går i stykker. Du sammenholder det, programmet skal kunne, med det, der faktisk sker, og beskriver forskellene, så andre kan handle på dem. Som nybegynder skal du først og fremmest lære at undersøge systematisk. De tekniske udtryk kan du lære undervejs.

Hvad undersøger en softwaretester egentlig

Forestil dig en digital kalender, hvor kunder kan bestille tid hos en frisør. Den oplagte test er at vælge en ledig tid, skrive et navn og gennemføre bestillingen. Men det er kun ét forløb. Hvad sker der, hvis kunden ikke skriver sit navn? Kan to kunder bestille den samme tid? Og bliver aftalen gemt to gange, hvis kunden trykker to gange på knappen?

Testeren tager udgangspunkt i kravene til løsningen. Et krav kan være, at en bestilling skal udløse en bekræftelse på skærmen. Et andet kan være, at optagede tider ikke må kunne vælges. Er kravene uklare, stiller testeren spørgsmål til dem, der har besluttet, hvordan systemet skal fungere. Problemer skyldes ikke altid en fejl i programmet. Nogle gange mangler der en fælles forståelse af, hvad løsningen skal gøre. Med en softwaretester til hånden får teamet hjælp til at afklare kravene.

Der er også forskel på at kontrollere en funktion og at undersøge, om den giver mening for brugeren. En formular kan godt gemme oplysninger korrekt, selv om fejlbeskederne er svære at forstå. Hvis beskeden blot siger, at noget er galt, ved kunden måske ikke, hvilket felt der skal rettes.

Softwaretest kan derfor omfatte både funktioner, brugervenlighed og samspillet mellem forskellige dele af et system. Testeren kan eksempelvis undersøge, om en adresse bliver overført korrekt fra en bestilling til en faktura. Andre opgaver kræver særlig teknisk viden, for eksempel måling af svartider under belastning. Som begynder behøver du ikke kunne det hele. Start med at skelne mellem den forventede adfærd, den observerede adfærd og de spørgsmål, der endnu ikke er afklaret. Den skelnen danner grundlag for en brugbar undersøgelse.

Sådan griber en softwaretester en opgave an

En testopgave begynder typisk med en afgrænset ændring. Måske har en udvikler tilføjet muligheden for at nulstille en adgangskode. Før du tester, læser du beskrivelsen og afklarer, hvad løsningen skal gøre. Skal linket i mailen udløbe? Må det bruges flere gange? Hvilken besked skal brugeren få, hvis mailadressen ikke findes i systemet? Svarene afgør, hvad du skal undersøge.

Derefter beskriver du nogle testtilfælde. Et testtilfælde er en konkret situation med bestemte forudsætninger, handlinger og forventede resultater. Du kan eksempelvis begynde med en eksisterende brugerkonto, bede om en nulstilling og kontrollere, at mailen kommer frem. Bagefter åbner du linket, vælger en ny adgangskode og undersøger, om du kan logge ind med den.

Prøv også situationer tæt på løsningens grænser. Hvis en adgangskode ifølge kravene skal indeholde mindst otte tegn, er syv, otte og ni tegn relevante eksempler. Det er mere målrettet end at vælge tilfældige længder. Du kan desuden undersøge, hvad der sker, når et obligatorisk felt er tomt, eller brugeren går tilbage til den foregående side undervejs.

Notér resultaterne, så det fremgår, hvad du har gennemført, hvilke test der fejlede, og hvad du ikke kunne undersøge. Måske manglede der en testkonto, eller måske virkede mailtjenesten ikke i testmiljøet. Et testmiljø er en særskilt udgave af systemet, hvor afprøvning kan foregå uden at ændre rigtige kunders oplysninger. Det forudsætter dog, at miljøet er sat op til formålet, og at du bruger de aftalte testdata.

Når udvikleren har rettet en fejl, prøver du det samme forløb igen. Du kan også kontrollere nærliggende funktioner, som ændringen kan have påvirket. Det kaldes regressionstest. Formålet er at undersøge, om noget, der tidligere virkede, stadig fungerer efter ændringen.

Fejlbeskrivelser skal kunne bruges af andre

At finde en fejl er kun en del af opgaven. Den næste er at beskrive den, så en udvikler kan genskabe situationen. En besked som »bestilling virker ikke« giver meget lidt at arbejde med. En præcis fejlrapport fortæller derimod, hvor problemet opstår, hvilke handlinger der fører frem til det, og hvordan resultatet adskiller sig fra det forventede.

Tag et eksempel med en indkøbskurv. Du lægger to varer i kurven, fjerner den ene og fortsætter til betaling. Her viser ordresummen stadig prisen for begge varer. En brugbar beskrivelse angiver varerne, rækkefølgen af handlinger og de viste beløb. Koster varerne i dit tænkte testeksempel henholdsvis 100 kr. og 150 kr., skal det fremgå, hvilken vare du fjernede, og hvilken sum der burde stå tilbage.

Oplysninger om omgivelserne kan også være nødvendige. Fejlen optræder måske kun på en telefon, i en bestemt browser eller med en bestemt type brugerkonto. Et skærmbillede kan vise problemet, men erstatter ikke nødvendigvis en skriftlig forklaring. En kort optagelse kan være nyttig, hvis fejlen afhænger af en bestemt rækkefølge af handlinger eller et hurtigt dobbeltklik.

Hold observationer og antagelser adskilt. Du kan skrive, at ordresummen ikke ændres, uden at konkludere, at årsagen ligger i databasen. Årsagen skal undersøges. Notér også, om fejlen opstår hver gang eller kun indimellem. Har du kun set den én gang, er det den oplysning, du skal give videre.

Fejlens alvor og dens prioritet er to forskellige vurderinger. En stavefejl på forsiden kan være synlig for mange, mens en fejl i en sjældent brugt beregning kan få større konsekvenser. Testeren bidrager med dokumentation og beskriver, hvordan fejlen påvirker brugeren eller systemet. Rækkefølgen for rettelser bliver ofte besluttet sammen med udviklere og den produktansvarlige.

Din første øvelse og vejen videre

Du kan øve grundprincipperne uden først at lære programmering. Vælg en afgrænset funktion i et øvelsesprogram eller en lokal testløsning, som du har lov til at afprøve. Det kan være en simpel formular med navn, mailadresse og besked. Skriv først, hvad hvert felt skal acceptere. Undersøg derefter almindelige indtastninger, tomme felter og værdier tæt på de fastsatte grænser.

Lav et lille dokument med dine testtilfælde og resultater. Skriv så præcist, at en anden person kan gentage dine handlinger uden at spørge dig undervejs. Finder du ikke en fejl, kan du stadig vise, hvad du har undersøgt, og hvilke begrænsninger der var. Et testresultat er ikke mindre brugbart, fordi programmet opførte sig som forventet.

Efter de første manuelle øvelser kan du lære om automatiseret test. Her skriver man instruktioner, som et værktøj udfører, eksempelvis et gentaget loginforløb. Automatiserede test kræver vedligeholdelse, når systemet ændrer sig. De erstatter heller ikke arbejdet med at vælge relevante undersøgelser. Manuelle undersøgelser og automatiske kontroller løser forskellige dele af opgaven.

Du kan gradvist bygge teknisk viden ovenpå. SQL bruges til at arbejde med oplysninger i databaser. Et API er en grænseflade, som systemer kan bruge til at udveksle data. Grundlæggende kendskab til begge dele kan åbne for andre testopgaver end dem, du udfører gennem knapper og formularer. Hvilke færdigheder du får brug for, afhænger af stillingen.

Når du læser jobopslag, så se efter de konkrete opgaver frem for kun stillingsbetegnelsen. Nogle roller handler især om manuel test og dialog om krav. Andre kræver programmering og vedligeholdelse af automatiserede test. Til en jobsamtale om en begynderstilling kan du medbringe en øvelsesopgave, du selv har lavet, med testtilfælde, observationer og en fejlrapport. Brug kun opdigtede testdata, og undlad adgangskoder og oplysninger om rigtige personer.

Skal du kunne programmere for at begynde

Du kan begynde med manuel softwaretest uden at kunne programmere, men kravene varierer fra stilling til stilling. Vil du arbejde med automatiserede test, skal du typisk lære programmering og de værktøjer, arbejdspladsen bruger. I de første manuelle øvelser kan du koncentrere dig om at beskrive forventninger, afprøve konkrete situationer og dokumentere resultaterne tydeligt.

Kan en softwaretester finde alle fejl

Nej, test kan ikke garantere, at et system er fejlfrit. Undersøgelserne udvælges blandt andet efter, hvad der er ændret, hvordan systemet bruges, og hvilke konsekvenser en fejl kan få. Testeren beskriver også, hvilke områder der ikke er undersøgt. Hvis en betalingsfunktion kun er afprøvet med én betalingsmetode, skal den begrænsning fremgå, så andre ikke forveksler resultatet med en kontrol af alle betalingsmuligheder.