Ad hoc-testning: Hur man hittar fel utan en formell testprocess

Bara termen ad hoc innebär avsaknad av struktur eller något som inte är metodiskt. När man talar om ad hoc-testning innebär det att det är en form av black box- eller beteendetestning som utförs utan någon formell process.

Den formella processen innebär här att man har dokumentation som kravdokument, testplaner, testfall och ordentlig testplanering när det gäller tidsplan och ordning för utförda tester. Dessutom dokumenteras vanligtvis inte heller eventuella åtgärder som utförs under testningen.

Detta görs huvudsakligen i syfte att försöka avslöja defekter eller brister som inte kan fångas upp genom traditionella eller formella processer som följs under testcykeln.

Som redan förstått ligger kärnan i denna testning i att det inte finns något formellt eller strukturerat sätt att testa. När en sådan typ av slumpmässig testteknik utförs är det uppenbart att testarna utför detta utan något särskilt användningsfall i åtanke med målet att bryta sönder systemet.

Därmed är det definitivt ännu mer uppenbart att en sådan intuitiv eller kreativ testmetodik kräver att testaren är extremt skicklig, kapabel och har en djupgående kunskap om systemet. Ad hoc-testning säkerställer att den utförda testningen är fullständig och är särskilt användbar när det gäller att fastställa testhinkens effektivitet.

Rekommenderad läsning => Exploratory Testing – How to Think Beyond Traditional Testing Boundaries?

Låt oss börja med ett exempel på ad hoc-testning

Här är ett exempel på hur vi kan utföra denna testning när det gäller UI Wizard.

Säg att du behöver skapa en plan eller en mall för någon form av uppgift som ska utföras med hjälp av den här UI-wizarden. Guiden är en serie rutor som har användarinmatning som namn, beskrivning etc.

När guiden fortskrider: låt oss säga att på en av rutorna ska användardata matas in vilket innebär att UI-guiden kastar en kontext-popupruta som lägger till de associerade data för att slutföra guiden och distribuera/aktivera guiden.

För att testa detta gör testaren sina vanliga tester som:

• Fullborda guiden framgångsrikt med alla giltiga data och skapa planen.
• Avbryt guiden halvvägs.
• Redigera en skapad plan genom guiden.
• Gradera den skapade planen och se att det inte finns några rester av den.
• Inför ett negativt värde i guiden och se att lämpliga felmeddelanden visas.

Nu, för exemplet ovan är här några testfall för ad hoc-tester som skulle kunna utföras för att avslöja så många defekter som möjligt:

