Ad hoc-testing
Ad hoc-testing er en uformell eller ustrukturert programvaretestingstype som tar sikte på å bryte testprosessen for å finne mulige feil eller feil på et tidlig mulig stadium. Ad hoc-testing utføres tilfeldig, og det er vanligvis en ikke-planlagt aktivitet som ikke følger noen dokumentasjon og testdesignteknikker for å lage testsaker.
Ad hoc-testing følger ingen strukturert måte å teste på, og det gjøres tilfeldig på noen del av applikasjonen. Hovedmålet med denne testingen er å finne feil ved tilfeldig kontroll. Adhoc-testing kan oppnås med Software testing-teknikken kalt Error Guessing. Feilgjetting kan gjøres ved at folk har nok erfaring på systemet til å "gjette" den mest sannsynlige feilkilden.
Denne testingen krever ingen dokumentasjon / planlegging / prosess som skal følges. Siden denne testingen tar sikte på å finne feil ved tilfeldig tilnærming, uten dokumentasjon, vil mangler ikke bli kartlagt for å teste tilfeller. Dette betyr at det noen ganger er veldig vanskelig å reprodusere feilene, ettersom det ikke er noen testtrinn eller krav som er kartlagt til den.
Følgende video guider deg hvordan du gjør adhoc-testing
Klikk her hvis videoen ikke er tilgjengelig
Når utfører Adhoc-testing?
Ad hoc-testing kan utføres når det er begrenset tid til å gjøre forseggjorte tester. Vanligvis utføres adhoc-testing etter den formelle gjennomføringen av testen. Og hvis tiden tillater det, kan ad hoc-testing gjøres på systemet. Ad hoc-testing vil bare være effektiv hvis testeren er kjent med systemet under test.
Typer Adhoc-testing
Det finnes forskjellige typer Adhoc-tester, og de er oppført som nedenfor:
| Buddy Testing | To kompiser jobber gjensidig med å identifisere feil i samme modul. For det meste kommer en kompis fra utviklingsteamet og en annen person fra testteamet. Buddy testing hjelper testerne med å utvikle bedre testsaker, og utviklingsteamet kan også gjøre designendringer tidlig. Denne testingen skjer vanligvis etter at enhetstesting er fullført. |
| Par testing | To testere får tildelt moduler, deler ideer og jobber på de samme maskinene for å finne feil. En person kan utføre testene, og en annen person kan notere funnene. Rollene til personene kan være tester og skribent under testing. Sammenligning Buddy and Pair Testing: Buddy testing er en kombinasjon av enhet- og systemtesting sammen med utviklere og testere, men Paretesting gjøres bare med testere med forskjellige kunnskapsnivåer. (Erfarne og ikke-erfarne til å dele sine ideer og synspunkter) |
| Monkey Testing | Test produktet eller applikasjonen tilfeldig uten testtilfeller med et mål å bryte systemet. |
Beste fremgangsmåter for Adhoc-testing
Å følge beste praksis kan sikre effektiv Adhoc-testing.
God forretningskunnskap
Testere bør ha god kjennskap til virksomheten og ha en klar forståelse av kravene - Detaljert kunnskap om sluttprosessen vil hjelpe til med å finne feil lett. Erfarne testere finner flere mangler ettersom de er bedre til å gjette feil.
Test nøkkelmoduler
Viktige forretningsmoduler bør identifiseres og målrettes for ad hoc-testing. Bedriftskritiske moduler bør testes først for å få tillit til kvaliteten på systemet.
Registrer feil
Alle feil må registreres eller skrives i et notisblokk. Mangler må tildeles utviklere for å fikse. For hver gyldig mangel må tilsvarende testsaker skrives og må legges til planlagte testsaker.
Disse funnfunnene bør gjøres etter hvert som de har lært, og disse bør gjenspeiles i vårt neste system mens vi planlegger for testtilfeller.
Konklusjon:
Fordelen med Ad-hoc-testing er å kontrollere om testingen er fullstendig og finne flere feil enn planlagt testing. Mangelfangstprøvesakene blir lagt til som ytterligere testtilfeller til de planlagte prøvesakene.
I programvareutvikling sparer Ad-hoc-testing mye tid ettersom det ikke krever omfattende testplanlegging, dokumentasjon og testkassedesign.