fbpx

Get your 6-month No-Cost Opt-Out offer for Unlimited Software Automation?

 

Ad hoc-testning är en typ av programvarutestning som utvecklare och programvaruföretag genomför när de kontrollerar programvarans aktuella iteration. Denna form av testning ger en större insikt i programmet och lokaliserar problem som konventionell testning kanske inte kan belysa.

Det är av största vikt att testteamen har en fullständig förståelse för ad hoc-testningsprocessen så att de vet hur de ska kringgå dess utmaningar och se till att teamet kan implementera den här tekniken på ett framgångsrikt sätt.

Genom att veta exakt hur ad hoc-testning fungerar och vilka verktyg som kan underlätta genomförandet kan ett företag kontinuerligt förbättra sina egna kvalitetssäkringsrutiner. Den formella testprocessen följer mycket specifika regler, vilket kan leda till att teamet missar vissa fel – ad hoc-kontroller kan kringgå dessa blinda fläckar och snabbt testa varje programvarufunktion.

 

I den här artikeln tittar vi närmare på ad hoc-testning och hur du kan använda den till din fördel när du utvecklar en mjukvaruprodukt.

 

Table of Contents

Ad hoc-testning Betydelse: Vad är Ad-Hoc Testing?

checklista uat, verktyg för testning av webbapplikationer, automatisering med mera

Ad hoc-testning är en kvalitetssäkringsprocess som undviker formella regler och dokumentation och hjälper testarna att hitta fel i sina applikationer som konventionella metoder inte kan identifiera. Detta kräver vanligtvis omfattande kunskaper om programvaran innan testningen börjar – inklusive en förståelse för programmets inre arbete. Dessa ad hoc-kontroller syftar till att bryta programmet på ett sätt som återspeglar användarinmatningen, och att ta hänsyn till olika potentiella situationer så att utvecklarna kan åtgärda eventuella problem.

Bristen på dokumentation är central för denna teknik, som inte innehåller någon checklista eller testfall för att vägleda testarna genom en applikations funktioner. Ad hoc-testning handlar helt och hållet om att testa programvaran på det sätt som teamet bestämmer sig för är effektivt vid det specifika tillfället. Detta kan ske med hänsyn till redan existerande formella tester, men kan också helt enkelt innebära att man genomför så många tester som möjligt under den (sannolikt begränsade) tid som avsätts för denna teknik.

 

1. När och varför behöver du göra ad hoc-testning i programvarutestning?

Fördelar med att inrätta ett kompetenscentrum för testning. Är prestandatestning annorlunda än funktionell testning?

Den främsta anledningen till att företag genomför ad hoc-tester är att de kan avslöja fel som traditionella metoder inte kan hitta. Det kan bero på många olika orsaker, t.ex. att konventionella testfall följer en särskilt standardiserad process som inte kan ta hänsyn till en applikations egenheter.

Varje testtyp kan erbjuda nya perspektiv och intressanta metoder för kvalitetssäkring – detta visar också på problem med den vanliga teststrategin. Om ad hoc-testning till exempel kan identifiera ett problem som teamets testfall inte tar itu med, tyder det på att de kan dra nytta av att omkalibrera sin testmetodik.

Testare kan utföra ad hoc-kontroller när som helst under testprocessen. Detta fungerar vanligtvis som ett komplement till traditionell (och mer formell) kvalitetssäkring, och med detta i åtanke kan testare utföra ad hoc-inspektioner medan deras kollegor utför mer formella undersökningar. Men de kanske föredrar att spara ad hoc-kontroller till efter den formella testprocessen som en uppföljning som specifikt riktar sig mot potentiella blinda punkter.

Ad hoc-testning kan också vara användbart när tiden är särskilt begränsad på grund av bristen på dokumentation – rätt tidpunkt beror på företaget och dess föredragna tillvägagångssätt.

 

2. När du inte behöver göra ad hoc-testning

Fördelar med att inrätta ett kompetenscentrum för testning. Är prestandatestning annorlunda än funktionell testning?

Om det inte finns tillräckligt med tid för att utföra både ad hoc-tester och formella tester är det viktigt att teamet prioriterar det senare eftersom det garanterar en omfattande testtäckning – även om det fortfarande finns vissa luckor.

Om teamets formella tester hittar fel som måste åtgärdas är det i allmänhet bättre att vänta med ad hoc-kontroller tills utvecklarna har genomfört de nödvändiga ändringarna. Annars kan resultaten som de levererar snabbt bli inaktuella, särskilt om testerna gäller en komponent som redan har fel.

Dessutom måste ad hoc-testning ske före betatestningsfasen.

 

3. Vem är inblandad i ad hoc-testning?

som bör arbeta med verktyg och planering för automatisering av programvarutestning

Det finns flera nyckelroller som är involverade i Ad-Hoc-testningsprocessen, bland annat:

– Mjukvarutestare är de viktigaste medlemmarna i teamet som utför ad hoc-kontroller. Om du genomför kompis- eller partestning kommer flera av dessa testare att arbeta tillsammans med samma komponenter.

