Adhoc-testning udføres normalt for at bryde systemet og ved hjælp af ukonventionelle måder. Den mest forbløffende egenskab ved Adhoc-testning er, at den ikke har nogen testdesignteknik til at skabe testcases.

Processen udføres normalt for at finde smuthuller i en software. Da Adhoc-testning ikke har testcases, udføres den ofte uden nogen dokumentation.

Se processen i detaljer

Adhoc-testning er en teknik, der hører under kategorien “ustruktureret testning”.

Hvad er struktureret og ustruktureret testning?

Struktureret testning

I denne tilgang er alle aktiviteter, der finder sted under testproceduren, lige fra oprettelsen af testcases til deres sekventielle udførelse, alt er scriptet. Testerne følger dette script for at udføre testene i henhold til det.

Ustruktureret testning

I denne tilgang udføres testning almindeligvis ved hjælp af fejlgætteri, hvor testerne skaber testcases under selve testprocessen.

Hvad er ad hoc-testning?

Som beskrevet ovenfor er det en type ustruktureret testtilgang, hvor der ikke oprettes nogen organiseret plan, før testprocessen påbegyndes.

Der er derfor forud for testen ingen kravdokumentation eller planlægning og udformning af testtilfælde udført.

Ad-hoc testning udføres normalt af en tester, der har et stærkt kendskab til den testede software med hensyn til, hvad den gør, og hvordan den fungerer.

Denne testning udføres ved tilfældigt at oprette testcases ved at gætte på fejl og udføre dem, uden at følge nogen krav til testen.

En stor del af denne testning er at finde frem til de potentielle områder i softwaren, hvor der kan være fejl.

Det er derfor, at den også nogle gange er kendt som Monkey Testing eller Random Testing. Derfor er det vigtigt, at det kun er de testere, der har et godt kendskab til softwaren, der udfører denne test.

En fordel ved Ad-Hoc-testning er, at den sparer en hel del tid, som ellers går til udarbejdelse af dokumenter som testkrav, planlægning af testcases, design osv.

Den udføres også generelt, efter at den strukturerede testning allerede er blevet udført. Dette gøres for at finde frem til ualmindelige fejl i softwaren, som ikke kunne opdages ved at følge de forudgående skrevne testcases.

Typer af adhoc-testning

1) Buddy-testning

I denne type adhoc-testning udføres testene med en holdindsats af mindst to personer. Dette team består normalt af mindst én softwaretester og én softwareudvikler.

Denne type testning finder sted, efter at udførelsen af enhedstest af et modul er afsluttet.

Teamet af de to ‘buddies’ arbejder sammen om det pågældende modul for at skabe gyldige testcases.

Dette gøres, så testeren ikke ender med at rapportere fejl, der er genereret gennem ugyldige testcases. Denne type test kan også betragtes som en kombination af både enheds- og systemtestning.

2) Monkey Testing

Den tilfældige tilgang, der anvendes i denne test, er grunden til, at den betegnes som “monkey testing”.

Her leveres den software, der testes, med tilfældige input, for hvilke deres tilsvarende output observeres.

På baggrund af de opnåede output bestemmes eventuel forekomst af fejl, inkonsistenser eller systemnedbrud.

3) Partestning

Denne testning minder meget om makkertestning. Her er det dog kun et par af testerne, der arbejder sammen om de moduler, der skal testes.

De arbejder sammen for at dele idéer, meninger og viden om den samme maskine for at identificere fejl og mangler.

Testerne er parret efter deres vidensniveau og ekspertise, for at få en anden indsigt i ethvert problem.

Kendetegn ved adhoc-testning

• Denne testning udføres, efter at formelle testteknikker allerede er blevet udført på softwaren. Grunden til dette er, at ad hoc-tests udføres for at finde ud af de uregelmæssigheder i applikationen, som ikke kan forudsiges før testen.

