9 typer softwaretest i softwareudvikling

Softwaretest er et håndværk. En softwaretester skal ligesom en håndværker have en grundig forståelse af de softwaretestværktøjer, der er til rådighed. Vi har samlet en liste over 9 forskellige typer softwaretest og de værktøjer, som hver type bruger, 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, er vigtigt. Den enkle 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 den højest mulige standard. 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: Alle 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 give et objektivt perspektiv og opdage eventuelle fejl. 
3. Sikkerhed: For hver dag, der går, virker dette punkt stadig vigtigere. Kunder ønsker ro i sindet ved at vide, at de oplysninger, de indtaster i softwaren, og det arbejde, de udfører i den, forbliver private. En del af QA-arbejdet består i at sikre, at kunderne har denne tillid. 

Metoder til softwaretest

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

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. Ja, softwaren kan fejlsøges, før den overhovedet er tæt på 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.

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 alle QA-analytikere 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 udarbejdes ingen dokumentation.
• Gennemgang: Forfatteren til koden 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. Alle fejl, der findes, dokumenteres formelt og registreres til 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å 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 ekstra fordel, at alle teammedlemmer bliver opdateret om projektets fremskridt og design. 

Brug statisk test, hvis dit team:

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

Dynamisk test

I modsætning til statisk test er dynamisk test en type softwaretest, der kræver, at koden 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, mens den kører i en situation fra den virkelige verden. Det er en god måde at kontrollere softwarens funktionelle adfærd og andre ting såsom CPU-forbrug. Dynamisk test kontrollerer, at det forventede resultat stemmer overens med resultatet i det virkelige liv. Det primære mål med dynamisk test er at verificere, at produktet opfylder de designmæssige 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 underkastes enhedstest, opdeles den i de mindst mulige komponenter, som testes individuelt. Ved at teste på denne måde kan QA-analytikerne være trygge ved, at hver enkelt del af softwaren fungerer efter hensigten. Hvis der findes en fejl, er det lettere at rette den på dette udviklingstrin, hvor problemkoden hurtigt kan isoleres. Typisk begynder QA-teamet den dynamiske test (selvom dette testtrin nogle gange håndteres af udviklingsteamet) med enhedstest.
• Integrationstest: Når softwaren er blevet grundigt opdelt i sine komponenter og testet via enhedstest, samles komponenterne i grupper og testes igen. Hvis enhedstest sikrer, at hver enkelt del fungerer 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 bilens dele (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 en 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, altså gør det, den er designet til at gøre. 
• Acceptancetest: Det sidste trin i dynamisk test. Acceptancetesten går endnu en gang ud på at teste i forhold til 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 øvrige testtrin. Grundlæggende er det en ekstra kontrol af hensyn til sikkerheden. 

Trin i dynamisk test

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

Hurtigt tip: Verifikationstest kontra valideringstest 

Verifikationstest har alle de vigtigste kendetegn ved statisk test. 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 test

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

Nu hvor vi har gennemgået nogle centrale begreber inden for softwaretest, kan vi udforske 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 test
8. Funktionel test
9. Brugervenlighedstest

1. Sortboks-test

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

Kan du huske scenen i slutningen af Pulp Fiction, hvor Samuel Jackson åbner kufferten, og hans ansigt lyser op? Som publikum ved vi, hvad kufferten betyder og repræsenterer i filmens sammenhæng, men vi får aldrig at vide, hvad der er indeni. En sortboks-tester er publikum, som ved, hvad tingen (uanset om det er en kuffert eller systemsoftware) skal gøre, men ikke hvad den er lavet af.

En tester, der har ansvaret for sortboks-test af et tidsregistreringssystem, åbner programmet uden kendskab til softwarens interne design og afprøver de forskellige funktioner og menuer for at sikre, at de fungerer som forventet. Grunden til at udføre sortboks-test er, at testeren uden indgående kendskab til softwarens design vil gå til softwaren med forventninger, der ligner slutbrugerens. 

Nogle fordele ved sortboks-test er:

• Testere behøver ikke megen viden om 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 fuld forståelse af den interne struktur og det interne design i den software, der testes. De går til testen som en inspektør og sikrer, at alle dele af programmet fungerer korrekt. Hvidboks-test kaldes nogle gange gennemsigtig boks-test, fordi testeren observerer interaktionerne mellem enheder, mens de tester softwaren. I modsætning til sortboks-test er en hvidboks-tester ikke nær så optaget af brugeroplevelsen. 

Nogle fordele ved hvidboks-test er:

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

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

3. Gråboks-test

Ved gråboks-test har testeren en vis viden om softwarens interne struktur og design (hvid boks), men tester stadig fra en slutbrugers perspektiv (sort boks). 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.

Hvis dette igen 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, de vil udføre, eller planlægger den softwaresti, de vil kontrollere fungerer korrekt. Automatiserede tests håndterer sådanne ting på testerens 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

Værktøjer til enhedstest sikrer, at hver enkelt del 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

Værktøjer til regressionstest kører gamle test på nye programversioner for at sikre, at softwaren stadig fungerer som tilsigtet. Regressionstest beskytter udviklere mod skjulte effekter ved at sikre, at en ændring i softwaren ved punkt A ikke ved et uheld har ødelagt noget helt ovre ved punkt D. 

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

7. Eksplorativ testning

Eksplorativ testning er testning for personer, der ikke kan lide planlægning. I de fleste andre situationer planlægges testtilfældet grundigt, før den udføres. Sådan er det ikke her. Når en tester udfører en eksplorativ test, udforsker vedkommende softwaren uden nogen foruddefineret plan ved hjælp af specialiserede værktøjer til eksplorativ testning.

Fordelen ved eksplorativ testning er, at den giver testeren mulighed for at tilpasse sig sine resultater undervejs uden at skulle skrive et nyt testtilfælde. Eksplorativ testning giver også mulighed for samarbejde, udvikling af teorier og videndeling 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 bliver mange interessante fejl opdaget, som en traditionel testudførelse måske ikke ville have ledt efter. 

Vær opmærksom på, at eksplorativ testning kan kræve stor kreativitet. 

8. Funktionel testning

Funktionel testning udføres for at sikre, at systemsoftwaren opfylder projektets krav, før udviklingen begyndte.

Softwaretesteren kontrollerer, at inputtet svarer til det forventede resultat. Den 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. Brugervenlighedstestning

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

Hvis du forudser, 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. 

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

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

Vil du vide mere?

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

Abonnér på The CTO Clubs nyhedsbrev for produktopdateringer, værktøjsanmeldelser og flere ressourceoversigter.