– Utvecklare kan självständigt använda dessa kontroller före det formella kvalitetssäkringssteget för att snabbt inspektera sin egen programvara, även om detta är mindre djupgående än dedikerad ad hoc-testning.

– Grupp- eller avdelningsledare godkänner den övergripande teststrategin och hjälper testarna att avgöra när de ska börja med ad hoc-testning och hur de ska utföra den utan att störa andra kontroller.

 

Fördelar med ad hoc-testning

Zaptest, det bästa automatiseringsverktyget för funktionell testning

Fördelarna med ad hoc-testning i programvarutestning är bland annat:

 

1. Snabba lösningar

 

Eftersom dessa tester inte kräver frekvent dokumentation före, under eller efter kontrollerna kan teamet identifiera problem mycket snabbare. Denna enkelhet ger testarna en enorm frihet.

Om de t.ex. testar en komponent och inte kan identifiera några fel kan teamet helt enkelt gå vidare till nästa test utan att notera detta i ett dokument.

 

2. Kompletterar andra testtyper.

 

Ingen teststrategi är perfekt, och 100 % täckning är oftast omöjligt att uppnå – även med ett omfattande schema. Det kommer alltid att finnas luckor i konventionella tester, så det är viktigt att företagen integrerar flera metoder.

Ad hoc-testning syftar särskilt till att hitta de problem som formell testning inte kan täcka – vilket garanterar en bredare övergripande testtäckning.

 

3. Flexibelt genomförande

 

Ad hoc-testning kan ske när som helst i kvalitetssäkringsprocessen före betatestning, vilket gör att företag och team kan bestämma när det är bäst att utföra dessa kontroller. De kan välja att utföra ad hoc-tester parallellt med konventionella tester eller vänta till efteråt – oavsett vad som händer drar teamet nytta av de valmöjligheter som står till deras förfogande.

 

4. Bättre samarbete

 

Utvecklarna är mer involverade i den här processen än i många andra former av testning – särskilt om företaget använder sig av kompis- och partestning.

Som ett resultat får utvecklarna bättre insikt i sina egna applikationer och kan kanske åtgärda fel i högre grad. Detta bidrar till att förbättra programvarans övergripande kvalitet ytterligare.

 

5. Olika perspektiv

 

Ad hoc-testning kan visa applikationen från nya vinklar och hjälpa testarna att ta del av funktionerna på nya sätt. Ytterligare perspektiv är viktiga under hela testningen eftersom formella kontroller ofta har åtminstone mindre luckor.

Om ad hoc-testare använder programvaran med det specifika syftet att bryta den kan de lättare identifiera programmets begränsningar.

 

Utmaningar med ad hoc-testning

Utmaningar för belastningstestning.

Ad hoc-testningsprocessen har också flera utmaningar, t.ex:

 

1. Svårigheter att rapportera

 

Bristen på dokumentation gör ad hoc-tester mycket snabbare, men kan också göra det svårt att rapportera om det inte rör sig om ett stort problem.

Till exempel kan en tidigare utförd kontroll bli mer relevant vid ett senare tillfälle, trots att den ursprungligen inte gav några betydande resultat. Utan omfattande dokumentation kanske teamet inte kan förklara dessa tester.

 

2. Mindre upprepningsbara

 

På samma sätt kanske testarna inte är helt medvetna om det exakta tillstånd som krävs för att orsaka de reaktioner de observerar. En ad hoc-kontroll som ger ett fel kanske inte innehåller tillräckligt med information för att teamet ska kunna vidta åtgärder. De kanske inte vet hur de ska upprepa testet för att få samma resultat.

 

3. Kräver erfarenhet av programvara

 

Eftersom snabbhet är nyckeln till ad hoc-testning och det oftast handlar om att försöka bryta programmet, är det viktigt att dessa testare har en ingående förståelse för programmet.

Genom att veta hur den fungerar kan testarna bryta sönder och manipulera programvaran på fler sätt, men detta kan avsevärt öka kraven på färdigheter för ad hoc-testning.

 

4. Begränsad ansvarsskyldighet

 

Bristande dokumentation kan orsaka fler problem än bara dålig rapportering; den kan också oavsiktligt förlänga testprocessen och påverka användbarheten av snabba individuella ad hoc-tester.

Testare kan ha svårt att hålla reda på sina framsteg om de inte har tillräcklig dokumentation under varje steg. Detta kan till och med leda till att de upprepar en kontroll som andra testare redan har utfört.

 

5. Kan inte återspegla användarens upplevelse.

 

Syftet med praktiskt taget alla testtyper är att ta hänsyn till fel som påverkar slutanvändarna på något sätt. Ad hoc-testning bygger främst på att en erfaren testare försöker efterlikna en oerfaren användare, och detta bör vara konsekvent vid varje kontroll, inklusive deras försök att bryta programmet.

 

Egenskaper hos ad hoc-tester