Denne testning kan kun udføres af de testere, som har et godt og grundigt kendskab til applikationens funktion. Dette skyldes, at effektiv “fejlvurdering” kun kan foretages, når testeren ved, hvad applikationen gør, og hvordan den fungerer. Ad-hoc-testteknikken er mest velegnet til at finde fejl og uoverensstemmelser, som giver anledning til kritiske huller i en applikation. Sådanne fejl er normalt meget vanskelige at afsløre. Denne testning tager forholdsvis mindre tid end andre testteknikker. Det skyldes, at den udføres uden forudgående planlægning, design og strukturering.

• Ad-Hoc-testning udføres kun én gang, da eventuelle fejl, der findes, skal testes igen.

Eksempler på Adhoc-testning

• Testning af, om en applikation fungerer korrekt, når browserindstillingerne er forskellige. F.eks. identificering af fejl, der opstår, når indstillingen for JavaScript er deaktiveret i forskellige browsere osv.

Test af applikationen på tværs af platforme. Det er vigtigt at kontrollere, om den udviklede applikation kan køre flydende på forskellige operativsystemer eller browsere.

• Forsendelse af input til systemet, der ligger uden for det gyldige inputområde, for at kontrollere, om den resulterende handling, som applikationen foretager, er hensigtsmæssig eller ej.

Kopiering af applikationens URL og manipulation af den for at køre på en anden browser. Dette gøres for at sikre, at uautoriserede brugere ikke kan få uautentificeret adgang til systemet.

• Gå gennem en række tilfældige trin eller navigere tilfældigt gennem programmet for at kontrollere de resultater, der opnås ved at gennemgå en bestemt kombination af usædvanlige input.

Hvornår skal man udføre ad hoc-testning

Usuelt udføres ad hoc-testning, når der ikke er tid nok til at udføre udtømmende og grundig testning, hvilket omfatter udarbejdelse af testkravsdokument, testcases og testcasedesigns.

Det perfekte tidspunkt til at udføre denne type test er efter afslutningen af de formelle testteknikker.

Ad-hoc-test kan dog også udføres midt i udviklingen af softwaren.

Det kan udføres efter den komplette udvikling af softwaren, eller endda efter at et par moduler er blevet udviklet.

Det kan også udføres under processen med formelle testmetoder også.

Der er nogle få situationer, hvor denne testning dog ikke må udføres. Derfor skal enhver tester vide, hvornår denne testning skal undgås.

Nedenfor er angivet nogle få forhold, hvor ad-hoc testning ikke må udføres:

• Ad-hoc testning må ikke udføres, når der udføres betatest. Dette skyldes, at Beta-testning involverer kunderne, som tester den udviklede software for at komme med forslag til nye funktioner, der skal tilføjes, eller for at ændre kravene til den.

Denne testning anbefales også ikke at blive udført i de testcases, som allerede har eksisterende fejl i dem. Fejlene skal først dokumenteres ordentligt, før de fjernes fra systemet. Når de er rettet, skal testcases testes igen for at sikre, at de fungerer korrekt.

Hvad er fordelene ved ad hoc-testning?

En af fordelene ved ad hoc-testning er, at mange fejl, som normalt ikke opdages, når der kun anvendes formelle testmetoder, kan findes ved at teste applikationen tilfældigt. Testerne får mulighed for at udforske applikationen frit, alt efter deres intuition og forståelse af applikationen. De kan derefter udføre testene undervejs, hvilket hjælper dem med at finde fejl i løbet af denne proces.
• Testere såvel som udviklerne af applikationen kan nemt teste applikationen, da der ikke er behov for at planlægge og designe testcases. Dette hjælper udviklerne til nemt at generere mere effektive og fejlfrie koder.
• Denne testning kan også hjælpe med at skabe unikke testcases, der kan ineffektivt opdage fejl. Derfor kan sådanne testcases tilføjes til den formelle testning sammen med andre planlagte testcases.
• Ad-hoc-testning kan udføres på et hvilket som helst tidspunkt i løbet af softwareudviklingslivscyklussen, fordi den ikke følger nogen formel proces.
• Den kan kombineres med andre testteknikker og udføres for at producere mere informative og effektive resultater.

Hvad er ulemperne ved ad hoc-testning?

