Planlægning af ad hoc-testning

I denne artikel har vi dækket ad hoc-testning, dens typer, fordele, ulemper og bedste praksis for ad hoc-testning.

Hvad er ad hoc-testning?

Ad hoc-testning, der undertiden kaldes “tilfældig testning” eller “abetestning”, er defineret som en uformel testtype. Formålet med denne proces er at bryde systemet ved hjælp af ukonventionelle metoder. Denne type softwaretestning er generelt uplanlagt og følger ikke nogen specifikke testdesignteknikker for at skabe testcases.

Det primære formål med ad hoc-testning er at finde eventuelle fejl gennem tilfældig kontrol. Testeren improviserer trinene ved at udføre dem vilkårligt. Dette kan afdække meget specifikke og interessante fejl, som let overses ved brug af andre metoder.

Det mest overraskende aspekt ved ad hoc-testning er, at den ikke omfatter nogen testdesignteknikker. Det betyder, at selv om denne metode finder fejl, som måske ikke normalt bliver fundet, er den vanskeligere at reproducere, da der ikke er nogen skriftlige testcases eller dokumentation.

Succesen med ad hoc-testning afhænger i virkeligheden af testerens kreativitet og vedholdenhed og skyldes nogle gange bare rent held. Ad hoc-testteknikken falder direkte ind under kategorien “ustruktureret testning”.

Struktureret vs. ustruktureret testning

Struktureret testning

Denne tilgang sikrer, at hver aktivitet, der finder sted under testproceduren, er scriptet, lige fra oprettelsen af testcases til den sekventielle udførelse. Testeren følger scriptet for at gennemføre testene med succes.

Ustruktureret testning

Denne tilgang indebærer testning ved hjælp af fejlgætteri. Testeren opretter testcases under testprocessen.

Typer af ad hoc-testmetoder

Buddy-testning

Denne type ad hoc-testning udføres med mindst to personer. Den finder sted, efter at enhedstest af et modul er blevet gennemført og afsluttet. Denne type testning kan også betragtes som en kombination af både system- og enhedstestning.

Det primære formål er, at to “buddies” arbejder på at identificere fejl eller mangler i det samme modul på samme tid. Dette team vil normalt bestå af en softwareudvikler og en softwaretester.

De to ‘buddies’ arbejder sammen på det pågældende modul for at skabe gyldige testcases. Denne proces sikrer, at testeren ikke rapporterer fejl, som ugyldige testcases kan have genereret.

Buddy testing har vist sig at være en succes, da den hjælper testeren med at udvikle bedre testcases og giver udviklingsteamet mulighed for at foretage designændringer så tidligt som muligt.

Monkey Testing

På grund af testens tilfældige karakter har denne metode fortjent navnet “monkey testing”. Monkey testing udføres oftest på unit testing-niveauet. Her tester tester testerne tilfældigt applikationen eller produktet uden testcases. Testerens hovedmål er at analysere dataene eller testene på helt tilfældige måder for at sikre, at systemet er i stand til at modstå ethvert nedbrud.

Testerne forsyner softwaren med tilfældige input og observerer deres tilsvarende output. På baggrund af outputdataene kan de bedre bestemme eventuelle fejl, inkonsekvenser eller systemnedbrud.

Pair testing

Par testing ligner på nogle måder “buddy testing”, men “pair testing” indebærer, at et par testere arbejder sammen om de moduler, der skal testes. De to testere deler ideer, viden og meninger om den samme maskine for at identificere fejl eller mangler.

Denne testmetode indebærer, at der anvendes testere, der er parret efter deres ekspertise og vidensniveau, hvilket giver mulighed for forskellige indsigter i forhold til ethvert problem, de identificerer. De to testere deler den samme opsætning og deler også arbejdet med at teste og dokumentere alle observationer mellem dem. Denne testmetode gør det også muligt for den ene tester at udføre testene, mens den anden kan tage noter om resultaterne.

Læs også: Brug partest til bedre accepttestning

Buddy vs. partestning

Den vigtigste forskel mellem buddy-testning og partestning er, at buddy-testning er en kombination af enheds- og systemtestning. En anden vigtig forskel er, at buddy testing udføres af udviklere og testere sammen. Partestning udføres derimod kun af testere, der har forskellige vidensniveauer.

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

Ad hoc-testning udføres almindeligvis, når der er mangel på tid til at udføre længere og mere udtømmende testprocesser. Den mere grundige testmetode omfatter udarbejdelse af testkravsdokumenter, testcases og design af testcases.

Det ideelle tidspunkt til at udføre ad hoc-testning er efter afslutningen af alle formelle testteknikker. Ad hoc-testning kan dog også udføres midt i softwareudviklingen, efter den komplette udvikling af softwaren, eller efter at nogle få moduler allerede er udviklet.