testning och automatisering av api

De viktigaste kännetecknen för framgångsrika ad hoc-tester är följande:

 

1. Utredning

 

Huvudprioriteten för ad hoc-testning är att identifiera fel i applikationen med hjälp av tekniker som konventionella kontroller inte tar hänsyn till. Ad hoc-undersökningar genomsöker programvaran med det uttalade syftet att hitta luckor i teamets testförfarande, inklusive täckningen av deras testfall.

 

2. Ostrukturerad

 

Ad hoc-kontroller har vanligtvis ingen fastställd plan utöver att utföra så många tester som möjligt utanför de typiska gränserna för formell kvalitetssäkring. Testare grupperar vanligtvis kontrollerna efter komponent för att underlätta, men det är inte nödvändigt – de kan till och med tänka ut kontrollerna medan de utför dem.

 

3. Erfarenhetsbaserad

 

Ad-hoc-testare använder sin tidigare erfarenhet av programvara för att bedöma vilka tester som skulle ge mest nytta och åtgärda vanliga blinda fläckar i formell testning.

Även om testprocessen fortfarande är helt ostrukturerad tillämpar testarna sina kunskaper om tidigare ad hoc-kontroller när de bestämmer sin strategi.

 

4. Ett brett spektrum

 

Det finns inga exakta riktlinjer för vilka kontroller teamet bör göra under ad hoc-testerna, men de täcker vanligtvis en rad olika komponenter – eventuellt med mer fokus på applikationens känsliga aspekter. Detta hjälper testarna att garantera att deras undersökningar kan komplettera formell testning fullt ut.

 

Vad testar vi i ad hoc-tester?

Testning från början till slut - Vad är E2E-testning, verktyg, typer med mera

Kvalitetssäkringsteam testar vanligtvis följande under ad hoc-testning:

 

1. Programvarukvalitet

 

Dessa kontroller syftar till att identifiera fel i applikationen som konventionell testning inte kan avslöja, vilket innebär att processen främst testar applikationens allmänna hälsa.

Ju fler fel som kan upptäckas genom ad hoc-testning, desto fler förbättringar kan utvecklarna genomföra innan tidsfristen löper ut.

 

2. Testfall

 

Vid ad hoc-testning implementeras i allmänhet inga testfall – och det är just för att teamet ska kunna undersöka hur effektiva de är när det gäller att ge tillräcklig täckning. Testfallen är sannolikt otillräckliga om ad hoc-kontroller kan hitta fel som konventionella testprocesser inte kan hitta.

 

3. Testpersonal

 

Målet kan också vara att kontrollera testgruppens färdigheter och kunskaper, även om testfallen är tillräckliga. Till exempel kan deras metodik för att genomföra fallen vara otillräcklig och ad hoc-testning kan vara avgörande för att åtgärda de resulterande luckorna i testtäckningen.

 

4. Begränsningar för programvara

 

Ad hoc-testning syftar också till att förstå applikationens begränsningar – t.ex. hur den reagerar på oväntade inmatningar eller hög systembelastning. Testarna kan särskilt undersöka programmets felmeddelanden och hur väl programmet fungerar när det är under stort tryck.

 

För att reda ut en viss förvirring:

Ad hoc-testning och utforskande testning

Jämförelse mellan UAT-testning och regressionstestning och annan testning.

En del människor anser att ad hoc- och utforskande testning är synonyma, men sanningen är mer komplicerad än så.

 

1. Vad är utforskande testning?

Fördelar med att inrätta ett kompetenscentrum för testning. Är prestandatestning annorlunda än funktionell testning?

Utforskande testning avser kvalitetssäkringsförfaranden som undersöker programvaran ur en holistisk synvinkel och som särskilt kombinerar upptäckts- och testprocesserna i en enda metod. Detta är vanligtvis ett mellanting mellan helt strukturerad testning och helt fria ad hoc-kontroller.

Utforskande testning fungerar bäst i specifika scenarier, t.ex. när snabb återkoppling är nödvändig eller om teamet måste ta itu med kantfall. Denna typ av testning når vanligtvis sin fulla potential när teamet använder skriptbaserad testning vid sidan av den.

 

2. Skillnader mellan utforskande testning

och Ad-Hoc-testning

Fördelar med att inrätta ett kompetenscentrum för testning. Är prestandatestning annorlunda än funktionell testning?

Den största skillnaden mellan ad hoc-testning och explorativ testning är att den förstnämnda testningen använder dokumentation för att registrera och underlätta kontrollerna, medan ad hoc-testning helt undviker detta. Utforskande testning lägger större vikt vid testfrihet, men aldrig på samma nivå som en ad hoc-metod som är helt ostrukturerad.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Utforskande testning innebär också att man lär sig mer om programmet och dess inre arbete under dessa kontroller – ad hoc-testare har istället ofta en omfattande kunskap om programvarans funktionalitet innan de börjar.

 

Typer av ad hoc-tester

Automatisering av webbapplikationer

