Meny

Ad-hoc-testing: Hvordan finne feil uten en formell testprosess

ad hoc testing how find defects without formal testing process

Prøv Instrumentet Vårt For Å Eliminere Problemer

Selve begrepet ad-hoc innebærer mangel på struktur eller noe som ikke er metodisk. Når du snakker om ad-hoc testing , betyr det at det er en form for a svart boks eller atferdstesting utført uten noen formell prosess på plass.

Den formelle prosessen betyr her å ha dokumentasjon som kravdokumenter, testplaner, testtilfeller og riktig testplanlegging når det gjelder tidsplanen og rekkefølgen på utførte tester. Også handlinger utført under testingen er vanligvis ikke dokumentert.

Ad-hoc testing

Dette gjøres hovedsakelig med det formål å prøve å avdekke mangler eller mangler som ikke kan fanges opp gjennom tradisjonelle eller formelle prosesser som følges under testsyklusen.

Som allerede forstått, ligger essensen av denne testingen i å ikke ha en formell eller strukturert måte å teste på. Når en slik type tilfeldige testteknikker utføres, er det tydelig at testerne utfører dette uten særlig bruk i tankene med sikte på å bryte systemet.

Derfor er det definitivt enda mer åpenbart at en slik intuitiv eller kreativ testmetodikk krever testeren for å være ekstremt dyktig, dyktig og ha inngående kunnskap om systemet. Ad-hoc-testing sikrer at testingen som er utført er fullført og er spesielt veldig nyttig for å bestemme effektiviteten til testbøtta.

Anbefalt lesing=> Utforskende testing - Hvordan tenke utover tradisjonelle testgrenser?

Hva du vil lære:

La oss starte med et ad-hoc-testeksempel

Her er et eksempel på hvordan vi kan utføre denne testen når det gjelder UI Wizard.

La oss si at du må lage en plan eller en mal for en slags oppgave som skal utføres ved hjelp av denne brukergrensesnittveiviseren. Veiviseren er en serie av vinduer som har brukerinndata som navn, beskrivelse osv.

Når veiviseren utvikler seg: si på et av rutene, brukerdata skal legges inn som involverer UI-veiviseren til å kaste en kontekst-popup-boks som legger til de tilknyttede dataene for å fullføre veiviseren og distribuere / aktivere veiviseren.

For å teste denne testeren utfører han sin vanlige testing, for eksempel:

den beste mobiltelefon spion app
  • Fullfør veiviseren med alle gyldige data og lag planen.
  • Avbryt veiviseren midtveis.
  • Rediger en opprettet plan gjennom veiviseren.
  • Slett den opprettet planen og se at det ikke er rester av den.
  • Angi en negativ verdi i veiviseren, og se de riktige feilmeldingene vises.

