Hva er Adhoc-testing? Typer med eksempel

Hva er ad hoc-testing?

Ad hoc-testing er en spontan og fleksibel måte å teste programvare uten å følge noen fastlagt plan eller dokumentasjon. I stedet for å forberede testtilfeller på forhånd, dykker du rett inn og begynner å utforske applikasjonen. Begrepet «ad hoc» betyr «for et bestemt formål» eller «uplanlagt», noe som virkelig gjenspeiler denne teststilen.

La meg si det enkelt. Tenk deg at jeg nettopp har installert en ny app på enheten min. I stedet for å krysse av i en liste med testtrinn, begynner jeg å trykke påping rundt. Jeg kan prøve å legge inn merkelige data, bruke appen på uventede måter, eller til og med prøve å avbryte flyten med vilje. Målet mitt her er å se hvordan appen håndterer virkelig, uforutsigbar bruk– ikke bare de ideelle scenariene.

Ad-hoc-testing skiller seg ut fordi den ofte avdekker problemer som formelle tester kan overse. Ved å tenke kreativt og sette meg inn i forskjellige brukeres situasjoner, kan jeg finne bugs og brukervennlighet problemer som andre kan overse. Denne metoden er avhengig av testernes intuisjon, erfaring, og en dyp forståelse av applikasjonen. Det er en fin måte å oppdage feil tidlig, spesielt når tiden er knapp eller dokumentasjonen er begrenset.

Selv om ad hoc-testing kan virke uformell, kommer den virkelige verdien fra testerens ekspertise og evne til å tenke utenfor boksenDet blir ofte sett på som en type svart boks testing siden den fokuserer på hvordan programvaren oppfører seg på overflaten, ikke hvordan den er bygget under. Brukt sammen med strukturert testing, bidrar Adhoc-testing til å sikre en mer pålitelig og brukervennlig produkt.

Følgende video viser deg hvordan du utfører Adhoc-testing.

Klikk her. hvis videoen ikke er tilgjengelig

Når skal man utføre ad hoc-testing?

Å vite det beste tidspunktet å utføre ad hoc-testing kan utgjøre en stor forskjell i kvaliteten på programvaren din. Gjennom årene har jeg lært at timing er nøkkelen til denne fleksible og spontane testtilnærmingen. Ad hoc-testing passer perfekt når du raskt trenger å sjekke for problemer som strukturerte testtilfeller kan overse. La oss utforske de viktigste situasjonene når ad hoc-testing er mest verdifull:

• Tidlig i utviklingen: Det fungerer bra når formelle testtilfeller ikke er klare ennå. Du kan raskt oppdage feil i nye funksjoner før de offisielle testplanene er opprettet.
• Før den offisielle testingen starter: Bruk ad hoc-testing som en rask skanning for å sikre at det grunnleggende fungerer. Dette bidrar til å forhindre at man kaster bort tid på ødelagte bygg under formelle testsykluser.
• Etter fullført formell testing: Selv etter å ha fulgt alle testtilfeller, kan noen feil fortsatt slippe gjennom. Ad hoc-testing lar deg lete etter feil som strukturert testing kan overse, spesielt de som ligger utenfor de dokumenterte kravene.
• Når du har lite tid: Noen ganger er det rett og slett ikke nok tid til en fullstendig testrunde. I slike tilfeller kan erfarne testere bruke ad hoc-testing for å finne de viktigste problemene raskt.
• For å utforske en funksjon i dybden: Hvis du virkelig vil forstå hvordan en bestemt del av programvaren oppfører seg, lar Ad Hoc-testing deg undersøke fritt uten å holde deg til et manus.
• For brukervennlighetskontroller: Du kan sette deg inn i brukerens sted for å se om det er noen forvirrende eller frustrerende deler av programvaren. Dette bidrar til å forbedre den generelle opplevelsen.
• Under betatesting: Mange betatestere bruker naturlig nok ad hoc-testing når de tester programvaren i reelle situasjoner, og avdekker problemer som bare dukker opp i bruk i den virkelige verden.