Det finns tre huvudformer av ad hoc-testning inom programvarutestning, bland annat:

 

1. Testning av apor

 

Den kanske mest populära typen av ad hoc-testning är apa-test som innebär att ett team slumpmässigt tittar på olika komponenter.

Detta sker vanligtvis under enhetstestningsprocessen och innebär en rad kontroller utan testfall. Testarna undersöker självständigt data på ett helt ostrukturerat sätt, vilket gör det möjligt för dem att undersöka systemet i stort och dess förmåga att motstå intensiv belastning från användarinmatningar.

Genom att observera resultatet av dessa oskrivna tekniker kan testteamet identifiera fel som andra enhetstester har missat på grund av brister i konventionella testmetoder.

 

2. Testning av kompisar

 

I ett ad hoc-sammanhang används minst två anställda – vanligen en testare och en utvecklare – för att genomföra kompis-tester och de äger främst rum efter enhetstestningen. Kompisarna arbetar tillsammans på samma modul för att hitta fel. Deras olika färdigheter och omfattande erfarenhet gör dem till ett effektivare team, vilket bidrar till att lindra många av de problem som uppstår på grund av bristande dokumentation.

Utvecklaren kan till och med föreslå ett antal av testerna själv, så att de kan identifiera de komponenter som kan behöva mer uppmärksamhet.

 

3. Testning av par

 

Partestning är liknande i det avseendet att den involverar två anställda, men vanligtvis är det två separata testare, varav den ena utför testerna medan den andra antecknar.

Även utan formell dokumentation kan anteckningar göra det möjligt för teamet att informellt hålla reda på enskilda ad hoc-kontroller. Rollerna som testare och skribent kan växla beroende på testet eller så kan paret behålla sina tilldelade roller under hela processen.

Den testare som har mer erfarenhet är vanligtvis den som utför de faktiska kontrollerna – även om de alltid delar arbetet med varandra.

 

Manuella eller automatiserade ad hoc-tester?

datorseende för testning av programvara

Automatiserad testning kan hjälpa teamet att spara ännu mer tid under hela kvalitetssäkringsfasen, vilket gör att testarna kan lägga in fler kontroller i sitt schema. Även utan en bestämd struktur är det viktigt att testarna arbetar för att maximera täckningen och automatiseringen uppmuntrar till mer djupgående inspektioner av programvaran.

Automatiserade ad hoc-kontroller är i allmänhet mer exakta än manuella tester eftersom de kan undvika mänskliga fel under rutinmässiga uppgifter – detta är särskilt användbart när samma tester utförs i olika iterationer. Hur väl detta förfarande lyckas beror vanligtvis på vilket verktyg för automatiserad testning som teamet väljer och hur det fungerar.

Automatiserad testning har dock vissa begränsningar. Den största styrkan med ad hoc-testning är till exempel dess förmåga att efterlikna användarinmatning och genomföra slumpmässiga kontroller när testaren kommer på dem. Dessa tester kan förlora sin slumpmässighet om organisationens testprogram har svårt att hantera komplexa kontroller.

Den tid det tar att automatisera dessa mycket specifika uppgifter kan också begränsa den typiska tidsvinsten med denna process. Det är viktigt att teamen noggrant undersöker de tillgängliga automatiseringsverktygen för att hitta ett som passar företagets projekt.

 

Vad behöver du för att börja med ad hoc-testning?

Automatiserad belastningstestning

Här är de viktigaste förutsättningarna för ad hoc-testning:

 

1. Kvalificerad personal

Eftersom ad hoc-testerna är snabba, slumpmässiga inspektioner av programvarans inre arbete är det vanligtvis bra att ha testare som har erfarenhet av programvaran. De bör också ha en fungerande kunskap om viktiga testprinciper – detta gör att de lätt kan identifiera de mest effektiva kontrollerna.

 

2. Ett ostrukturerat tillvägagångssätt

Testarna måste vara villiga att överge sina vanliga strategier för ad hoc-testning. Detta tankesätt är lika viktigt som själva kvalitetskontrollerna. Denna metod kan bara lyckas utan struktur och dokumentation, och det är viktigt att testarna kommer ihåg detta i varje skede.

 

3. Programvara för automatisering

Även om ad hoc-testning bygger mer på testning av slumpmässiga inmatningar och villkor är automatisering fortfarande en mycket effektiv teknik i alla sammanhang.

Därför bör ad hoc-kontroller ändå använda automatiserade testverktyg där det är möjligt, eftersom rätt applikation kan effektivisera processen avsevärt.

 

4. Andra former av testning

Ad hoc-tester fungerar bäst tillsammans med andra kontroller som har ett mer formellt tillvägagångssätt och hjälper teamet att garantera en omfattande täckning av programvaran. Det är viktigt att testarna blandar olika tekniker, även om detta kan ske före, under eller efter att de genomför ad hoc-testerna.

 

Processen för ad hoc-testning

Testning av bakändar, verktyg, vad är det, typer, tillvägagångssätt