• Da testprocessen ikke er dokumenteret, og der ikke følges en bestemt testcase, bliver det meget vanskeligt for testeren at genskabe en fejl. Dette skyldes, at testeren skal huske de nøjagtige trin, som han fulgte for at få den pågældende fejl, hvilket ikke er muligt hver gang.
• I nogle tilfælde rapporteres der ugyldige fejl på grund af udførelsen af ugyldige testcases, der er tilfældigt udviklet af testeren, hvilket bliver et problem i de efterfølgende fejlrettelsesprocesser.
• Hvis testerne ikke har forudgående viden om, hvordan den testede applikation fungerer, vil udførelsen af ad hoc-test ikke kunne afdække mange fejl. Dette skyldes, at testerne skal arbejde sig gennem fejlgætteri og intuitivt oprette og udføre testcases på stedet.

Ad-hoc-testning giver ikke sikkerhed for, at fejlene vil blive fundet. Proaktivt fejlgætteri til testning afhænger helt af testerens færdigheder og viden.

• Da der ikke tidligere er oprettet og dokumenteret testcases, er det fortsat usikkert, hvor meget tid og indsats der går til denne testning. Nogle gange kan det tage enormt lang tid at finde bare én fejl.

Bedste praksis for at udføre ad hoc-testning

For effektivt at udføre ad hoc-testningsteknikken er det vigtigt at kende de mest effektive og effektive måder at gøre det på.

Dette skyldes, at hvis testene ikke udføres på en ordentlig måde, vil den indsats og tid, der er lagt i testene, være spildt.

For at gennemføre denne type test skal man derfor kende de bedste metoder, der kan hjælpe med en mere omfattende tilgang til testning:

1) Godt kendskab til software

Sørg for, at den tester, der er udpeget til at teste applikationen via ad-hoc-tilgangen, har et godt greb om applikationen.

Testeren skal være bekendt med alle applikationens funktioner, så det bliver lettere at “gætte fejl” på applikationen.

Med tilstrækkelig viden til at understøtte testerens testproces bliver det lettere at finde flere fejl, fejl og inkonsekvenser.

2) Find ud af fejltrængende områder

Hvis testere, hvordan ikke er bekendt med applikationen, så er den bedste praksis for dem til at starte deres testproces at tjekke efter den del af applikationen, hvor størstedelen af fejlene ligger.

Det at vælge sådanne følsomme områder til at udføre ad hoc-tests kan hjælpe dem med at finde fejl lettere.

3) Prioritér testområder

Det er altid bedre at starte testen fra de områder af applikationen, der er mest brugt af slutbrugerne eller kunderne. Dette hjælper med at sikre de vigtige funktioner og rapportere eventuelle fejl på forhånd.

4) Planlæg testplanen groft

Selv om adhoc-testning ikke kræver nogen forudgående planlægning eller dokumentation, viser det sig at være meget nyttigt og effektivt, hvis der på forhånd udarbejdes en grov plan.

Det at notere de vigtigste pointer og områder, der kræver testning, kan hjælpe testerne med at dække den maksimale del af applikationen på kort tid.

5) Værktøjer

Det er vigtigt at gøre brug af den rigtige slags værktøjer som f.eks. debuggere, task monitors og profilers for at lette testprocessen.

Dette skyldes, at der er tidspunkter, hvor specifikke fejl og undtagelser ikke kan ses og ikke bliver fanget under testen.

Hvorimod kan brugen af de rigtige værktøjer hjælpe med at isolere fejlen på kort tid.

Adhoc-testning vs. udforskende testning

Adhoc-testning	Udforskende testning
Testerne skal have en klar idé om applikationens arbejdsgang	Testerne lærer om den applikationen undervejs
Mere om perfektionering af testprocessen	Det er en læringsmetode til at kende applikationen
En form for positiv testning	En form for negativ systemtestning
Der er ingen plan	En charterbaseret plan vil blive taget i brug
Der er ingen foreslået tidsgrænse	Tidsramme/karaktervektor
Kan udføres af softwaretestingeniøren	Måtte være udføres af eksperten
Fokus er på ansøgningsprocessen	Dataindtastningsområder vil være det primære fokus
Kompleksiteten af tests vil ikke genere meget denne proces	Udfordringer involveret