Typer ad hoc-testing

Ad hoc-testing følger kanskje ikke en formell plan, men over tid har det dukket opp flere nyttige stiler. Dette er ikke strenge kategorier, men de gjenspeiler hvordan testere tilpasser seg basert på reelle behov. Etter min erfaring kan bruk av disse metodene i riktig situasjon avdekke skjulte feil raskere og mer effektivt.

• Buddy testing: Denne metoden kobler en utvikler og en tester til å jobbe side om side. Utvikleren forklarer hvordan funksjonen ble bygget. I mellomtiden utforsker testeren den fra brukerens perspektiv. Denne blandingen av kodekunnskap og testferdigheter bidrar til å fange opp problemer tidlig, ofte rett etter at kodingen er avsluttet.
• Partesting: To testere jobber sammen på samme enhet. Den ene utforsker appen, mens den andre foreslår forskjellige innspill og observerer atferd. De bytter på å dele notater. Dette samarbeidet i sanntid øker kreativiteten og finner ofte flere feil enn testing alene.
• Apetesting: Dette er den mest uforutsigbare tilnærmingen. En tester eller et verktøy klikker, skriver eller navigerer tilfeldig gjennom appen. Målet er å presse systemet til det slutter å virke. Selv om dette kan virke kaotisk, er det en fin måte å finne krasj eller svake punkter på. Bare husk at det kan være vanskelig å reprodusere feil som finnes på denne måten.

Hver av disse tilnærmingene har sin egen styrke. Å velge den rette avhenger av prosjektets behov, teamdynamikken og hvor raskt tilbakemelding er nødvendig. Ut fra det jeg har sett, kan en kombinasjon av disse metodene få det beste ut av ad hoc-testing – å avdekke problemer som skriptbasert testing kan overse.

Fordeler med ad-hoc-testing

Adhoc-testing tilbyr en unik verdi som strukturert testing ofte går glipp av. Den er fleksibel, rask og er avhengig av testerens instinkter snarere enn faste prosedyrer. Min erfaring er at denne typen testing er en kraftig følgesvenn til formelle metoder, spesielt i utviklingsmiljøer med rask utvikling.

• Avdekker skjulte feil: Uten begrensningene til forhåndsdefinerte testtilfeller utforsker den uventede veier der feil ofte gjemmer seg.
• Raskt og enkelt oppsett: Ikke behov for detaljerte testplaner eller dokumentasjon, noe som sparer mye tid når rask tilbakemelding er nødvendig.
• Kostnadseffektivt når tiden er knapp: Ideelt for situasjoner der ressursene er begrensede, men kritiske feil fortsatt må finnes raskt.
• Innsikt fra virkelige brukere: Fordi testere oppfører seg som sluttbrukere, kan testprosessen fremheve brukervennlighetsfeil som formelle tester kan overse.
• Bruker testerens intuisjon: Dyktige testere kan stole på sin erfaring for å avdekke subtile feil som verktøy eller skript kan overse.
• Forbedrer formell testing: Den erstatter ikke formell testing. I stedet gir den et ekstra lag med trygghet ved å utvide testdekningen.
• Øyeblikkelig tilbakemeldingsløkke: Spesielt nyttig i smidige oppsett der feil må finnes og fikses raskt for å holde ting i gang.

Ulemper med ad-hoc-testing

Ad hoc-testing har flere begrensninger som kan påvirke både testkvaliteten og produktresultatet. La meg forklare disse tydelig ut fra min egen testerfaring.

