9 typer softwaretest i softwareudvikling

Softwaretest er et håndværk. En softwaretester skal ligesom en håndværker have en solid forståelse af de softwaretestværktøjer, de har til rådighed. Vi har samlet en liste over 9 forskellige typer softwaretest og de værktøjer, som hver type anvender, for at hjælpe QA-analytikere og alle andre, der arbejder inden for softwaretest, med bedre at forstå deres håndværk.

Hvorfor har vi brug for softwaretest?

Nogle gange er det vigtigt at blive mindet om, hvorfor det, du gør, betyder noget. Den simple kendsgerning er, at al software, der nogensinde er blevet udviklet og har opnået succes, har gjort det med hjælp fra softwaretestere, der utrætteligt har arbejdet på at sikre, at produktet havde så høj en standard som muligt. Her er tre grunde til, at softwaretest er vigtigt. 

1. Kundetilfredshed: Når man udvikler et projekt, kan det være let at fare vild i kodens skov og glemme, at brugeren også skal være tilfreds med den måde, softwaren fungerer på. QA-analytikere og andre QA-medarbejdere udfylder denne rolle. 
2. Produktkvalitet: Ethvert erhverv, hvor et team eller en enkeltperson skaber noget fra bunden, kræver et andet team til at opdage deres fejl. Forfattere har brug for redaktører. Filminstruktører har også brug for redaktører. Softwareudviklere har ikke brug for redaktører, men de har brug for et QA-team, der kan tilbyde et objektivt perspektiv og opdage eventuelle fejl. 
3. Sikkerhed: For hver dag, der går, synes dette punkt at blive stadig vigtigere. Kunderne ønsker ro i sindet, fordi de ved, at de oplysninger, de indtaster i softwaren, og det arbejde, de udfører i den, forbliver private. En del af QA er at sikre, at kunderne har denne tillid. 

Metoder til softwaretest

Alle typer softwaretest, der nævnes i denne artikel, tilhører en af to hovedkategorier: statisk testning og dynamisk testning. Før vi gennemgår de specifikke detaljer ved de ni forskellige softwaretestteknikker, vil jeg forklare forskellen mellem disse to metoder, og hvor i softwareudviklingscyklussen de kommer i spil. 

Statisk testning

Statisk testning er en type softwaretest, der udføres tidligt i udviklingscyklussen. Det er en omkostningseffektiv måde at finde fejl på, før de bliver til store problemer for udviklingsteamet. Statiske test køres tidligt i udviklingscyklussen, fordi de kan udføres uden fuldt funktionsdygtig software. Det er rigtigt, softwaren kan fejlfindes, før den overhovedet er i nærheden af at være færdig. Kan du se, hvordan det kan være nyttigt? 

Statiske test udføres på to måder:

• Manuelle undersøgelser: Koden analyseres af en QA-analytiker eller tester. 
• Automatisk analyse: Et testværktøj kontrollerer automatisk programdokumentet og noterer eventuelle fejl.

Statisk testning er:

• Udført uden at køre kode.
• Omkostningseffektiv.
• Nyttig til at sikre, at softwaren opfylder verifikationsspecifikationerne.
• En måde at fastslå den grundlæggende årsag til fejl på.

De fleste statiske test udføres i form af dokumentgennemgange. I dette scenarie er et dokument enten en skriftlig beskrivelse af et produkt (kendt som et softwaredesign-dokument) eller programmets kildekode. Her er nogle statiske testteknikker, som enhver QA-analytiker bør kende:

• Uformel gennemgang:  Der er ingen strenge retningslinjer for den uformelle gennemgang. Teamet gennemgår testdokumenterne og kommenterer på det, de ser. Der er ingen dokumentation.
• Gennemgang: Kodeforfatteren gennemgår sit dokument, og QA-teamet stiller spørgsmål og fremfører bekymringer. Gennemgange er typisk meget uformelle og en god måde at drøfte emner med personer uden for softwareområdet på. 
• Teknisk gennemgang: Tekniske eksperter samles og gennemgår kodens tekniske specifikationer. Ved at gøre dette tidligt i udviklingsprocessen sikrer man, at det endelige produkt opfylder de krævede specifikationer.
• Inspektioner: Den mest formelle af alle gennemgange. Et team af uddannede moderatorer inspicerer dokumenterne grundigt under mødet. Eventuelle fundne fejl dokumenteres og logges formelt med henblik på gennemgang. Der foretages en opfølgning for at kontrollere, at de dokumenterede fejl er blevet håndteret. 