De vanliga stegen som testare bör följa när de utför ad hoc-testning i programvarutestning är följande:

 

1. Fastställande av mål för ad hoc-tester

 

Det här steget är begränsat på grund av bristen på dokumentation och struktur, men det är fortfarande av största vikt att teamet har ett tydligt fokus. Testarna kan börja dela vaga idéer om vilka kommande tester som ska köras och vilka komponenter som ska prioriteras.

 

2. Val av ad hoc-testgrupp

 

När teamet funderar på ett antal potentiella ad hoc-kontroller tar de också reda på vilka testare som är bäst lämpade för denna typ av testning. De väljer vanligtvis ut testare som har en ingående förståelse för applikationen och kan också para ihop dem med en utvecklare.

 

3. Genomförande av ad hoc-tester

 

Efter att ha bestämt vilka testare som är lämpliga för detta skede börjar dessa gruppmedlemmar sina kontroller vid en överenskommen punkt i testningen. Deras mål är att utföra så många ad hoc-kontroller som möjligt – som testarna kanske inte kommer på förrän i detta skede.

 

4. Utvärdering av testresultaten

 

När testarna har slutfört testerna (eller till och med mellan enskilda kontroller) utvärderar de resultaten, men utan att formellt dokumentera dem i ett testfall. Om de upptäcker några problem med ansökan registrerar de dem informellt och diskuterar gruppens nästa steg.

 

5. Rapportera eventuella upptäckta fel

 

När testarna har utvärderat resultaten måste de informera utvecklarna om de fel som finns i programvaran så att de har gott om tid att rätta till dem innan de släpps.

Testteamet använder också informationen för att avgöra hur de ska förbättra sina formella testprocesser.

 

6. Omprövning vid behov.

 

Testteamet kommer troligen att upprepa ad hoc-processen för nya iterationer av applikationen för att kontrollera hur väl den hanterar uppdateringar. Eftersom testarna kommer att ha åtgärdat många av de tidigare identifierade bristerna i sina testfall kan framtida ad hoc-kontroller kräva ett annat tillvägagångssätt.

 

Bästa praxis för ad hoc-testning

2-2.png

Det finns vissa metoder som testteamen bör tillämpa vid ad hoc-testning, bland annat:

 

1. Rikta in sig på potentiella brister i testningen.

 

Även om ad hoc-testning innebär mycket mindre planering än andra typer av testning, vill teamet ändå åtgärda brister i kvalitetssäkringen. Om ad hoc-testarna misstänker några specifika problem med teamets testfall bör de prioritera detta när de utför sina kontroller.

 

2. Överväga programvara för automatisering

 

Automatiseringsstrategier som hyperautomatisering kan erbjuda många fördelar för företag som vill utföra ad hoc-tester.

Hur väl detta lyckas beror på flera nyckelfaktorer, bland annat vilket verktyg företaget väljer och hur komplexa deras ad hoc-tester är.

 

3. Ta omfattande anteckningar

 

Bristen på dokumentation vid ad hoc-testning är främst till för att effektivisera denna process ytterligare – teamet skulle kunna dra nytta av att göra informella anteckningar under tiden de arbetar. Detta ger testarna en tydlig dokumentation av dessa kontroller och deras resultat, vilket ökar deras totala repeterbarhet.

 

4. Fortsätt att förfina testerna

 

Ad-hoc-testare förbättrar kontinuerligt sitt tillvägagångssätt för att ta hänsyn till förändringar i teamets teststrategi. När de tittar på nyare versioner av företagets programvara kan de till exempel justera dessa kontroller som svar på nyare och mer omfattande formella testfall.

 

7 misstag och fallgropar vid genomförandet av

Ad hoc-tester

fördelar UI-testning

Som i alla testprocesser finns det en mängd potentiella misstag som teamet bör försöka undvika, till exempel:

 

1. Oerfarna testare

 

För att hålla den förväntade takten i ad hoc-testerna måste teamledaren tilldela testarna utifrån deras kunskaper och färdigheter. Medan många former av testning kan passa kvalitetssäkringspersonal på nybörjarnivå, kräver ad hoc-kontroller gruppmedlemmar som förstår programvaran till fullo, helst med erfarenhet av att köra dessa tester.

 

2. Oriktade kontroller

 

Ad hoc-testning kan avsevärt förbättra testtäckningen tack vare den snabbare processen – teamet behöver inte fylla i omfattande dokumentation före och efter varje kontroll.

Ad-hoc-testarna måste dock fortfarande ha ett starkt fokus; de kan till exempel besluta att prioritera vissa komponenter med större risk för fel.

 

3. Ingen planering

 

Om man undviker att ha en plan kan man begränsa effektiviteten av ad hoc-testerna. Trots att det här tillvägagångssättet är ostrukturerat är det viktigt att teamet har en ungefärlig uppfattning om vilka tester som ska köras innan de börjar.

Tiden är begränsad under denna process och att veta hur man ska gå tillväga kan ge många fördelar.

 

