Planering av ad hoc-testning

I den här artikeln har vi behandlat ad hoc-testning, dess typer, fördelar, nackdelar och de bästa metoderna för att genomföra ad hoc-testning.

Vad är ad hoc-testning?

Ad hoc-testning, ibland kallad ”slumpmässigt testande” eller ”aptestning”, definieras som en informell testtyp. Syftet med denna process är att bryta systemet med hjälp av okonventionella metoder. Denna typ av programvarutestning är i allmänhet oplanerad och följer ingen specifik testdesignteknik för att skapa testfall.

Det huvudsakliga syftet med ad hoc-testning är att hitta eventuella defekter genom slumpmässig kontroll. Testaren improviserar stegen genom att godtyckligt utföra dem. Detta kan avslöja mycket specifika och intressanta defekter som lätt missas när andra metoder används.

Den mest överraskande aspekten av ad hoc-testning är att den inte omfattar några testdesigntekniker. Detta innebär att även om denna metod hittar fel som kanske inte brukar hittas är den svårare att reproducera, eftersom det inte finns några skrivna testfall eller någon dokumentation.

För att lyckas med ad hoc-testning krävs verkligen testarens kreativitet och uthållighet och ibland beror det bara på ren tur. Ad hoc-testningstekniken faller direkt under kategorin ”ostrukturerad testning”.

Strukturerad vs. ostrukturerad testning

Strukturerad testning

Detta tillvägagångssätt säkerställer att varje aktivitet som äger rum under testningsförfarandet är skriptat, från skapandet av testfall till sekventiellt utförande. Testaren följer skriptet för att framgångsrikt genomföra testerna.

Ostrukturerad testning

Detta tillvägagångssätt innebär testning genom felgissning. Testaren skapar testfall under testprocessen.

Typer av ad hoc-testmetoder

Buddy Testing

Denna typ av ad hoc-testning utförs med minst två personer. Den äger rum efter att enhetstestning av en modul har utförts och slutförts. Denna typ av testning kan också betraktas som en kombination av både systemtestning och enhetstestning.

Det huvudsakliga syftet är att två ”kompisar” ska arbeta med att identifiera defekter eller buggar i samma modul samtidigt. Teamet består vanligtvis av en mjukvaruutvecklare och en mjukvarutestare.

De två ”kompisarna” arbetar tillsammans med den modulen för att skapa giltiga testfall. Denna process säkerställer att testaren inte rapporterar fel som ogiltiga testfall kan ha genererat.

Buddy testing har visat sig vara framgångsrikt eftersom det hjälper testaren att utveckla bättre testfall och gör det möjligt för utvecklingsteamet att göra konstruktionsändringar så tidigt som möjligt.

Monkey Testing

På grund av testningens slumpmässiga karaktär har denna metod fått namnet ”monkey testing”. Monkey testing görs oftast på enhetstestningsnivån. Här testar testarna slumpmässigt applikationen eller produkten utan testfall. Testarens huvudmål är att analysera data eller tester på helt slumpmässiga sätt och se till att systemet klarar av en eventuell krasch.

Testare förser programvaran med slumpmässiga indata och observerar motsvarande utdata. Baserat på utdata kan de bättre fastställa eventuella fel, inkonsekvenser eller systemkrascher.

Par testning

Som på sätt och vis liknar ”kompis testning” innebär ”par testning” att ett par testare arbetar tillsammans med de moduler som ska testas. De två testarna delar idéer, kunskap och åsikter om samma maskin för att identifiera defekter eller fel.

Denna testmetod innebär att man använder testare som paras ihop enligt deras expertis- och kunskapsnivåer, vilket möjliggör olika insikter om eventuella problem som de identifierar. De två testarna delar samma uppställning och delar också på arbetet med att testa och dokumentera alla observationer mellan dem. Denna testmetod gör det också möjligt för den ena testaren att utföra testerna, medan den andra kan föra anteckningar om resultaten.

Även läs: Använd partestning för bättre acceptanstestning

Buddy vs. partestning

Den största skillnaden mellan buddy-testning och partestning är att buddy-testning är en kombination av enhets- och systemtestning. En annan viktig skillnad är att buddy testing utförs av utvecklare och testare tillsammans. Partestning däremot utförs endast av testare som har olika kunskapsnivåer.

När och när man inte ska utföra ad hoc-testning

Ad hoc-testning utförs vanligen när det saknas tid för att utföra längre och mer uttömmande testprocesser. Den mer grundliga testmetoden omfattar utarbetande av testkravsdokument, testfall och design av testfall.

Den idealiska tidpunkten för att utföra ad hoc-testning är efter det att alla formella testmetoder har slutförts. Ad hoc-testning kan dock också utföras mitt i programvaruutvecklingen, efter att programvaran har utvecklats helt eller efter att några moduler redan har utvecklats.

