Adhoc-testning utförs vanligtvis för att bryta sönder systemet och på okonventionella sätt. Det mest häpnadsväckande med Adhoc-testning är att den inte har någon testdesignteknik för att skapa testfall.

Processen utförs vanligtvis för att hitta kryphål i en programvara. Eftersom Adhoc-testning inte har testfall utförs den ofta utan någon dokumentation.

Se processen i detalj

Adhoc-testning är en teknik som faller under kategorin ”ostrukturerad testning”.

Vad är strukturerad och ostrukturerad testning?

Strukturerad testning

I detta tillvägagångssätt är varje aktivitet som sker under testproceduren, från skapandet av testfall till deras sekventiella utförande, allt är skriptat. Testarna följer detta skript för att utföra testerna enligt det.

Ostrukturerad testning

I detta tillvägagångssätt sker testning vanligen genom felgissning, där testarna skapar testfallen, under själva testprocessen.

Vad är ad hoc-testning?

Som diskuterats ovan är det en typ av ostrukturerad testmetod, där ingen organiserad plan skapas innan testprocessen påbörjas.

Därmed görs ingen kravdokumentation eller planering och utformning av testfall före testningen.

Ad-hoc-testning utförs vanligtvis av en testare som har en stark kunskap om den testade programvaran, om vad den gör och hur den fungerar.

Denna testning görs genom att slumpmässigt skapa testfall genom att gissa sig fram till fel och utföra dem, utan att följa några krav för testet.

En stor del av denna testning är att ta reda på potentiella områden i programvaran, där fel kan förekomma.

Det är därför som den också ibland kallas Monkey Testing eller Random Testing. Därför är det viktigt att endast de testare som har god kännedom om programvaran utför detta test.

En fördel med Ad-Hoc-testning är att den sparar ganska mycket tid, som annars går åt till att skapa dokument som testkrav, planering av testfall, utformning etc.

Den utförs också i allmänhet efter att den strukturerade testningen redan har utförts. Detta görs för att hitta ovanliga brister i programvaran som inte kunde upptäckas genom att följa de tidigare skrivna testfallen.

Typer av ad hoc-testning

1) Buddy Testing

I denna typ av ad hoc-testning utförs testerna med lagarbete av minst två personer. Detta team består vanligtvis av minst en mjukvarutestare och en mjukvaruutvecklare.

Denna typ av testning äger rum efter att utförandet av enhetstestning av en modul har slutförts.

Teamet bestående av de två ”kompisarna” arbetar tillsammans med den modulen för att skapa giltiga testfall.

Detta görs så att testaren inte slutar med att rapportera fel som genererats genom ogiltiga testfall. Denna typ av testning kan också betraktas som en kombination av både enhets- och systemtestning.

2) Monkey Testing

Det slumpmässiga tillvägagångssättet som används i denna testning är anledningen till att den benämns som ”monkey testing”.

Här förses programvaran som testas med slumpmässiga indata, för vilka motsvarande utdata observeras.

På grundval av de erhållna utdata bestäms eventuell förekomst av fel, inkonsekvenser eller systemkrascher.

3) Partestning

Denna testning påminner mycket om kompisstestning. Här arbetar dock ett par av endast testarna tillsammans med de moduler som ska testas.

De arbetar tillsammans för att dela idéer, åsikter och kunskap om samma maskin för att identifiera fel och brister.

Testarna paras ihop enligt deras kunskapsnivåer och expertis, för att få en annan inblick i ett problem.

Karaktäristika för ad hoc-testning

• Denna testning görs efter att formella testtekniker redan har utförts på programvaran. Anledningen till detta är att ad hoc-tester görs för att ta reda på anomalier i applikationen, som inte kan förutsägas före testningen.
• Denna testning kan endast utföras av de testare som har en god och grundlig kunskap om hur applikationen fungerar. Detta beror på att effektiv ”felgissning” endast kan göras när testaren vet vad programmet gör och hur det fungerar.