4. Överdrivet strukturerad

 

I motsatt ände av spektrumet bygger detta tillvägagångssätt vanligtvis på en brist på planering, eftersom det hjälper testarna att aktivt omintetgöra testfall och hitta dolda fel.

Ad hoc-testning kallas också för slumpmässig testning och att tvinga fram en struktur kan hindra dessa kontroller från att hitta fel.

 

5. Inga långsiktiga förändringar

 

Syftet med ad hoc-testning är att identifiera eventuella svagheter i teamets testfall; detta undersöker deras övergripande strategi lika mycket som själva programvaran.

Detta innebär dock att ad hoc-tester i allmänhet bara är effektiva om teamet använder denna information för att förbättra sina formella kontroller med tiden.

 

6. Inkompatibla datamängder

 

Praktiskt taget varje form av testning kräver någon form av simulerade data för att bedöma hur programmet reagerar; vissa verktyg låter testarna automatiskt fylla ett program med simulerade data.

Detta kanske inte återspeglar hur en användare skulle använda programvaran – ad hoc-kontroller kräver datamängder som programvaran sannolikt kommer att stöta på.

 

7. Informationssilos

 

Det är viktigt att testare och utvecklare har en ständig kommunikation med varandra, även om de senare inte är en del av ad hoc-testprocessen.

Detta hjälper alla att förstå vilka tester som har utförts och visar vilka nästa åtgärder som ska vidtas, samtidigt som det förhindrar att testarna upprepar vissa kontroller i onödan.

 

Typer av resultat från ad hoc-tester

automatisering av programvarutestning

Ad hoc-kontroller ger flera olika resultat, bland annat:

 

1. Testresultat

 

De enskilda testerna ger olika resultat beroende på exakt vilken komponent och metod som används – detta kan ta många olika former.

Det är vanligtvis testarens ansvar att avgöra om resultaten utgör ett fel, men bristen på dokumentation gör det svårt att jämföra detta med deras förväntningar. Teamet skickar dessa resultat vidare till utvecklarna om de upptäcker några problem.

 

2. Testloggar

 

Programvaran i sig använder ett komplicerat system av interna loggar för att övervaka användarinmatningar och belysa ett antal fil- eller databasproblem som kan uppstå.

Detta kan tyda på ett internt fel, inklusive den specifika del av programvaran som orsakar problemet. Med den här informationen kan ad hoc-testare och utvecklare mycket lättare åtgärda de problem som de upptäcker.

 

3. Felmeddelanden

 

Många ad hoc-kontroller syftar särskilt till att bryta programvaran och avslöja dess begränsningar, vilket innebär att programmets felmeddelanden är ett av de vanligaste resultaten från dessa tester.

Genom att medvetet skapa felmeddelanden kan teamet visa vad den genomsnittliga slutanvändaren ser när de oväntade åtgärder de vidtar har en negativ inverkan på programmets funktion.

 

Exempel på ad hoc-testning

 

Här är tre scenarier för ad hoc-testning som visar hur ett team kan genomföra det för olika tillämpningar:

 

1. Webbapplikation för e-handel

 

Om ett företag vill testa en e-handelsbaserad webbapplikation kan de använda ad hoc-testning – särskilt aptestning – för att se hur väl plattformen hanterar oväntade användarinteraktioner.

Testarna kan sträva efter att pressa varje funktion till sin gräns, till exempel genom att lägga varor i korgen i orealistiska mängder eller försöka köpa produkter som inte finns i lager. De begränsas inte av teamets testfall och det finns få begränsningar för vilka kontroller de kan utföra; testarna kan till och med försöka slutföra köp med hjälp av föråldrade webbadresser.

 

2. Skrivbordsprogram

 

Ad-hoc-testare kan också tillämpa dessa tekniker för skrivbordsprogram med fokus på olika maskiner och hur väl de alla klarar av programmet.

Gruppmedlemmarna kan utföra dessa kontroller upprepade gånger för att se hur ändrade maskinvaru- eller programvaruinställningar påverkar ett programs prestanda. Ett visst grafikkort kan till exempel ha svårt att återge gränssnittet.

Alternativt kan dessa testare helt enkelt ge programmet omöjliga inmatningar och se hur det reagerar, t.ex. om det kan visa korrekta felmeddelanden som förklarar problemet på ett adekvat sätt för slutanvändaren.

 

3. Mobilapplikation

 

Ett sätt för ad hoc-testare att undersöka en mobilapplikation är att testa dess säkerhetsprotokoll – de kan till exempel försöka få direkt tillgång till appens utvecklingsverktyg.

Teamet kan försöka se om de kan utföra obehöriga åtgärder genom att hitta vanliga kryphål och exploateringar; de kan särskilt be personal med erfarenhet av app-säkerhet att underlätta detta.

Detta kan också innebära partestning tillsammans med utvecklarna, eftersom de har insikt i appens utformning och låter en testare bryta programvaran och visa exakt var säkerheten är bristfällig.

 

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Typer av fel och buggar som upptäcks

