Menu

Ad-hoc-test: Sådan finder du mangler uden en formel testproces

ad hoc testing how find defects without formal testing process

Prøv Vores Instrument Til At Fjerne Problemer

Selve udtrykket ad-hoc indebærer mangel på struktur eller noget, der ikke er metodisk. Når du taler om ad hoc-test , betyder det, at det er en form for a sort kasse eller adfærdstest udført uden nogen formel proces på plads.

Den formelle proces betyder her at have dokumentation som kravsdokumenter, testplaner, testsager og korrekt testplanlægning med hensyn til dens tidsplan og rækkefølge for udførte tests. Også handlinger, der udføres under testen, dokumenteres ikke typisk.

Ad-hoc test

Dette gøres hovedsageligt med det formål at forsøge at afdække mangler eller mangler, som ikke kan fanges gennem traditionelle eller formelle processer, der følges under testcyklussen.

Som allerede forstået ligger essensen af ​​denne test i ikke at have en formel eller struktureret måde at teste på. Når en sådan form for tilfældige testteknikker udføres, er det tydeligt, at testerne udfører dette uden særlig brug i tankerne med det formål at bryde systemet.

Derfor er det bestemt endnu mere indlysende, at en sådan intuitiv eller kreativ testmetode kræver testeren skal være yderst dygtig, dygtig og have indgående kendskab til systemet. Ad hoc-test sikrer, at den udførte test er komplet og er særlig meget nyttig til bestemmelse af testskovlens effektivitet.

Anbefalet læsning=> Undersøgende test - Hvordan tænker man ud over traditionelle testgrænser?

Hvad du lærer:

Lad os starte med et Ad-hoc-testeksempel

Her er et eksempel på, hvordan vi kan udføre denne test, når det kommer til UI Wizard.

Lad os sige, at du skal oprette en plan eller en skabelon til en slags opgave, der skal udføres ved hjælp af denne UI-guide. Guiden er en række ruder, der har brugerinput som navn, beskrivelse osv.

Efterhånden som guiden skrider frem: sig på en af ​​ruderne, der skal indtastes brugerdata, som involverer UI-guiden til at kaste en kontekst-pop op-boks, der tilføjer de tilknyttede data for at fuldføre guiden og distribuere / aktivere guiden.

For at teste denne tester udfører han regelmæssig test som:

vægtet graf tilstødelsesliste c ++
  • Fuldfør guiden med alle gyldige data, og opret planen.
  • Annuller guiden midtvejs.
  • Rediger en oprettet plan gennem guiden.
  • Slet den oprettede plan og se, at der ikke er nogen rester af den.
  • Indtast en negativ værdi i guiden, og se de relevante fejlmeddelelser ses.

