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.
Ad hoc-testning Betydelse: Vad är Ad-Hoc Testing?
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?
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
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?
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
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
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
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?
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
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?
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
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.
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
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?
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?
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
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
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
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
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.
Typer av fel och buggar som upptäcks
genom ad hoc-testning
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
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
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
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
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.