I de fleste tilfælde er statiske testgennemgange nyttige, fordi hele QA-teamet analyserer produktet og foreslår ændringer baseret på de problemer, de ser, og problemer, der kan forudses. Ud over fordelen ved at få en bred vifte af stemmer involveret i samtalen har dette den yderligere fordel, at alle teammedlemmer bliver opdateret om projektets fremskridt og design. 

Brug statisk testning, hvis dit team:

• Er tidligt i udviklingsprocessen.
• Leder efter en omkostningseffektiv måde at finde fejl på.
• Har software, der ikke er klar til at blive kørt.
• Vil opdage fejl tidligt i udviklingen.

Dynamisk testning

I modsætning til statisk testning er dynamisk testning en type softwaretest, der kræver, at kode køres. Det kræver naturligvis, at udviklingen er længere fremme i produktionscyklussen. Fordelen ved at teste eksekverbar kode er, at QA-analytikere kan se på, hvordan softwaren fungerer under kørsel i en situation fra den virkelige verden. Det er en god måde at kontrollere softwarens funktionelle adfærd og andre ting som CPU-forbrug på. Dynamisk testning kontrollerer, at det forventede resultat stemmer overens med resultatet fra det virkelige liv. Hovedmålet med dynamisk testning er at verificere, at produktet opfylder de design- og funktionelle krav, der blev fastlagt, før projektet begyndte.

Typisk er der fire trin involveret, når systemsoftware testes dynamisk, som QA-analytikere bør kende:

• Enhedstest: Når software gennemgår enhedstest, opdeles den i de mindst mulige komponenter, som testes individuelt. Ved at teste på denne måde kan QA-analytikere være trygge ved, at hver enkelt del af softwaren fungerer efter hensigten. Hvis der findes en fejl, vil det være lettere at rette den på dette udviklingstrin, hvor problemkoden hurtigt kan isoleres. Når QA-teamet typisk begynder den dynamiske testning (selvom dette testtrin nogle gange håndteres af udviklingsteamet), starter de med enhedstest.
• Integrationstest: Når softwaren er blevet grundigt opdelt i sine komponenter og testet via enhedstest, samles softwaren i grupper og testes igen. Hvis enhedstest skal sikre, at hver enkelt del kører korrekt, sikrer integrationstest, at de enkelte dele kommunikerer med hinanden, som de skal. Tænk på det som samlingen af en bil. På hvert trin i samlingen testes bildelene (motoren, pedalerne, rattet) individuelt. Derefter samles bilen og testes som en helhed for at sikre, at speederen kommunikerer korrekt med motoren (og at bremserne også gør det!). Vil du sikre problemfri integration mellem moduler? Vores anbefalede softwaretestværktøjer kan hjælpe dig med netop det.
• Systemtest: Systemtest er det tredje niveau inden for softwaretest. På dette trin testes en komplet og fuldt integreret software. Formålet med systemtesten er at sikre, at softwaren opfylder kravene, dvs. gør det, den er designet til at gøre. 
• Acceptancetest: Det sidste trin i dynamisk testning. Formålet med acceptancetesten er endnu en gang at teste op mod kravene og sikre, at softwaren er færdiggjort til en acceptabel standard. Den udføres for at sikre, at ingen fejl er sluppet igennem de andre testtrin. Grundlæggende er det en ekstra kontrol af hensyn til sikkerheden. 

Trin i dynamisk testning

1. Enhedstest
2. Integrationstest
3. Systemtest
4. Acceptancetest
   

Hurtigt tip: Verifikations- kontra valideringstest 

