Meny

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

ad hoc testing how find defects without formal testing process

Prova Vårt Instrument För Att Eliminera Problem

Själva termen ad-hoc innebär brist på struktur eller något som inte är metodiskt. När du pratar om ad hoc-testning , betyder det att det är en form av a svart låda eller beteendestestning utan någon formell process på plats.

Den formella processen här innebär att ha dokumentation som kravdokument, testplaner, testfall och korrekt testplanering i termer av dess schema och ordning på utförda tester. Alla handlingar som utförs under testningen dokumenteras vanligtvis inte.

Ad hoc-testning

Detta görs främst 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ås ligger kärnan i denna testning i att inte ha ett formellt eller strukturerat sätt att testa. När en sådan typ av slumpmässiga testtekniker utförs är det uppenbart att testarna utför detta utan något särskilt användningsfall i åtanke i syfte att bryta systemet.

Därför är det definitivt ännu mer uppenbart att en sådan intuitiv eller kreativ testmetod kräver testaren att vara extremt skicklig, kapabel och ha djupgående kunskaper om systemet. Ad-hoc-testning säkerställer att testningen är komplett och är särskilt mycket användbar för att bestämma testskopans effektivitet.

Rekommenderad läsning=> Exploratory Testing - Hur kan man tänka utöver traditionella testgränser?

Vad du kommer att lära dig:

Låt oss börja med ett ad hoc-testexempel

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

Låt oss säga att du måste skapa en plan eller en mall för någon form av uppgift som ska utföras med den här UI-guiden. Guiden är en serie rutor som har användarinmatning som namn, beskrivning etc.

När guiden fortskrider: säg på en av rutorna, användardata ska anges som innebär att UI-guiden kastar en popup-ruta som lägger till tillhörande data för att slutföra guiden och distribuera / aktivera guiden.

För att testa denna testare gör han sin regelbundna testning som:

den bästa mobiltelefonspionappen
  • Slutför guiden framgångsrikt med alla giltiga data och skapa planen.
  • Avbryt guiden halvvägs.
  • Redigera en skapad plan via guiden.
  • Ta bort den skapade planen och se att det inte finns några rester av den.
  • Ange ett negativt värde i guiden och se lämpliga felmeddelanden visas.