genom ad hoc-testning

zaptest-runtime-fel.png

Ad hoc-kontroller kan avslöja många problem med ett program, t.ex:

 

1. Fel i funktionaliteten

 

Om man använder ad hoc-testning för att undersöka en applikations grundläggande funktioner kan man upptäcka allvarliga fel som påverkar hur slutanvändarna använder applikationen.

Om man till exempel testar betalningsalternativen på en e-handelsplats med hjälp av en apa kan man se vilka villkor som hindrar transaktionen.

 

2. Prestandafrågor

 

Testarna kan särskilt arbeta för att skapa prestandaproblem i programmet – till exempel genom att fylla databasen med olika skräppost.

Detta kan visa sig i form av betydande fördröjning eller till och med allmän instabilitet i programvaran, vilket sannolikt kommer att leda till en krasch (som kan drabba hela systemet).

 

3. Problem med användbarheten

 

Dessa kontroller kan också avslöja fel i gränssnittet och den allmänna användarupplevelsen. Användargränssnittet i en mobilapp kan till exempel se annorlunda ut på ett annat operativsystem eller en annan skärmupplösning. Ett dåligt gränssnitt kan leda till att användarna har svårt att använda programmet.

 

4. Säkerhetsbrister

 

Ad-hoc-testernas slumpmässiga karaktär gör att de kan täcka en rad vanliga och sällsynta säkerhetsproblem; en testare kan använda dessa kontroller för att hitta ett programs administrativa bakdörrar.

Alternativt kan inspektionen visa att programvaran inte har någon datakryptering.

 

Vanliga mätvärden för ad hoc-testning

belastningstestning

Ad hoc-testning använder olika mätvärden för att underlätta resultaten, bland annat:

 

1. Effektivitet vid upptäckt av defekter

 

Det här måttet visar hur effektiv testprocessen är när det gäller att hitta fel i varje form av testning, inklusive ad hoc-testning. Effektiviteten för upptäckt av fel är den procentuella andelen upptäckta fel dividerat med det totala antalet problem – vilket visar hur effektiva testerna är.

 

2. Testets täckningsgrad

 

En extra funktion för ad hoc-testning är att öka täckningen genom att kontrollera komponenter på ett sätt som testfallen inte tar hänsyn till. Detta innebär att testarna också kommer att sträva efter att radikalt öka testtäckningen för varje kontroll så mycket som möjligt.

 

3. Total längd på testet

 

Ad hoc-testning är mycket snabbare än andra kvalitetssäkringsprocesser – och det är viktigt att testarna arbetar för att behålla denna fördel. Mätningar av testens varaktighet visar gruppmedlemmarna hur de kan spara tid och ytterligare förstärka fördelarna med ad hoc-strategier.

 

4. Antalet krascher

 

Dessa tester syftar ofta till att bryta programvaran och orsaka en krasch eller ett allvarligt fel – vilket gör att de går bortom typiska teststrategier och hittar oväntade problem. Därför kan det vara bra att veta hur ofta programvaran kraschar och vad som orsakar dessa problem.

 

5 bästa verktygen för ad hoc-testning

de bästa verktygen för gratis testning och automatisering av programvara för företag och RPA

Det finns många gratis och betalda testverktyg för ad hoc-testning i programvarutestning – de fem bästa är följande:

 

1. ZAPTEST Free & Enterprise Edition

grey box testing artikel - verktyg, tillvägagångssätt, jämförelse med white box och black box testing, gray box gratis och företagsverktyg.

ZAPTEST är ett omfattande program för programvarutestning som erbjuder en stark test- och RPA-funktionalitet i både gratis- och företagsversionen.

Den här fullskaliga sviten för automatisering av programvara + RPA möjliggör fullständig testning på olika skrivbords- och mobilplattformar, och med programvarans 1SCRIPT-teknik kan användarna enkelt utföra samma kontroller upprepade gånger. Dessutom utnyttjar verktyget den senaste tekniken för datorseende, vilket gör det möjligt för ZAPTEST att köra ad hoc-tester ur ett mänskligt perspektiv.

 

2. BrowserStack

 

BrowserStack är en molnplattform som kan underlätta testning på över 3 000 olika maskiner, med ytterligare en funktion för att automatisera Selenium-skript. Även om den ger en stark täckning för programvaruprojekt fungerar den bäst för webbläsar- och mobilapplikationer.

BrowserStack-testlösningar har också en gratis provperiod med 100 minuters automatiserad testning, men den kan ha begränsad användning.

Även om den molnbaserade metoden kan vara till hjälp, påverkar den också plattformens svarstid negativt.

 

3. LambdaTest

 

LambdaTest använder också molnbaserad teknik och lägger stor vikt vid testning av webbläsare, vilket kan begränsa dess effektivitet för andra program – även om det fortfarande passar bra för iOS- och Android-program. Detta är en användbar plattform när skalbarhet är ett problem och den kan integreras med många andra testhostingtjänster.