Verifikationstest deler alle de vigtigste kendetegn ved statisk testning. Formålet med en verifikationstest er at verificere alle dokumenter og al kode, og det opnås gennem de samme metoder, som bruges ved statisk testning

På samme måde deler valideringstest alle de vigtigste kendetegn ved dynamisk testning. En verifikationstest handler om at bekræfte, at softwaren er af høj kvalitet, hvilket er præcis det, system- og acceptancetest fokuserer på.

Nu hvor vi har gennemgået nogle centrale begreber inden for softwaretest, kan vi se nærmere på de 9 typer softwaretest, som alle QA-analytikere bør kende.

9 typer softwaretest, som alle QA-analytikere bør kende:

1. Sort boks
2. Hvid boks
3. Grå boks 
4. Automatiseret 
5. Enhedstest
6. Regressionstest
7. Eksplorativ testning
8. Funktionel testning
9. Brugervenlighedstest

1. Sortboks-test

Sortboks-test er en softwareteststrategi, hvor designet af det softwaresystem, der testes, er ukendt for testeren.

Husk scenen i slutningen af Pulp Fiction, hvor Samuel Jackson åbner dokumentmappen, og hans ansigt lyser op? Som publikum ved vi, hvad dokumentmappen betyder og repræsenterer i filmens sammenhæng, men vi finder aldrig ud af, hvad der er indeni. En sortboks-tester er tilskueren, der ved, hvad genstanden (uanset om det er en dokumentmappe eller systemsoftware) skal gøre, men ikke hvad den er lavet af.

En tester, der er ansvarlig for sortboks-test af et tidsregistreringsprogram, åbner programmet uden kendskab til softwarens interne design og prøver de forskellige funktioner og menuer for at sikre, at de fungerer som forventet. Formålet med sortboks-test er, at testeren uden indgående kendskab til softwarens design vil tilgå softwaren med samme forventninger som slutbrugeren. 

Nogle fordele ved sortboks-test er:

• Testere behøver ikke meget kendskab til programmeringssprog, fordi testeren bruger softwaren fra en brugers perspektiv.
• Giver en uvildig vurdering af softwaren, fordi softwaretesten udføres af QA-teamet i stedet for softwareudviklerne.
• Testerne behøver ikke at være ajour med udviklingen af softwaresystemet, hvilket betyder, at der er meget kort forberedelsestid, før testene kan udføres.

Relateret læsning: 10 bedste værktøjer til sortboks-test

2. Hvidboks-test

Ved hvidboks-test har QA-medarbejderen fuldt kendskab til den interne struktur og det interne design af den software, der testes. Testeren tilgår testen som en inspektør og sikrer, at alle dele af programmet fungerer korrekt. Hvidboks-test kaldes nogle gange klarboks-test, fordi testeren observerer interaktionerne mellem enheder, mens softwaren testes. I modsætning til sortboks-test er en hvidboks-tester ikke nær så optaget af brugeroplevelsen. 

Nogle fordele ved hvidboks-test er:

• Test kan udføres på tidlige udviklingsstadier. Den grafiske brugergrænseflade (GUI) behøver ikke at være fuldt funktionsdygtig. 
• Testene er mere grundige og målrettede end sortboks-test.

I Pulp Fiction-eksemplet er hvidboks-testeren Tim Roths karakter, der stirrer direkte på det, der er inde i dokumentmappen. 

3. Gråboks-test

Ved gråboks-test har testeren en vis viden om softwarens interne struktur og design (hvidboks), men tester stadig fra slutbrugerens perspektiv (sortboks). Sådan opstod gråboks-test. Ved gråboks-test udvikles testens design ved at se på softwarens interne struktur, mens selve testen udføres ved hjælp af brugergrænsefladen.

Igen, hvis dette var den berømte scene fra Pulp Fiction, er gråboks-testeren hverken publikum eller Tim Roth. Denne gang er testeren Quentin Tarintino selv.  

4. Automatiseret test

Automatiserede tests bruger software til at udføre opgaver uden manuel instruktion fra en tester.