Nu, för ovanstående exempel här är några testfall för ad hoc-test som kunde utföras att avslöja så många fel 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 ordentligt. Till exempel, ibland begränsar guiderna inte {eller (hängslen, men i vissa situationer kan detta komma i konflikt med koden baserat på språket det är skrivet på och orsaka mycket opålitligt beteende.
  • Ett annat test är specifikt med avseende på popup-fönster. En användare kan få pop-up att starta och sedan försöka trycka på backstegsknappen på tangentbordet. Många gånger har jag observerat att genom att göra detta, försvinner bakgrundsguiden helt och hela användardata som matats in tills den punkt där popup-fönstret startades, går förlorad!

Egenskaper för ad hoc-testning:

Om du noterar scenarierna ovan ser du något mycket distinkt kännetecken för denna typ av testning.

Dom är:

  • De är alltid i linje med testmålet. Det är dock vissa drastiska tester som utförts med avsikt att bryta systemet.
  • Testaren måste ha fullständig kunskap och medvetenhet om systemet som testas. Resultatet av denna testning hittar fel som försöker markera kryphålen i testprocessen.
  • Om man även tittar på ovanstående två tester skulle den naturliga reaktionen på det vara att - den här typen av test kan utföras bara en gång, eftersom det inte är möjligt för ett omprov såvida det inte är en defekt associerad.

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

En miljon dollar fråga verkligen!

För det mesta är testteamen alltid belastade med för många funktioner för att testa inom begränsade tidslinjer. Under den begränsade tidsperioden finns det massor av testaktiviteter som härrör från den formella processen som också måste slutföras. I sådana situationer är ad hoc-testning smal.

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

Eftersom ad hoc-testning är mer en 'vildbarn' -teknik som inte behöver struktureras, är den allmänna rekommendationen att den måste utföras efter att den nuvarande testskopan har utförts. En annan synpunkt är att detta kan göras när detaljerad testning inte kan utföras på grund av kortare tid.

Enligt min mening skulle jag säga det ad-hoc-test kan göras nästan när som helst - i början, mot mitten och mot slutet! Det hittar bara sin plats när som helst. Men när ad hoc-testning måste göras för att få fram maximalt värde bedöms bäst av en erfaren testare som har djupgående kunskaper om systemet som testas.

När ska man inte köra?

Om den tidigare frågan var värd en miljon dollar borde den vara värd en miljard!

Vi har fastställt hur effektiv och fruktbar ad hoc-testning kan vara, men som en skicklig och kapabel testare måste vi också dechiffrera när vi inte ska investera i denna typ av testning. Även om det bestäms av testaren, här är några rekommendationer / exempel 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 / testa om defekten när den är fixad. Därför är det inte tillämpligt här.
  • Det kan också finnas vissa scenarier där kunder eller kunder kan bjudas in testa betaversionen av programvaran . I sådana fall bör denna testning inte utföras.
  • Ett annat scenario är när det finns en mycket enkel UI-skärm som läggs till. Traditionella positiva och negativa tester bör räcka här för att få fram maximala defekter.

Typer av ad hoc-testning

Ad-hoc-testning kan kategoriseras i tre kategorier nedan:

# 1) Buddy Testing

I denna form av testning kommer det att finnas en testmedlem och en utvecklingsmedlem som kommer att väljas för att arbeta med samma modul. Strax efter utvecklaren slutför enhetstestningen , den testare och utvecklare sitter tillsammans och arbeta med modulen. Denna typ av testning gör att funktionen kan ses i ett bredare omfång för båda parter.

Utvecklaren får ett perspektiv på alla de olika tester som testaren kör och testaren kommer att få ett perspektiv på hur den inneboende designen är som hjälper honom att undvika att designa ogiltiga scenarier och därigenom förhindra ogiltiga defekter. Det kommer att hjälpa en att tänka som att tänka den andra.

# 2) Parprovning

I denna testning arbetar två testare tillsammans på en modul med samma testinställning som delas mellan dem. Idén bakom denna form av testning att få de två testarna brainstorma idéer och metoder för att ha ett antal defekter. Båda kan dela 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 testar på ett helt slumpmässigt sätt för att säkerställa att systemet klarar av kraschar. Denna testning kan klassificeras ytterligare i två kategorier:

hur man testar webbplats på olika webbläsare

Ad-hoc-testfördelar

Testningen garanterar testaren med mycket kraft 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 de kan använda för att testa programvaran.
  • Denna form av testning kan tillämpas var som helst i SDLC; det är inte bara begränsat till testteamet. Utvecklarna kan också genomföra denna testning, vilket skulle hjälpa dem att koda bättre och också förutsäga vilka problem som kan uppstå.
  • Det kan kombineras med en annan testning för att få bästa resultat som ibland kan förkorta den tid som krävs för den vanliga testningen. Detta skulle göra det möjligt att generera testkvaliteter med bättre kvalitet och produktens kvalitet på det hela taget.
  • Det föreskriver inte att någon dokumentation ska göras som förhindrar extra belastning på testaren. En testare kan koncentrera sig på att faktiskt förstå den underliggande arkitekturen.
  • I fall där det inte finns mycket tid att testa kan detta visa sig vara mycket värdefullt när det gäller testtäckning och kvalitet.

Ad-hoc test nackdelar

Ad-hoc-test har också några nackdelar. Låt oss ta en titt på några av de nackdelar som uttalas:

Eftersom det inte är särskilt organiserat och det inte finns någon mandatdokumentation är det tydligaste problemet att testaren måste komma ihåg och komma ihåg alla detaljer i ad-hoc-scenarier i minnet. Detta kan vara ännu mer utmanande, särskilt i scenarier där det finns mycket interaktion mellan olika komponenter.

  • Följt från den första punkten skulle detta också resultera i att man inte kunde återskapa defekter i de efterföljande försöken om man ombads om information.
  • En annan mycket viktig fråga som detta lyfter fram är ansträngningsansvaret. Eftersom detta inte är planerat / strukturerat finns det inget sätt att redovisa den tid och ansträngning som investerats 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 vara proaktiv och intuition när det gäller att förutse potentiella felområden.

Bästa metoder för att göra denna test effektivare

Vi har diskuterat långsiktigt styrkor och svagheter i samband med denna testning.

Helst bör ad hoc-test hitta sin plats i SDLC, men om det inte närmar sig på lämpligt sätt kan det visa sig vara kostsamt och slöseri med värdefull testtid. Nedan följer några tips för att göra ad hoc-test effektiv:

# 1) Identifiera defekt utsatta områden:

När du har ett bra grepp om att testa en viss programvara, kommer du att komma överens om att det kommer att finnas vissa funktioner som är mer benägna för fel än de andra. Om du är ny i systemet, fortsätt och kontrollera funktionerna v / s-defekter som har öppnats mot dem.

Antalet fel i en viss funktion visar att den är känslig och du bör välja just det området för ad hoc-testning. Detta visar sig vara ett mycket tidseffektivt sätt att avslöja några allvarliga brister.

# 2) Byggkompetens:

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

Ja, erfarna testare har ett försprång eftersom deras färdigheter som byggts upp genom åren kommer till nytta, men de nya testarna bör använda detta som en plattform för att få så mycket kunskap som möjligt för att utforma bättre ad hoc-scenarier.

# 3) Skapa testkategorier:

När du är medveten om listan över funktioner som ska testas, avsätt några minuter för att bestämma hur du ska kategorisera dessa funktioner och testa. Till exempel, du bör bestämma dig för att testa funktioner som är mest synliga och som oftast används av användaren innan något annat, eftersom dessa verkar kritiska för programvarans framgång.

Då kan du kategorisera dem funktionalitet / prioritering och testa dem segment för segment.

Ett annat exempel där detta är särskilt viktigt är om det finns integration mellan komponenter eller moduler. I dessa fall kan det finnas många avvikelser som kan uppstå. Att använda kategorisering kan hjälpa till att beröra denna typ av test minst 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 borde ha någon planering eller dokumentation. Tanken här är att hålla fast vid kärnan i ad-hoc-testning, men ändå ha några grova pekare skrivna ner på hur du planerar att testa.

Ett mycket grundläggande exempel är att du ibland kanske inte kommer ihåg alla tester du tänker utföra. Så att notera dem skulle säkerställa att du inte missar någonting.

# 5) Verktyg:

Låt oss ta ett exempel som vi alla ofta möter. Många gånger om du observerar är testningen av funktionaliteten i sig lyckad utan någon skillnad rapporterad i dess beteende. Loggarna bakom kulisserna kan dock rapportera några undantag som kan ses av testarna eftersom det inte hindrar testmålet på något sätt.

Dessa kan ha en hög grad av svårighetsgrad. Därför är det väldigt viktigt för oss att lära oss och verktyg som hjälper till att hitta detta omedelbart.

# 6) Dokument för fler defekter:

Återigen förstår jag att detta kan höja ögonbrynen igen. Dokumentation behöver inte vara detaljerad, utan bara en liten anteckning för din egen referens av alla olika scenarier som omfattas, avvikelse i steg och registrera dessa defekter för den specifika testfunktionskategorin.

Detta hjälper dig att förbättra den övergripande testskopan så att du kan bestämma hur du ska improvisera befintliga testfall eller lägga till fler om det behövs.

Slutsats

Vi har diskuterat i detalj om ad hoc-testtekniker - dess styrkor, svagheter, situationer där det skulle och inte skulle vara till nytta.

Detta är en testteknik som garanterar att tillgodose och tillfredsställa testarens kreativitet maximalt. I min helhet testkarriär , Jag får största tillfredsställelse från ad hoc-testning eftersom det inte finns någon gräns för att vara innovativ och du bara blir mer kunnig.

Med detta sagt skulle det viktigaste att ta tillbaka från all ovanstående information vara att bestämma hur du kan utnyttja styrkorna för ad hoc-testning och få det att ge mervärde till den övergripande testprocessen och produktkvaliteten.

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

Utför du ad hoc-test på ditt projekt? Vilka är dina förslag för att göra Ad-hoc-test framgångsrika?

Rekommenderad läsning

^