• Vanskelig å reprodusere feil: Siden det ikke finnes noen strukturert tilnærming eller trinnvis oversikt, kan det være vanskelig å gjenskape et problem. Dette gjør det vanskeligere for utviklere å løse problemet.
• Avhenger av testerens erfaring: Hvor vellykket denne metoden er, avhenger mye av hvor dyktig eller kjent testeren er med produktet. En nybegynner kan overse viktige feil som en erfaren tester ville oppdage.
• Ingen full testdekning: Ad hoc-testing følger ikke en planlagt vei. Det betyr at noen viktige områder kan bli stående utestet uten at noen merker det før det er for sent.
• mangler Tracking og målinger: Uten testtilfeller eller logger er det vanskelig å måle fremgang, identifisere mønstre eller forstå hva som har blitt testet. Dette reduserer synligheten for team og interessenter.
• Ikke egnet for høyrisikoapplikasjoner: Prosjekter innen helsevesen, bankvirksomhet eller sikkerhetskritiske systemer krever grundig dokumentasjon og validering. Ad hoc-testing alene oppfyller ikke disse strenge standardene.
• Kan kaste bort tid uten fokus: Hvis testeren ikke har i det minste uformelle mål, kan de ende opp med å bruke for mye tid på å utforske lavprioriterte funksjoner. Dette forsinker den generelle testsyklusen.

Beste praksis for effektiv ad hoc-testing

For å maksimere fordelene med ad hoc-testing til tross for dens uformelle natur, bør du vurdere disse fremgangsmåtene som bygger bro mellom ustrukturert utforskning og pålitelig defekttesting. trackonge:

1) God forretningskunnskap

Testere bør ha god kunnskap om virksomheten og en klar forståelse av kravene. Detaljert kunnskap om hele forretningsprosessen vil bidra til å finne feil enkelt. Erfarne testere finner flere feil ettersom de er bedre til å gjette feil.

2) Testnøkkelmoduler

Viktige forretningsmoduler bør identifiseres og målrettes for ad-hoc-testing. Forretningskritiske moduler bør testes først for å få tillit til systemets kvalitet.

3) Registreringsfeil

Alle feil må registreres eller skrives i en notisblokk. Feil må tilordnes utviklere for utbedring. For hver gyldig feil må tilsvarende testtilfeller skrives og legges til planlagte testtilfeller.

Disse Defekt funn bør gjøres som lærdom og disse bør gjenspeiles i vårt neste system mens vi planlegger testcaser.

4) Par opp

Som sett i Buddy eller partesting, samarbeid kan bringe frem ulike perspektiver og forbedre feildeteksjon.

Eksempler på Adhoc-tester

Adhoc-testing handler om å utforske en applikasjon uten en fast plan. I stedet for å følge skript, stoler vi på intuisjon og tidligere erfaring. Jeg har ofte funnet denne tilnærmingen nyttig når jeg prøver å fange opp uvanlige eller uventede feil som skriptede tester kan overse.

• Stresstest av påloggingsfunksjonen: En tester logger gjentatte ganger inn og ut med forskjellige påloggingsinformasjoner, noen feil, for å se om systemet krasjer eller reagerer merkelig.
• Uvanlig brukerinndata: Å legge inn symboler, ekstremt lange strenger eller uventede filformater for å sjekke hvordan systemet reagerer. Det hjelper med å finne ut hvor godt validering av inndata håndteres.
• Tilfeldige klikk og navigasjon: Testeren klikker seg tilfeldig gjennom appen – hoppping mellom sider, utløse knapper i feil rekkefølge – for å oppdage uventet atferd.
• Kaos ved filopplasting: Laster opp filtyper som ikke støttes eller som er ødelagte for å teste robustheten til opplastingsfunksjonen.
• Avbruddstesting: Avbryte en prosess (som å lukke en fane midt i lagring eller kutte internettforbindelsen) for å se hvordan systemet gjenoppretter seg.

Sammenlignende analyse med utforskende testing

Selv om de ofte blandes sammen, viser ad hoc-testing og utforskende testing distinkte driftsparametere:

Karakteristisk	Ad hoc-testing	Utforskende testing
Teknisk dokumentasjon	Kun etter utførelse	Kontinuerlig innspilling
Planlegging	none	Lett charterbasert
Sesjonsstruktur	Helt ustrukturert	Tidsbestemte iterasjoner
Reproduksjon av feil	33 % reproduserbarhet	78 % reproduserbarhet
Automatisering Integrasjon	Begrenset anvendelighet	42 % verktøyinnarbeidelse

Spørsmål og svar