Tekniken för ad hoc-testning lämpar sig bäst för att hitta fel och inkonsekvenser som ger upphov till kritiska kryphål i ett program. Sådana fel är vanligtvis mycket svåra att avslöja. Denna testning tar jämförelsevis mindre tid än andra testmetoder. Detta beror på att den utförs utan föregående planering, utformning och strukturering.

• Ad-hoc-testning utförs endast en gång, eftersom eventuella fel som upptäcks måste testas på nytt.

Exempel på Adhoc-testning

• Testning för att se om en applikation fungerar korrekt när webbläsarinställningarna är olika. Till exempel identifiering av fel som uppstår när alternativet för JavaScript är inaktiverat i olika webbläsare osv.
• Testning av applikationen på olika plattformar. Det är viktigt att kontrollera om den utvecklade applikationen kan köras flytande i olika operativsystem eller webbläsare.
• Förmedla inmatningar till systemet som ligger utanför intervallet för giltiga inmatningar, för att kontrollera om den resulterande åtgärden som vidtas av applikationen är lämplig eller inte.

Kopiera applikationens webbadress och manipulera den så att den kan köras i en annan webbläsare. Detta görs för att säkerställa att obehöriga användare inte kan få obehörig åtkomst till systemet.

• Gå igenom en serie slumpmässiga steg eller navigera slumpmässigt genom programmet för att kontrollera de resultat som erhålls genom att gå igenom en viss kombination av ovanliga inmatningar.

När man utför ad hoc-testning

I vanliga fall utförs ad hoc-testning när det inte finns tillräckligt med tid för att utföra uttömmande och grundlig testning, vilket inkluderar att förbereda testkravsdokument, testfall och design av testfall.

Den perfekta tidpunkten för att genomföra denna typ av testning är efter det att de formella testmetoderna har slutförts.

Hursomhelst kan ad-hoc-tester också genomföras mitt under utvecklingen av programvaran.

Det kan utföras efter att programvaran har utvecklats helt och hållet, eller till och med efter att några moduler har utvecklats.

Det kan också utföras under processen med formella testmetoder också.

Det finns några få situationer där denna typ av testning dock inte får utföras. Därför måste varje testare veta när denna testning ska undvikas.

Nedan anges några förhållanden när ad hoc-testning inte får utföras:

• Ad hoc-testning får inte utföras när betatestning utförs. Detta beror på att betatestning involverar kunderna, som testar den utvecklade programvaran för att ge förslag på nya funktioner som behöver läggas till eller för att ändra kraven för den.

Denna testning rekommenderas också att inte utföras i de testfall som redan har befintliga fel i dem. Felen måste först dokumenteras ordentligt innan de tas bort från systemet. När de är åtgärdade måste testfallen testas på nytt för att säkerställa att de fungerar korrekt.

Vad är fördelarna med ad hoc-testning?

En fördel med ad hoc-testning är att många fel, som vanligtvis inte upptäcks när endast formella testmetoder används, kan hittas genom att slumpmässigt testa applikationen. Testarna får möjlighet att utforska applikationen fritt, i enlighet med sin intuition och förståelse av applikationen. De kan sedan utföra testerna efter hand, vilket hjälper dem att hitta fel under denna process. Testare såväl som utvecklare av applikationen kan enkelt testa applikationen, eftersom inga testfall behöver planeras och utformas. Detta hjälper utvecklarna att enkelt generera effektivare och felfria koder.
• Denna testning kan också hjälpa till att skapa unika testfall som ineffektivt kan upptäcka fel. Därför kan sådana testfall läggas till den formella testningen tillsammans med andra planerade testfall.
• Ad-hoc-testning kan utföras när som helst under programvaruutvecklingens livscykel eftersom den inte följer någon formell process.
• Det kan kombineras med andra testmetoder och utföras för att ge mer informativa och effektiva resultat.

Vad är nackdelarna med ad hoc-testning?