Det är viktigt att notera de få scenarier när ad hoc-testning inte rekommenderas. Några förhållanden när ad hoc-testning inte bör utföras är:

När betatestning utförs

I testfall som redan har existerande fel

Fördelar med ad hoc-testning

En av de viktigaste fördelarna med ad hoc-testning är att den kan identifiera eventuella fel som vanligtvis skulle gå obemärkt förbi under formella testmetoder. Detta kan spara mycket tid eftersom det inte kräver någon av den planering som strukturerad testning gör.

En annan fördel är att testarna får utforska applikationen fritt, enligt sin egen kunskap och förståelse av applikationen. De kan sedan utföra olika tester efter hand, vilket hjälper dem att identifiera fel under hela processen.

För det tredje kan testare och utvecklare av applikationen enkelt testa applikationen själva, eftersom den inte kräver testfall. Detta gör att utvecklarna enkelt kan skapa effektivare och felfri kod.

Ad hoc-testning kan också kombineras med andra testtekniker och utföras därefter för att ge mer effektiva och informativa resultat totalt sett.

Nackdelar med ad hoc-testning

En av de största nackdelarna med ad hoc-testning är att själva testprocessen inte är dokumenterad eftersom den inte följer ett visst testfall. Detta gör det svårare för testerna att återskapa ett fel. För för att få fram det felet måste testaren komma ihåg de exakta stegen han/hon tog för att komma dit, vilket inte alltid är möjligt.

Enstaka gånger rapporteras ogiltiga fel som ett resultat av ogiltiga testfall som utvecklas av testaren. Detta kan bli ett problem i följande felrättningsprocesser. Om testaren inte har någon förhandskunskap om funktionaliteten hos den applikation som testas kommer ad hoc-testning inte att vara användbar och kommer inte att kunna identifiera några fel.

Ad hoc-testning garanterar inte heller att alla fel kommer att hittas. Framgången med ad hoc-testning beror på testarens skicklighet och kunskap. Eftersom det inte finns några tidigare skapade eller dokumenterade testfall, förblir mängden tid, arbete och resurser som går åt till dessa tester ospecificerade. Att hitta ett fel kan ta allt från några minuter till några timmar eller längre.

Bästa metoder när testningen genomförs

Tester som inte genomförs på rätt sätt kan orsaka onödigt tidsspill. Med detta i åtanke är det avgörande att veta hur man optimerar processen för att effektivt utföra framgångsrika ad hoc-tester.

Med hjälp av följande bästa praxis kan man se till att den tid som spenderas under processen spenderas på ett klokt sätt med bästa möjliga chans att uppnå önskade resultat.

Var väl förtrogen med programvaran

Det är absolut nödvändigt att den testare som utför ad hoc-testerna har gedigen kunskap och grepp om applikationen. Det är viktigt att testaren är bekant med alla huvudfunktioner i applikationen för att säkerställa bättre ”felgissning”. Med rätt kunskap kommer testaren att kunna hitta fler buggar, fel och allmänna inkonsekvenser.

Identifiera områden som sannolikt har fel

Om testarna inte är bekanta med applikationen rekommenderas det att de identifierar de felbenägna områdena i applikationerna och börjar därifrån. Genom att välja känsliga områden för att utföra ad hoc-tester kan testarna lättare hitta fel.

Prioritera områden som slutanvändaren kommer åt lättast

Börja med att testa de områden i applikationen som används mest av kunderna och slutanvändarna. På så sätt kommer de att bedöma de viktiga funktionerna först, vilket gör det möjligt för dem att rapportera eventuella fel i förväg.

Formulera testplanen i detalj

Samtidigt som ad hoc-testning inte kräver någon föregående planering eller dokumentation, är det användbart att göra en grov planering i förväg. Genom att notera de viktigaste områdena som kräver testning kan testaren hjälpa testaren att täcka in så mycket som möjligt på kortast möjliga tid.

Öka effektiviteten med rätt verktyg

Det är viktigt att använda rätt verktyg, t.ex. uppgiftsövervakare, felsökare och profilerare, för att se till att processen löper effektivt. De kompletterar testarnas förmåga att isolera fel, eftersom det kan finnas fall där undantag inte identifieras under testningen.

Slutsats

Ad hoc-testning kräver inte genomarbetad planering, dokumentation och testfallsdesign. Istället sparar den tid på grund av sin ad hoc-natur och genom att välja testare som är kreativa och har tidigare kunskap om applikationens funktionalitet. Denna testning kan hjälpa till att hitta fler defekter än planerad testning.

Gå med i 60 000+ prenumeranter

För de senaste bloggarna, branschuppdateringar och exklusiva tips.

*Din e-post är säker hos oss, vi hatar också spam