• När du försöker lägga till negativa data, lägg till vissa specialtecken som inte är begränsade för att se om de hanteras korrekt. Till exempel begränsar ibland guider inte {or [ hakparenteser men i vissa situationer kan detta komma i konflikt med kod baserat på språket det är skrivet i, och orsaka ett mycket opålitligt beteende.
• Ett annat test är specifikt med avseende på popup-fönster. En användare kan få popupen att starta och sedan försöka trycka på backspace-knappen på tangentbordet. Många gånger har jag observerat att om man gör det så försvinner bakgrundsguiden helt och hållet och alla användardata som matats in fram till dess att pop-upen startades går förlorade!

Kännetecken för Ad-hoc-testning:

Om du noterar scenarierna ovan kommer du att se något mycket distinkt kännetecken för den här typen av testning.

Dessa är:

• De är alltid i linje med testmålet. De är dock vissa drastiska tester som utförs med avsikt att bryta systemet.
• Testaren måste ha fullständig kunskap och medvetenhet om det system som testas. Resultatet av denna testning hittar buggar som försöker belysa kryphålen i testprocessen.
• Också när man tittar på de två ovanstående testerna skulle den naturliga reaktionen vara att – den här typen av test kan utföras bara en gång eftersom det inte är genomförbart för en omtestning om det inte finns en defekt associerad.

När gör vi ad hoc-testning?

En miljondollarsfråga, minsann!

De flesta av tidens testteam är alltid belastade med för många funktioner att testa inom begränsade tidsramar. Under denna begränsade tidsperiod finns det många testaktiviteter som härrör från den formella processen som också måste slutföras. I sådana situationer är det svårt att få in ad hoc-testning i testningen.

Men enligt min erfarenhet kan en omgång ad hoc-testning göra underverk för produktkvaliteten och väcka många designfrågor.

Då ad-hoc-testning är mer av en ”vildvuxen” testteknik som inte behöver vara strukturerad, är den allmänna rekommendationen att den måste utföras efter det att utförandet av den aktuella testhinken är klart. En annan synpunkt är att detta kan göras när detaljerad testning inte kan utföras på grund av mindre tid.

I min mening skulle jag säga att ad-hoc-testning kan göras nästan när som helst – i början, mot mitten och mot slutet! Det hittar bara sin plats vid varje given tidpunkt. När ad hoc-testning måste göras för att få ut maximalt värde bedöms dock bäst av en erfaren testare som har djupgående kunskaper om det system som ska testas.

När man inte ska utföra?

Om föregående fråga var värd en miljon dollar borde den här vara värd en miljard!

Samtidigt som vi har fastställt hur effektiv och fruktbar ad-hoc-testning kan vara, måste vi som skickliga och kompetenta testare också dechiffrera när man inte ska investera i denna typ av testning. Även om det är upp till testaren att avgöra, finns här några rekommendationer/exempel på när det kanske inte är nödvändigt.

• Undvik denna testning när det finns ett testfall för vilket det finns en defekt. I en sådan situation finns det ett behov av att dokumentera testfallets felpunkt och sedan verifiera/omtester felet när det är åtgärdat. Därför kommer det inte att vara tillämpligt här.
• Det kan också finnas vissa scenarier där kunder eller klienter kan bjudas in för att testa betaversionen av programvaran. I sådana fall bör denna testning inte genomföras.
• Ett annat scenario är när det är en mycket enkel UI-skärm som läggs till. Traditionell positiv och negativ testning bör räcka här för att få fram maximalt antal defekter.

Typer av ad hoc-testning

Ad hoc-testning kan delas in i tre kategorier nedan:

#1) Buddy Testing

I denna form av testning finns det en testmedlem och en utvecklingsmedlem som väljs ut för att arbeta med samma modul. Precis efter att utvecklaren har slutfört enhetstestningen sitter testmedlemmen och utvecklaren tillsammans och arbetar med modulen. Denna typ av testning gör det möjligt att se funktionen i ett bredare perspektiv för båda parter.

Utvecklaren kommer att få ett perspektiv på alla olika tester som testaren utför och testaren kommer att få ett perspektiv på hur den inneboende designen är, vilket kommer att hjälpa honom att undvika att utforma ogiltiga scenarier och därmed förhindra ogiltiga defekter. Det kommer att hjälpa den ena att tänka som tänka den andra.

#2) Partestning

I denna testning arbetar två testare tillsammans på en modul med samma testuppsättning som delas mellan dem. Tanken bakom denna form av testning att låta de två testarna brainstorma idéer och metoder för att ha ett antal defekter. Båda kan dela på testarbetet och göra nödvändig dokumentation av alla observationer som gjorts.

#3) Monkey Testing

Denna testning utförs huvudsakligen på enhetstestnivå. Testaren analyserar data eller tester på ett helt slumpmässigt sätt för att säkerställa att systemet klarar av eventuella krascher. Denna testning kan vidare klassificeras i två kategorier:

Ad-hoc-testning Fördelar

Denna testning garanterar testaren mycket makt att vara så kreativ som nödvändigt.

Detta ökar testkvaliteten och effektiviteten enligt nedan:

• Den största fördelen som sticker ut är att en testare kan hitta antalet defekter än vid traditionell testning på grund av de olika innovativa metoderna som de kan tillämpa för att testa programvaran.
• Denna form av testning kan tillämpas var som helst i SDLC:n; den är inte bara begränsad till testteamet. Utvecklarna kan också utföra denna testning, vilket skulle hjälpa dem att koda bättre och även förutsäga vilka problem som kan uppstå.
• Den kan kopplas ihop med annan testning för att få bästa möjliga resultat, vilket ibland kan förkorta den tid som behövs för den vanliga testningen. Detta skulle göra det möjligt att generera testfall av bättre kvalitet och bättre kvalitet på produkten som helhet.
• Det krävs ingen dokumentation, vilket förhindrar en extra börda för testaren. En testare kan koncentrera sig på att faktiskt förstå den underliggande arkitekturen.
• I de fall då det inte finns mycket tid till förfogande för att testa kan detta visa sig vara mycket värdefullt när det gäller testtäckning och kvalitet.

Ad-hoc-testning nackdelar

Ad-hoc-testning har också några nackdelar. Låt oss ta en titt på några av de nackdelar som är uttalade:

Då det inte är särskilt organiserat och det inte finns någon dokumentation som är obligatorisk, är det mest uppenbara problemet att testaren måste komma ihåg och samla alla detaljer i ad-hoc-scenarierna i minnet. Detta kan vara ännu mer utmanande, särskilt i scenarier där det finns mycket interaktion mellan olika komponenter.

• Följt av den första punkten skulle detta också resultera i att man inte kan återskapa defekter i de efterföljande försöken om man blir tillfrågad om information.
• En annan mycket viktig fråga som detta aktualiserar är ansvarsskyldigheten för insatser. Eftersom detta inte är planerat/strukturerat finns det inget sätt att redovisa den tid och ansträngning som investeras i denna typ av testning.
• Ad hoc-testning måste endast utföras av en mycket kunnig och skicklig testare i teamet eftersom det kräver att man är proaktiv och har intuition när det gäller att förutse potentiella områden som är behäftade med fel.

Bästa metoder för att göra denna testning mer effektiv

Vi har utförligt diskuterat de styrkor och svagheter som är förknippade med denna testning.

Idealt bör ad-hoc-testning finna sin plats i SDLC, men om den inte hanteras på rätt sätt kan den dock visa sig vara kostsam och ett slöseri med värdefull testtid. Nedan följer några tips för att göra ad hoc-testning effektiv:

#1) Identifiera felbenägna områden:

När du har ett bra grepp om testningen av en viss mjukvara kommer du att hålla med om att det kommer att finnas vissa funktioner som är mer benägna till fel än de andra. Om du är ny i systemet, gå då vidare och kontrollera funktionerna v/s defekter som öppnats mot dem.

Antalet defekter i en viss funktion är kommer att visa dig att den är känslig och du bör exakt välja just det området för att utföra ad-hoc-testning. Detta visar sig vara ett mycket tidseffektivt sätt att avslöja vissa allvarliga defekter.

#2) Bygg upp expertis:

En testare som har mer erfarenhet är otvivelaktigt mer intuitiv och kan gissa sig till var felen kan finnas, jämfört med någon som inte har så mycket erfarenhet. Jag skulle säga, erfaren eller inte, att det är upp till individen att ta steget och bygga upp expertis om det system som testas.

Ja, erfarna testare har ett övertag eftersom deras kunskaper som byggts upp under årens lopp kommer väl till pass, men de nya testarna bör använda detta som en plattform för att skaffa sig så mycket kunskap som möjligt för att kunna utforma bättre ad hoc-scenarier.

#3) Skapa testkategorier:

När du väl känner till listan över funktioner som ska testas, ska du avsätta några minuter för att bestämma hur du ska kategorisera dessa funktioner och testa. Till exempel bör du bestämma dig för att testa funktioner som är mest synliga och oftast används av användaren före allt annat, eftersom dessa verkar kritiska för programvarans framgång.

Därefter kan du kategorisera dem funktionellt/prioriteringsmässigt och testa dem segment för segment.

Ett annat exempel där detta är särskilt mycket viktigt är om det finns en integration mellan komponenter eller moduler. I dessa fall kan det finnas många avvikelser som kan uppstå. Att använda kategorisering skulle hjälpa till att beröra denna typ av test åtminstone en eller två gånger.

#4) Ha en grov plan:

Ja, ja den här punkten kan förvirra dig lite eftersom vi beskrev ad-hoc-testning som testning som inte bör ha någon planering eller dokumentation. Tanken här är att hålla sig till kärnan i ad hoc-testning, men ändå ha några grova pekpinnar nedtecknade om hur du planerar att testa.

Ett mycket grundläggande exempel är att du ibland kanske helt enkelt inte kan komma ihåg alla tester som du har för avsikt att utföra. Om du antecknar dem kan du se till att du inte missar något.

#5) Verktyg:

Låt oss ta ett exempel som vi alla ofta ställs inför. Många gånger är testningen av funktionaliteten i sig själv framgångsrik utan att någon avvikelse rapporteras i dess beteende. Loggarna bakom kulisserna kan dock rapportera några undantag som testarna kan missa eftersom de inte hindrar testmålet på något sätt.

Dessa kan till och med vara av hög allvarlighetsgrad. Därför är det mycket viktigt för oss att lära oss och verktyg som hjälper till att lokalisera detta omedelbart.

#6) Dokumentera för fler defekter:

Jag förstår att detta kan höja några ögonbryn igen. Dokumentationen behöver inte vara detaljerad, men bara en liten anteckning för din egen referens av alla olika scenarier som täcks, avvikelse i de involverade stegen och registrera dessa defekter för den särskilda testfunktionskategorin.

Detta kommer att hjälpa dig att förbättra det övergripande testet också varigenom du kan bestämma hur du ska improvisera befintliga testfall eller lägga till fler om det är nödvändigt.

Slutsats

Vi har diskuterat i detalj om ad hoc-testningstekniker – dess styrkor, svagheter, situationer där det skulle vara fördelaktigt och inte fördelaktigt.

Detta är en testteknik som garanterar att tillgodose och tillfredsställa en testares kreativitet maximalt. Under hela min testkarriär får jag den största tillfredsställelsen av ad hoc-testning eftersom det inte finns någon gräns för att vara nyskapande och man blir bara mer kunnig.

Med detta sagt är det viktigaste att ta med sig från all ovanstående information att avgöra hur man kan utnyttja styrkorna i ad hoc-testning och se till att den ger ett mervärde till den övergripande testprocessen och produktkvaliteten.

Om författaren: Det här är en gästartikel av Sneha Nadig. Hon arbetar som testledare med över 7 års erfarenhet av manuella och automatiska testprojekt.

Gör du ad hoc-tester i ditt projekt? Vilka är dina förslag för att lyckas med ad hoc-tester?