Nå, for eksemplet ovenfor her er noen testtilfeller for ad-hoc-tester som kunne utføres å avdekke så mange mangler som mulig:

  • Mens du prøver å legge til negative data, kan du legge til visse spesialtegn som ikke er begrenset for å se om de blir håndtert riktig. For eksempel, noen ganger begrenser ikke veivisere {eller (bukseseler, men i visse situasjoner kan dette komme i konflikt med kode basert på språket det er skrevet på, og forårsake svært upålitelig oppførsel.
  • En annen test er spesielt med hensyn til popup-vinduer. En bruker kan få pop-up til å starte og deretter prøve å trykke på tilbaketasten på tastaturet. Mange ganger har jeg observert at det å gjøre dette, gjør at bakgrunnsveiviseren forsvinner helt og hele brukerdataene som ble lagt inn til poenget der popup-vinduet ble lansert, er tapt!

Egenskaper ved ad-hoc-testing:

Hvis du noterer deg scenariene ovenfor, vil du se noe veldig tydelige kjennetegn ved denne typen testing.

De er:

  • De er alltid i tråd med testmålet. Imidlertid er det visse drastiske tester som er utført med den hensikt å bryte systemet.
  • Testeren må ha full kunnskap og bevissthet om systemet som testes. Resultatet av denne testingen finner feil som prøver å markere smutthullene i testprosessen.
  • Når man ser på de to ovennevnte testene, vil den naturlige reaksjonen på det være at - denne typen test kan utføres bare en gang, da det ikke er mulig for en omprøve med mindre det er en feil forbundet.

Når gjør vi ad hoc-testing?

Et million dollar spørsmål virkelig!

Det meste av tiden er testteamene alltid belastet med for mange funksjoner til å teste innen begrensede tidslinjer. I løpet av den begrensede tidsperioden er det mange testaktiviteter som kommer fra den formelle prosessen som også må fullføres. I slike situasjoner er ad-hoc-testing å finne veien inn i testingen slank.

Fra min erfaring kan en runde med ad hoc-testing imidlertid gjøre underverker for produktkvaliteten og heve mange designspørsmål.

Siden ad-hoc-testing mer er en 'villbarn' -teknikk som ikke trenger å være strukturert, er den generelle anbefalingen at den må utføres etter at den nåværende testbøtta er utført. Et annet synspunkt er at dette kan gjøres når detaljert testing ikke kan utføres på grunn av kortere tid.

Etter mitt syn vil jeg si det ad-hoc-testing kan gjøres nesten når som helst - i begynnelsen, mot midten og mot slutten! Den finner bare sin plass til enhver tid. Imidlertid, når ad hoc-testing må gjøres for å få frem maksimal verdi, vurderes det best av en erfaren tester som har inngående kunnskap om systemet som testes.

Når skal du ikke utføre?

Hvis det forrige spørsmålet var verdt en million dollar, burde dette være verdt en milliard!

Selv om vi har funnet ut hvor effektiv og fruktbar ad-hoc-testing kan være, må vi som en dyktig og dyktig tester også tyde når vi ikke skal investere i denne typen testing. Selv om det er etter testers skjønn, er det her noen anbefalinger / eksempler når det kanskje ikke er nødvendig.

  • Unngå denne testen når det er en testtilfelle der det foreligger en mangel. I en slik situasjon er det behov for å dokumentere feilsøkingsstedet for testsaken og deretter verifisere / re-teste feilen når den er løst. Derfor vil det ikke være aktuelt her.
  • Det kan også være visse scenarier der kunder eller kunder kan bli invitert til test betaversjonen av programvaren . I slike tilfeller bør ikke denne testen utføres.
  • Et annet scenario er når det er en veldig enkel UI-skjerm som legges til. Tradisjonell positiv og negativ testing bør være tilstrekkelig her for å få frem maksimale feil.

Typer av ad-hoc-testing

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

# 1) Buddy Testing

I denne testformen vil det være et testmedlem og et utviklingsmedlem som vil bli valgt for å jobbe med den samme modulen. Rett etter utvikleren fullfører enhetstesten , den tester og utvikler sitter sammen og jobbe med modulen. Denne typen testing gjør at funksjonen kan sees i et bredere omfang for begge parter.

Utvikleren vil få et perspektiv på alle de forskjellige testene testeren kjører, og testeren vil få et perspektiv på hvordan den iboende designen er, som vil hjelpe ham å unngå å designe ugyldige scenarier, og dermed forhindre ugyldige feil. Det vil hjelpe den ene til å tenke som å tenke den andre.

# 2) Paretesting

I denne testen jobber to testere sammen på en modul med samme testoppsett som deles mellom dem. Ideen bak denne formen for testing for å få de to testerne til å brainstorme ideer og metoder for å ha en rekke mangler. Begge kan dele testarbeidet og lage nødvendig dokumentasjon av alle observasjoner som er gjort.

# 3) Monkey Testing

Denne testingen utføres hovedsakelig på enhetstestnivå. Testeren analyserer data eller tester på en helt tilfeldig måte for å sikre at systemet tåler krasj. Denne testen kan videre klassifiseres i to kategorier:

hvordan du tester nettstedet i forskjellige nettlesere

Ad-hoc testfordeler

Testingen garanterer at testeren med mye kraft er så kreativ som nødvendig.

Dette øker testkvaliteten og effektiviteten som nedenfor:

  • Den største fordelen som skiller seg ut er at en tester kan finne antall feil enn i tradisjonell testing på grunn av de forskjellige innovative metodene de kan bruke for å teste programvaren.
  • Denne formen for testing kan brukes hvor som helst i SDLC; det er ikke bare begrenset til testteamet. Utviklerne kan også utføre denne testen, noe som vil hjelpe dem å kode bedre og også forutsi hvilke problemer som kan oppstå.
  • Det kan kombineres med en annen testing for å få de beste resultatene, som noen ganger kan forkorte tiden som er nødvendig for den vanlige testen. Dette vil gjøre det mulig å generere bedre kvalitetstester og bedre kvalitet på produktet i det hele tatt.
  • Det pålegges ingen dokumentasjon som skal forhindre den ekstra belastningen på testeren. En tester kan konsentrere seg om å faktisk forstå den underliggende arkitekturen.
  • I tilfeller hvor det ikke er mye tid til å teste, kan dette vise seg å være veldig verdifullt når det gjelder testdekning og kvalitet.

Ad-hoc testing ulemper

Ad-hoc-testing har også noen ulemper. La oss ta en titt på noen av ulemper som er uttalt:

Siden det ikke er veldig organisert og det ikke er noen dokumentasjon pålagt, er det mest tydelige problemet at testeren må huske og huske alle detaljene i ad-hoc-scenariene i minnet. Dette kan være enda mer utfordrende, spesielt i scenarier der det er mye interaksjon mellom forskjellige komponenter.

  • Følges fra det første punktet, vil dette også resultere i ikke å kunne gjenopprette feil i de påfølgende forsøkene hvis du blir bedt om informasjon.
  • Et annet veldig viktig spørsmål dette bringer frem i lyset er innsatsen ansvarlighet. Siden dette ikke er planlagt / strukturert, er det ingen måte å redegjøre for tid og krefter som er investert i denne typen testing.
  • Ad-hoc-testing må bare utføres av en meget kunnskapsrik og dyktig tester i teamet, da den krever å være proaktiv og intuisjon når det gjelder å forutse potensielle mangler.

Beste fremgangsmåter for å gjøre denne testen mer effektiv

Vi har diskutert sterke og svake sider ved denne testingen.

Ideelt sett bør ad hoc-testing finne sin plass i SDLC, men hvis det ikke blir kontaktet på riktig måte, kan det vise seg å være kostbart og bortkastet verdifull testtid. Så gitt nedenfor er noen tips for å gjøre ad-hoc-testing effektiv:

# 1) Identifiser utsatte områder:

Når du har et godt grep om å teste en bestemt programvare, vil du være enig i at det vil være visse funksjoner som er mer utsatt for feil enn de andre. Hvis du er ny i systemet, kan du fortsette og sjekke funksjonene v / s-mangler som er åpnet mot dem.

Antallet mangler i en bestemt funksjon vil vise deg at den er følsom, og du bør velge nettopp det området du vil utføre ad hoc-testing. Dette viser seg å være en veldig tidseffektiv måte å avsløre noen alvorlige mangler.

# 2) Byggekompetanse:

Utvilsomt er en tester som har mer erfaring mer intuitiv og kan gjette hvor feilene kan være, sammenlignet med noen som ikke har mye erfaring. Jeg vil si, erfaren eller ikke, det er opp til den enkelte å ta steget og bygge kompetanse på systemet som testes.

Ja, erfarne testere har et forsprang ettersom ferdighetene som er bygget opp gjennom årene, kommer til nytte, men de nye testerne bør bruke dette som en plattform for å få så mye kunnskap som mulig for å designe bedre ad hoc-scenarier.

# 3) Opprett testkategorier:

Når du er klar over listen over funksjoner som skal testes, setter du av noen minutter til å bestemme hvordan du vil kategorisere disse funksjonene og teste. For eksempel, du bør bestemme deg for å teste funksjoner som er mest synlige og som oftest brukes av brukeren før noe annet, da disse virker kritiske for programvarens suksess.

Deretter kan du kategorisere dem funksjonalitet / prioritert og teste dem segment for segment.

Et annet eksempel der dette er spesielt viktig er om det er integrasjon mellom komponenter eller moduler. I disse tilfellene kan det være mange avvik som kan oppstå. Å bruke kategorisering vil hjelpe til med å berøre denne typen test minst en eller to ganger.

# 4) Ha en grov plan:

Ja, ja dette punktet kan forvirre deg litt da vi beskrev ad hoc-testing som testing som ikke burde ha noen planlegging eller dokumentasjon. Ideen her er å holde seg til essensen av ad-hoc-testing, men likevel ha noen tøffe tips som er skrevet ned på hvordan du planlegger å teste.

Et veldig grunnleggende eksempel er at du noen ganger kanskje ikke kan huske alle testene du har tenkt å utføre. Så å notere dem ville sikre at du ikke går glipp av noe.

# 5) Verktøy:

La oss ta et eksempel som vi alle ofte møter. Mange ganger hvis du observerer, er testingen av funksjonaliteten i seg selv vellykket uten avvik rapportert i oppførselen. Imidlertid kan loggene bak kulissene rapportere om noen unntak som kan bli savnet av testerne, da det ikke hindrer testmålet på noen måte.

Disse kan være til og med høy i alvorlighetsgrad. Derfor er det veldig viktig for oss å lære og verktøy som kan hjelpe til med å finne ut dette umiddelbart.

# 6) Dokument for flere feil:

Igjen forstår jeg at dette kan heve noen øyenbryn igjen. Dokumentasjon trenger ikke å være detaljert, men bare et lite notat for din egen referanse til alle de forskjellige scenariene som er dekket, avvik i trinnene som er involvert, og registrer disse feilene for den aktuelle kategorien for testfunksjoner.

Dette vil hjelpe deg med å forbedre den samlede testbøtta, slik at du kan bestemme hvordan du skal improvisere eksisterende testsaker eller legge til flere om nødvendig.

Konklusjon

Vi har diskutert i detalj om ad-hoc-testteknikker - dets styrker, svakheter, situasjoner der det ville og ikke ville være gunstig.

Dette er en testteknikk som garanterer å imøtekomme og tilfredsstille en testers kreativitet maksimalt. I hele mitt testkarriere , Jeg får størst tilfredshet med ad-hoc-testing, da det ikke er noen grense for å være nyskapende, og du bare blir mer kunnskapsrik.

Når det er sagt, vil det viktigste å ta tilbake fra all informasjonen ovenfor være å bestemme hvordan du kan utnytte ad hoc-teststyrker og få det til å gi verdi til den totale testprosessen og produktkvaliteten.

Om forfatteren: Dette er en gjesteartikkel av Sneha Nadig. Hun jobber som en testleder med over 7 års erfaring i manuelle og automatiseringstestprosjekter.

Utfører du ad-hoc-testing på prosjektet ditt? Hva er dine forslag for å gjøre Ad-hoc-testing vellykket?

Anbefalt lesing

^