Det er vigtigt at være opmærksom på de få scenarier, hvor ad hoc-testning ikke anbefales. Nogle få forhold, hvor ad hoc-testning ikke bør udføres, omfatter:

Når der udføres betatestning

I testcases, der allerede har eksisterende fejl

Fordele ved ad hoc-testning

En af de vigtigste fordele ved ad hoc-testning er, at den er i stand til at identificere eventuelle fejl, der normalt ville gå ubemærket hen under formelle testmetoder. Dette kan spare meget tid, da det ikke kræver nogen af den planlægning, som struktureret testning gør.

En anden fordel er, at testerne får mulighed for at udforske applikationen frit i henhold til deres egen viden og forståelse af applikationen. De kan derefter udføre forskellige tests undervejs, hvilket hjælper med at identificere fejl undervejs i processen.

For det tredje kan testere og udviklere af applikationen nemt selv teste appen, da det ikke kræver testcases. Dette giver udviklerne mulighed for nemt at skabe mere effektiv og fejlfri kode.

Ad hoc-testning kan også kombineres med andre testteknikker og udføres derefter for at give mere effektive og informative resultater i det hele taget.

Ulemper ved ad hoc-testning

En af de største ulemper ved ad hoc-testning er, at selve testprocessen ikke er dokumenteret, da den ikke følger en bestemt testcase. Dette gør det vanskeligere for testene at regenerere en fejl. For for at få den pågældende fejl skal testeren huske de nøjagtige trin, han/hun tog for at nå dertil, hvilket ikke altid er muligt.

Fordelvis rapporteres der ugyldige fejl som følge af ugyldige testcases, der er udviklet af testeren. Dette kan blive et problem i de følgende fejlrettelsesprocesser. Hvis testeren ikke har forudgående viden om funktionaliteten af den applikation, der testes, vil ad hoc-testning ikke være nyttig og vil ikke kunne identificere fejl.

Ad hoc-testning garanterer heller ikke, at alle fejl vil blive fundet. Succesen af ad hoc-testning afhænger af testerens færdigheder og viden. Da der ikke på forhånd er oprettet eller dokumenteret testcases, er det ikke fastlagt, hvor meget tid, kræfter og ressourcer der går til disse tests. Det kan tage alt fra et par minutter til et par timer eller mere at finde en enkelt fejl.

Best Practices When Conducting The Testing

Tests, der ikke udføres på den rigtige måde, kan medføre unødvendigt tidsspilde. Med dette in mente er det afgørende at vide, hvordan man kan optimere processen for effektivt at udføre succesfulde ad hoc-tests.

Følgende bedste praksis vil sikre, at den tid, der bruges under processen, bruges fornuftigt med den bedste chance for at opnå de ønskede resultater.

Vær fortrolig med softwaren

Det er bydende nødvendigt, at testeren, der udfører ad hoc-testen, har solid viden om og greb om applikationen. Det er vigtigt, at testeren er fortrolig med alle de vigtigste funktioner i applikationen for at sikre bedre “fejlgætning”. Med den rette viden vil testeren være i stand til at finde flere fejl, fejl og generelle uoverensstemmelser.

Identificer områder, der sandsynligvis vil indeholde fejl

Hvis testerne ikke er bekendt med applikationen, anbefales det, at de identificerer de fejlbehæftede områder i applikationerne og begynder derfra. Ved at vælge følsomme områder til ad hoc-testning vil testerne lettere kunne finde fejl.

Prioriter områder, som slutbrugeren har lettest adgang til

Start med at teste de områder af applikationen, der bruges mest af kunderne og slutbrugerne. På den måde vil de vurdere de vigtige funktioner først, hvilket gør det muligt for dem at rapportere eventuelle fejl på forhånd.

Løs formulering af testplanen

Selv om ad hoc-testning ikke kræver nogen forudgående planlægning eller dokumentation, er det nyttigt at lave en grov planlægning på forhånd. Ved at notere sig de vigtigste områder, der skal testes, kan testeren få hjælp til at dække så meget som muligt på kortest mulig tid.

Øg effektiviteten med de rigtige værktøjer

Det er afgørende at bruge de rigtige værktøjer, såsom task monitors, debuggere og profilers, for at sikre, at processen kører effektivt. De supplerer testernes evne til at isolere fejl, da der kan være tilfælde, hvor undtagelser ikke identificeres under testningen.

Slutning

Ad hoc-testning kræver ikke udførlig planlægning, dokumentation og design af testcases. I stedet sparer den tid på grund af sin ad hoc-natur og ved at vælge testere, der er kreative og har forudgående kendskab til applikationens funktionalitet. Denne testning kan være med til at finde flere fejl end planlagt testning.

Gå med i 60.000+ abonnenter

For seneste blogs, opdateringer fra branchen og eksklusive tips.

*Din e-mail er sikker hos os, vi hader også spam