Nu til ovenstående eksempel her er nogle testtilfælde til ad-hoc-test der kunne udføres at afdække så mange mangler som muligt:

  • Mens du prøver at tilføje negative data, skal du tilføje visse specialtegn, der ikke er begrænset for at se, om de håndteres korrekt. For eksempel, nogle gange begrænser guider ikke {eller (seler, men i visse situationer kan dette være i konflikt med kode baseret på det sprog, det er skrevet på, og forårsage meget upålidelig opførsel.
  • En anden test er specifikt med hensyn til pop op-vinduer. En bruger kan få pop op til at starte og derefter prøve at trykke på backspace-knappen på tastaturet. Mange gange har jeg bemærket, at dette gør, at baggrundsguiden forsvinder fuldstændigt, og at alle brugerdata, der blev indtastet indtil det tidspunkt, hvor pop op-vinduet blev startet, går tabt!

Egenskaber ved ad hoc-test:

Hvis du bemærker scenarierne ovenfor, vil du se noget meget tydeligt kendetegn ved denne type test.

De er:

  • De er altid i tråd med testmålsætningen. Det er dog visse drastiske tests, der udføres med det formål at bryde systemet.
  • Testeren skal have komplet viden og opmærksomhed omkring det system, der testes. Resultatet af denne test finder fejl, der forsøger at fremhæve smuthuller i testprocessen.
  • Når man ser på ovenstående to tests, ville den naturlige reaktion på det være, at - denne type test kan udføres kun en gang, da det ikke er muligt for en gentest, medmindre der er en fejl forbundet.

Hvornår foretager vi ad hoc-test?

Et spørgsmål på en million dollars!

Det meste af tidens testteam er altid belastet med for mange funktioner til at teste inden for begrænsede tidslinjer. I den begrænsede tidsperiode er der masser af testaktiviteter, der stammer fra den formelle proces, som også skal gennemføres. I sådanne situationer er ad-hoc-test slank.

Men fra min erfaring kan en runde ad hoc-test gøre underværker for produktkvaliteten og rejse mange designspørgsmål.

Da ad-hoc-testning mere er en 'vild-child' testteknik, der ikke behøver at være struktureret, er den generelle anbefaling, at den skal udføres, efter at udførelsen af ​​den aktuelle testspand er færdig. Et andet synspunkt er, at dette kunne gøres, når detaljeret test ikke kan udføres på grund af kortere tid.

Efter min mening vil jeg sige det ad-hoc-test kan udføres næsten når som helst - i begyndelsen, mod midten og mod slutningen! Det finder bare sit sted til enhver tid. Men når ad hoc-test skal udføres for at få maksimal værdi bedømmes bedst af en erfaren tester, der har indgående kendskab til det system, der testes.

Hvornår skal man ikke udføre?

Hvis det forrige spørgsmål var en million dollars værd, burde dette være en milliard værd!

Mens vi har fastslået, hvor effektiv og frugtbar ad hoc-test kan være, er vi som en dygtig og dygtig tester også nødt til at dechifrere, hvornår vi ikke skal investere i denne type test. Selvom det er efter testers skøn, her er nogle anbefalinger / eksempler, når det måske ikke er nødvendigt.

  • Undgå denne test, når der er en testtilfælde, for hvilken der er en mangel. I en sådan situation er der behov for at dokumentere fejlsagspunktet i testsagen og derefter kontrollere / gentest fejlen, når den er rettet. Derfor vil det ikke være anvendeligt her.
  • Der kan også være visse scenarier, hvor kunder eller kunder kan blive inviteret til test betaversionen af ​​softwaren . I sådanne tilfælde bør denne test ikke udføres.
  • Et andet scenario er, når der er en meget enkel brugergrænseflade, der tilføjes. Traditionel positiv og negativ testning skal være tilstrækkelig her for at frembringe maksimale mangler.

Typer af ad hoc-test

Ad-hoc-test kan kategoriseres i tre kategorier nedenfor:

# 1) Buddy Testing

I denne form for test vil der være et testmedlem og et udviklingsmedlem, der vælges til at arbejde på det samme modul. Lige efter udvikleren gennemfører enhedstesten , det testeren og udvikleren sidder sammen og arbejde på modulet. Denne form for test gør det muligt at se funktionen i et bredere omfang for begge parter.

Udvikleren får et perspektiv på alle de forskellige tests, som testeren kører, og testeren får et perspektiv på, hvordan det iboende design er, som hjælper ham med at undgå at designe ugyldige scenarier og derved forhindre ugyldige fejl. Det vil hjælpe den ene til at tænke som at tænke den anden.

# 2) Par test

I denne test arbejder to testere sammen på et modul med den samme testopsætning, der deles mellem dem. Ideen bag denne form for testning for at få de to testere til at brainstorme ideer og metoder til at have en række mangler. Begge kan dele testarbejdet og foretage den nødvendige dokumentation af alle observationer, der er foretaget.

# 3) Monkey Testing

Denne test udføres hovedsageligt på enhedstestniveau. Testeren analyserer data eller test på en helt tilfældig måde for at sikre, at systemet er i stand til at modstå eventuelle nedbrud. Denne test kan yderligere klassificeres i to kategorier:

hvad er en sikkerhedsnøglekode

Ad-hoc testfordele

Testning garanterer, at testeren med en masse magt er så kreativ som nødvendigt.

Dette øger testkvaliteten og effektiviteten som nedenfor:

  • Den største fordel, der skiller sig ud, er, at en tester kan finde antallet af defekter end ved traditionel test på grund af de forskellige innovative metoder, de kan anvende til at teste softwaren.
  • Denne form for test kan anvendes hvor som helst i SDLC; det er ikke kun begrænset til testteamet. Udviklerne kan også udføre denne test, som vil hjælpe dem med at kode bedre og også forudsige, hvilke problemer der kan opstå.
  • Det kan kombineres med en anden test for at få de bedste resultater, som nogle gange kan forkorte den nødvendige tid til den regelmæssige test. Dette vil gøre det muligt at generere testkvaliteter af bedre kvalitet og generelt bedre produktkvalitet.
  • Der kræves ikke nogen dokumentation, der forhindrer den ekstra byrde for testeren. En tester kan koncentrere sig om faktisk at forstå den underliggende arkitektur.
  • I tilfælde, hvor der ikke er meget tid til at teste, kan dette vise sig at være meget værdifuldt med hensyn til testdækning og kvalitet.

Ad-hoc test ulemper

Ad-hoc-test har også et par ulemper. Lad os se på nogle af de ulemper, der er udtalt:

Da det ikke er meget organiseret, og der ikke kræves nogen dokumentation, er det mest tydelige problem, at testeren skal huske og huske alle detaljerne i ad-hoc-scenarierne i hukommelsen. Dette kan være endnu mere udfordrende, især i scenarier, hvor der er meget interaktion mellem forskellige komponenter.

  • Efterfulgt af det første punkt ville dette også resultere i ikke at være i stand til at genskabe fejl i de efterfølgende forsøg, hvis de blev bedt om information.
  • Et andet meget vigtigt spørgsmål, dette bringer frem i lyset, er indsatsen ansvarlighed. Da dette ikke er planlagt / struktureret, er der ingen måde at redegøre for den tid og kræfter, der er investeret i denne form for test.
  • Ad-hoc-test skal kun udføres af en meget kyndig og dygtig tester i holdet, da det kræver at være proaktiv og intuition med hensyn til at forudse potentielle defekte ridte områder.

Bedste fremgangsmåder for at gøre denne test mere effektiv

Vi har diskuteret udførligt styrker og svagheder forbundet med denne test.

Ideelt set bør ad hoc-test finde sin plads i SDLC, men hvis det ikke kontaktes på den rette måde, kan det vise sig at være dyrt og spild af værdifuld testtid. Så nedenfor er et par punkter, der gør ad-hoc-test effektiv:

# 1) Identificer defekte udsatte områder:

Når du har et godt greb om at teste et bestemt stykke software, er du enig i, at der vil være visse funktioner, der er mere tilbøjelige til fejl end de andre. Hvis du er ny på systemet, skal du fortsætte med at kontrollere funktionerne v / s-mangler, der er åbnet mod dem.

Antallet af defekter i en bestemt funktion viser dig, at den er følsom, og du skal nøjagtigt vælge det område, der skal udføres ad hoc-test. Dette viser sig at være en meget tidseffektiv måde at afsløre nogle alvorlige mangler på.

# 2) Opbygning af ekspertise:

Utvivlsomt er en tester, der har mere erfaring, mere intuitiv og kan gætte, hvor fejlene kan være, sammenlignet med en, der ikke har meget erfaring. Jeg vil sige, erfaren eller ej, det er op til den enkelte at tage springet og bygge ekspertise på det system, der testes.

Ja, erfarne testere har en fordel, da deres færdigheder opbygget gennem årene kommer til nytte, men de nye testere bør bruge dette som en platform for at få så meget viden som muligt til at designe bedre ad hoc-scenarier.

# 3) Opret testkategorier:

Når du er opmærksom på listen over funktioner, der skal testes, skal du afsætte et par minutter til at beslutte, hvordan du vil kategorisere disse funktioner og teste. For eksempel, du skal beslutte at teste funktioner, der er mest synlige og mest brugt af brugeren før noget andet, da disse synes kritiske for softwarens succes.

Derefter kan du kategorisere dem funktionalitet / prioritetsmæssigt og teste dem segment for segment.

Et andet eksempel, hvor dette er særlig vigtigt, er hvis der er integration mellem komponenter eller moduler. I disse tilfælde kan der være mange abnormiteter, der kan opstå. Brug af kategorisering vil hjælpe med at berøre denne form for test mindst en eller to gange.

# 4) Har en grov plan:

Ja, ja dette punkt kan forvirre dig lidt, da vi beskrev ad hoc-test som test, der ikke burde have nogen planlægning eller dokumentation. Ideen her er at holde fast ved essensen af ​​ad-hoc-test, men alligevel have nogle grove pointer nedskrevet på, hvordan du planlægger at teste.

Et meget grundlæggende eksempel er, at du nogle gange måske ikke kan huske alle de tests, du har til hensigt at udføre. Så at notere dem ville sikre, at du ikke går glip af noget.

# 5) Værktøjer:

Lad os tage et eksempel, som vi alle ofte møder. Mange gange, hvis du observerer, er testningen af ​​funktionaliteten i sig selv vellykket uden nogen uoverensstemmelse rapporteret i dens adfærd. Imidlertid kunne logfilerne bag kulisserne rapportere om nogle undtagelser, som testere kunne gå glip af, da det ikke hæmmer testmålsætningen på nogen måde.

Disse kan have en høj grad af sværhedsgrad. Derfor er det meget vigtigt for os at lære og værktøjer, der hjælper med at lokalisere dette med det samme.

# 6) Dokument for flere mangler:

Igen forstår jeg, at dette kan hæve nogle øjenbryn igen. Dokumentation behøver ikke at være detaljeret, men kun en lille note til din egen reference til alle de forskellige scenarier, der er dækket, afvigelse i de involverede trin og registrere disse fejl for den bestemte kategori af testfunktioner.

Dette hjælper dig med at forbedre den samlede testspand, så du kan beslutte, hvordan du improviserer eksisterende testsager eller tilføjer flere, hvis det er nødvendigt.

Konklusion

Vi har diskuteret detaljeret om ad hoc testteknikker - dets styrker, svagheder, situationer hvor det ville og ikke ville være gavnligt.

Dette er en testteknik, der garanterer at imødekomme og tilfredsstille en testers kreativitet maksimalt. I min helhed testkarriere , Jeg opnår den største tilfredshed med ad-hoc-test, da der ikke er nogen grænse for at være innovative, og du kun ender med at blive mere vidende.

Når det er sagt, ville det vigtigste at tage tilbage fra alle ovenstående oplysninger være at bestemme, hvordan du kan bruge ad hoc-teststyrker og få det til at tilføre værdi til den samlede testproces og produktkvalitet.

Om forfatteren: Dette er en gæsteartikel af Sneha Nadig. Hun arbejder som en testleder med over 7 års erfaring i manuelle og automatiseringstestprojekter.

Udfører du ad hoc-test på dit projekt? Hvad er dine forslag for at gøre Ad-hoc-test vellykket?

Anbefalet læsning

^