• Då testprocessen inte är dokumenterad och inget särskilt testfall följs, blir det mycket svårt för testaren att återskapa ett fel. Detta beror på att testaren måste komma ihåg exakt vilka steg han följde för att få fram felet, vilket inte är möjligt varje gång.
• Ibland rapporteras ogiltiga fel på grund av att testaren utför ogiltiga testfall som slumpmässigt utvecklats av testaren, vilket blir ett problem i de efterföljande processerna för felrättning.
• Om testarna inte har förkunskaper om hur den testade applikationen fungerar, kommer ad hoc-testerna inte att kunna avslöja många fel. Detta beror på att testarna måste arbeta sig igenom felgissningar och intuitivt skapa och utföra testfall på plats.

Ad-hoc-testning ger ingen garanti för att fel kommer att upptäckas. Proaktiv felgissning för testning är helt beroende av testarens skicklighet och kunskap.

• Då det inte finns några tidigare skapade och dokumenterade testfall förblir mängden tid och arbete som går åt till denna testning osäkert. Ibland kan det ta enormt mycket tid att hitta även ett enda fel.

Bästa metoder för att genomföra Ad-hoc-testning

För att effektivt genomföra Ad-hoc-testningstekniken är det viktigt att känna till de mest effektiva och ändamålsenliga sätten att göra det på.

Det här beror på att om testerna inte genomförs på ett korrekt sätt kommer den ansträngning och den tid som läggs ner på testerna att vara bortkastad.

För att genomföra denna typ av testning måste man därför känna till de bästa metoderna som kan hjälpa till med ett mer heltäckande tillvägagångssätt för testning:

1) Goda programvarukunskaper

Säkerställ att testaren som tilldelas testningen av applikationen genom ad hoc-metoden har ett bra grepp om applikationen.

Testaren måste känna till alla funktioner i applikationen för att underlätta bättre ”felgissning” på applikationen.

Med tillräcklig kunskap som stöd för testarens testprocess blir det lättare att hitta fler fel, buggar och inkonsekvenser.

2) Ta reda på felprioriterade områden

Om testare, hur inte är bekanta med applikationen, så är den bästa metoden för dem att börja sin testprocess att kontrollera den del av applikationen där majoriteten av felen finns.

Att välja sådana känsliga områden för att utföra ad hoc-tester kan hjälpa dem att lättare hitta fel.

3) Prioritera testområden

Det är alltid bättre att börja testa från de områden i applikationen som används mest av slutanvändarna eller kunderna. Detta hjälper till att säkra de viktiga funktionerna och rapportera eventuella fel i förväg.

4) Planera testplanen i grova drag

Tyvärr kräver ad hoc-testning ingen föregående planering eller dokumentation, men den visar sig vara mycket användbar och effektiv om en grov plan skapas i förväg.

Enbart genom att notera de viktigaste pekpinnarna och de områden som kräver testning kan testarna få hjälp med att täcka in största möjliga del av applikationen på kort tid.

5) Verktyg

Det är viktigt att använda sig av rätt sorts verktyg som felsökare, taskmonitorer och profilerare för att underlätta testningen.

Detta beror på att det finns tillfällen då specifika buggar och undantag inte kan ses och inte fångas upp under testningen.

Hursomhelst kan användningen av rätt verktyg hjälpa till att isolera felet på bara en kort tid.

Adhoc-testning vs. utforskande testning

Adhoc-testning	Utforskande testning
Testare måste ha en klar uppfattning om applikationens arbetsflöde	Testare lär sig om. programmet i farten
Mer om att finslipa testprocessen	Det är en inlärningsmetod för att känna till programmet
En form av positiv testning	En form av negativ systemtestning
Det finns ingen plan	En charterbaserad plan kommer att användas
Det finns ingen föreslagen tidsgräns	Tidsramar/teckenvektor
Kan utföras av mjukvarutestingenjören	Måste vara utföras av experten
Fokus ligger på ansökningsprocessen	Datainsamlingsområden kommer att vara huvudfokus
Testkomplexiteten kommer inte att störa mycket i den här processen	Utmaningar i samband med detta