Vissa användare har dock blandade reaktioner på applikationens prissättning för de olika alternativen som finns tillgängliga, vilket kan begränsa tillgängligheten för mindre organisationer.

 

4. TestRail

 

TestRail är generellt sett ganska anpassningsbart eftersom det körs helt och hållet i webbläsaren, och trots ett starkt fokus på effektiva testfall har det också direkt ad hoc-funktionalitet. De analyser som tillhandahålls efter varje test kan också hjälpa team som aktivt undviker att göra egen oberoende dokumentation, samtidigt som de kan validera sin testprocess.

Större sviter kan dock ha svårt att hantera det webbläsarbaserade formatet, vilket kan begränsa tidsvinsterna med ad hoc-testning med en betydande marginal.

 

5. Zephyr

 

Zephyr är en testhanteringsplattform från SmartBear som hjälper kvalitetssäkringsteam att förbättra sin testsynlighet samtidigt som den integreras väl med andra programvaror för felrapportering.

Den här funktionen är dock begränsad till vissa applikationer, där Confluence och Jira är de som har störst nytta av Zephyr – dessa kanske inte är de mest effektiva lösningarna för alla företag. Det finns flera skalbara program tillgängliga under Zephyr-varumärket till olika priser.

 

Checklista, tips och tricks för ad hoc-testning

Checklista för programvarutestning

Här är ytterligare tips för team som ska ta hänsyn till när de utför ad hoc-tester:

 

1. Prioritera känsliga komponenter

 

Vissa funktioner eller komponenter är naturligtvis mer utsatta för fel än andra, särskilt om de är viktiga för programmets övergripande funktion.

Varje metod för testning bör identifiera de delar av en applikation som kan dra nytta av mer noggrann uppmärksamhet. Detta är särskilt användbart när den totala tiden för testning är begränsad.

 

2. Undersöka olika testverktyg

 

Det verktyg som en organisation använder för att underlätta sina tester kan påverka täckningen och tillförlitligheten av dessa kontroller.

Med ad hoc-testning är det värt att titta på så många program som möjligt för att hitta dem som passar den användarcentrerade aspekten. Programvara som använder datorsynsteknik, som ZAPTEST, kan använda en människoliknande strategi för ad hoc-tester.

 

3. Anta ett ad hoc-tänkande

 

Ad hoc-testning ger en enorm frihet under hela kvalitetssäkringsfasen, men teamet måste engagera sig i den för att få del av strategins viktigaste fördelar.

Till exempel bör ad hoc-testare avstå från alla sina vanliga dokument utöver grundläggande anteckningar, och de måste granska programvaran från ett helt nytt perspektiv.

 

4. Lita på testande instinkter

 

Erfarenhet av ad hoc-testning eller allmänna programvarukontroller kan hjälpa till att lyfta fram vanliga felpunkter, vilket hjälper testarna att avgöra hur de ska upptäcka fel av alla slag.

Det är viktigt att testarna litar på sina instinkter och alltid använder denna kunskap till sin fördel – de kan känna av vilka ad hoc-kontroller som skulle vara mest användbara.

 

5. Fullständig registrering av upptäckta fel

 

Även om ad hoc-testning inte har någon formell dokumentation utan mestadels bygger på informella anteckningar är det fortfarande viktigt att teamet kan identifiera och kommunicera orsaken till ett programvarufel.

De måste logga all information som testet ger och som är relevant för utvecklare, t.ex. potentiella orsaker till dessa problem.

 

6. Ta alltid hänsyn till användaren

 

Varje form av testning syftar till att i viss mån anpassa användarens helhetsupplevelse – och ad hoc-testning är inget undantag. Även om man ofta tittar djupare på applikationens inre arbete och till och med dess interna kod, bör ad hoc-testare försöka bryta programvaran på ett sätt som användarna teoretiskt sett skulle kunna göra.

 

7. Förbättra processen kontinuerligt

 

Testteamen bör förfina sitt tillvägagångssätt för ad hoc-testning mellan flera iterationer av samma programvara och från ett projekt till ett annat.

De kan samla in feedback från utvecklarna för att se hur väl deras ad hoc-tester hjälpte kvalitetssäkringsfasen och om de kunde öka testtäckningen avsevärt.

 

Slutsats

Ad hoc-testning kan hjälpa organisationer av alla slag att verifiera sin strategi för mjukvarutestning, men sättet som tekniken genomförs på kan vara en viktig faktor för dess effektivitet.

Att balansera olika testtyper är nyckeln till att få ut mesta möjliga nytta av ad hoc-kontroller – särskilt som denna form av testning syftar till att komplettera de andra genom att fylla en strategisk lucka.

Med ett program som ZAPTEST kan teamet utföra ad hoc-tester med större säkerhet och flexibilitet, särskilt om de implementerar automatisering. Oavsett teamets specifika tillvägagångssätt kan deras engagemang för ad hoc-testning revolutionera hela programmet eller projektet.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post