Ved manuel test skriver testeren den kode, der skal udføres, eller planlægger den softwaresti, som skal kontrolleres for at sikre, at den fungerer korrekt. Automatiserede tests tager sig af sådanne ting på testernes vegne. Her er en kort liste over automatiseret software og QA-værktøjer, som QA-analytikere bør kende:

• Selenium 
• Cucumber
• Katalon Studio

Hvis du vil have en mere dybdegående gennemgang af værktøjer til automatiseret test, kan du se listen over de bedste værktøjer til automatiseret test, som du bør bruge.

5. Enhedstest

Enhedstestværktøjer sikrer, at alle individuelle dele af softwaren fungerer korrekt. Det er ekstremt vigtigt at sikre, at enhedstestningen udføres korrekt, ellers vil udviklingsteamet opleve et stort tilbageslag, når de senere opdager, at en vigtig del af deres software ikke fungerer. 

6. Regressionstest

Regressionstestværktøjer kører gamle tests på nye builds for at sikre, at softwaren stadig fungerer som tilsigtet. Ved at køre regressionstests beskyttes udviklerne mod skjulte konsekvenser, fordi det sikres, at en ændring i softwaren på punkt A ikke ved et uheld ødelægger noget helt ovre på punkt D. 

For en QA-analytiker bør to skridt frem og ét skridt tilbage ikke betragtes som noget negativt. Ved at tage ét skridt tilbage en gang imellem sikrer du, at du ikke senere står til at tage halvtreds skridt tilbage.

7. Eksplorativ testning

Eksplorativ testning er testning for mennesker, der ikke kan lide planlægning. I de fleste andre situationer planlægges testscenariet grundigt, før det udføres. Men ikke her. Når en tester udfører en eksplorativ test, undersøger vedkommende softwaren uden en foruddefineret plan ved hjælp af specialiserede værktøjer til eksplorativ testning.

Fordelen ved eksplorativ testning er, at testeren kan tilpasse sig sine resultater undervejs uden at skulle skrive endnu et testscenarie. Eksplorativ testning giver også mulighed for samarbejde, udvikling af teorier og fælles problemløsning undervejs.

Efterhånden som den agile udviklingsteori er blevet mere fremtrædende, er eksplorativ testning også blevet det. Ved at give QA-testere mulighed for at bruge deres intuition opdages mange interessante fejl, som en traditionel testudførelse måske ikke ville have ledt efter. 

Vær advaret: eksplorativ testning kan kræve en hel del kreativitet. 

8. Funktionstest

Funktionstest udføres for at sikre, at systemsoftwaren opfylder projektets krav, før udviklingen begynder.

Softwaretesteren kontrollerer, at inputtet giver det forventede resultat. Testen udføres i en af de sidste testfaser, enten som systemtest eller accepttest, og er udelukkende en form for sortboks-test, da den ikke beskæftiger sig med, hvordan softwaren fungerer, så længe den fungerer. 

9. Brugervenlighedstest

Testere af brugervenlighed sikrer, at designvalgene både er funktionelle og intuitive.

Hvis du forventer, at mange brugere af din software vil sikkerhedskopiere deres dokumenter hver halve time, er det bedst at placere sikkerhedskopieringsfunktionen et let tilgængeligt sted i stedet for at gemme den bag fire undermenuer. 

Det er sket mange gange, at der er blevet udviklet et stykke software, som fungerer fejlfrit og opfylder et vigtigt behov på markedet, men som er fuldstændig umuligt at navigere i fra brugerens perspektiv. Det kan forklares med manglende brugervenlighedstest under softwaretestfasen.

I sidste ende vil det, uanset hvor teknisk godt et stykke software er, være svært at finde et marked, hvis brugerne ikke nyder at bruge det.

Vil du have mere?

Softwaretestbranchen ændrer sig hele tiden, og QA-analytikere skal holde sig opdateret om aktuelle tendenser. Der findes utallige ressourcer om softwaretest, herunder podcasts, bøger, nyhedsbreve og meget mere.

Tilmeld dig The CTO Clubs nyhedsbrev for produktopdateringer, værktøjsanmeldelser og flere samlinger af ressourcer.