Ad-hoc-testing er en type programvaretesting som utviklere og programvareselskaper implementerer når de sjekker programvarens nåværende iterasjon. Denne formen for testing gir et større nivå av innsikt i programmet, og lokaliserer problemer som konvensjonell testing kanskje ikke kan synliggjøre.
Det er avgjørende at testteam har en fullstendig forståelse av ad hoc-testprosessen slik at de vet hvordan de kan omgå utfordringene og sørge for at teamet kan implementere denne teknikken.
Å vite nøyaktig hvordan ad-hoc-testing fungerer, og hvilke verktøy som kan lette implementeringen, lar en virksomhet kontinuerlig forbedre sine egne kvalitetssikringsprosedyrer. Den formelle testprosessen følger veldig spesifikke regler, noe som kan føre til at teamet savner visse feil – ad hoc-kontroller kan omgå disse blindsonene og raskt teste hver programvarefunksjon.
I denne artikkelen undersøker vi nøye ad-hoc-testing og hvordan du kan bruke den til din fordel når du utvikler et programvareprodukt.
Ad-hoc-testing Betydning: Hva er ad-hoc-testing?
Ad-hoc-testing er en kvalitetssikringsprosess som unngår formelle regler og dokumentasjon – som hjelper testere med å finne feil i applikasjonen som konvensjonelle tilnærminger ikke kan identifisere. Dette krever vanligvis omfattende kunnskap om programvaren før testing starter – inkludert en forståelse av programmets indre funksjoner. Disse ad-hoc-kontrollene tar sikte på å bryte applikasjonen på måter som reflekterer brukerinnspill, og tar hensyn til ulike potensielle situasjoner slik at utviklerne kan lappe eventuelle eksisterende problemer.
Mangelen på dokumentasjon er sentral i denne teknikken, som ikke inkluderer noen sjekkliste eller testtilfeller for å veilede testere på tvers av en applikasjons funksjoner. Ad-hoc-testing handler utelukkende om å teste programvaren på den måten et team bestemmer seg for er effektiv i det spesifikke øyeblikket. Dette kan ta forhåndseksisterende formelle tester i betraktning, men kan også bare innebære å gjennomføre så mange tester som mulig i den (sannsynligvis begrensede) tiden som er avsatt for denne teknikken.
1. Når og hvorfor trenger du å gjøre ad-hoc-testing i programvaretesting?
Hovedårsaken til at selskaper utfører ad-hoc-testing er på grunn av deres evne til å avdekke feil som tradisjonelle tilnærminger ikke kan finne. Dette kan være av en rekke årsaker, for eksempel konvensjonelle testtilfeller etter en spesielt standardisert prosess som ikke kan redegjøre for en applikasjons særegenheter.
Hver testtype kan tilby nye perspektiver og interessante tilnærminger til kvalitetssikring – dette viser også problemer med den vanlige teststrategien. For eksempel, hvis ad-hoc-testing kan identifisere en bekymring som teamets testtilfeller ikke adresserer, antyder dette at de kan dra nytte av å rekalibrere testmetodikken.
Testere kan utføre ad hoc-kontroller når som helst i testprosessen. Dette fungerer vanligvis som et supplement til tradisjonell (og mer formell) kvalitetssikring, og med dette i tankene kan testere utføre ad-hoc inspeksjoner mens kollegene deres gjennomfører mer formelle undersøkelser. Imidlertid kan de i stedet foretrekke å lagre ad-hoc-kontroller til etter den formelle testprosessen som en oppfølging som spesifikt retter seg mot potensielle blindsoner.
Ad-hoc-testing kan også være nyttig når tiden er spesielt begrenset på grunn av mangel på dokumentasjon – riktig tidspunkt avhenger av selskapet og dets foretrukne tilnærming.
2. Når du ikke trenger å gjøre ad hoc-testing
Hvis det ikke er tilstrekkelig tid til å utføre både ad-hoc og formell testing, er det viktig at teamet prioriterer sistnevnte, da dette sikrer betydelig testdekning – selv om det fortsatt er noen hull.
Hvis teamets formelle tester finner feil som krever fiksing, er det generelt bedre å vente til etter at utviklerne har fullført de nødvendige endringene for å vedta ad hoc-kontroller. Ellers kan resultatene de leverer snart bli utdaterte, spesielt hvis testene er relatert til komponenten som allerede opplever feil.
I tillegg til dette må ad-hoc-testing skje før beta-teststadiet.
3. Hvem er involvert i ad-hoc-testing?
Det er flere nøkkelroller involvert i ad-hoc-testprosessen, inkludert:
• Programvaretestere er de viktigste teammedlemmene som utfører ad hoc-kontroller. Hvis du vedtar kompis- eller partesting, vil flere av disse testerne jobbe sammen på de samme komponentene.
• Utviklere kan selvstendig bruke disse kontrollene før det formelle kvalitetssikringsstadiet for raskt å inspisere sin egen programvare, selv om dette er i mindre dybde enn dedikert ad-hoc-testing.
• Team- eller avdelingsledere godkjenner den overordnede teststrategien – hjelper testerne med å bestemme når de skal begynne ad hoc-testing og hvordan de skal utføre den uten å forstyrre andre kontroller.
Fordeler med ad hoc-testing
Fordelene med ad-hoc-testing i programvaretesting inkluderer:
1. Raske oppløsninger
Siden disse testene ikke involverer hyppig dokumentasjon før, under eller etter kontrollene, er det mulig for team å identifisere problemer mye raskere. Denne enkelheten gir testerne enorm frihet.
For eksempel, hvis de tester en komponent og ikke kan identifisere noen feil, kan teamet ganske enkelt gå videre til neste test uten å notere dette i et dokument.
2. Kompletterer andre testtyper
Ingen teststrategi er perfekt, og 100 % dekning er vanligvis umulig å oppnå – selv med en omfattende tidsplan. Det vil alltid være hull i konvensjonell testing, så det er viktig at bedrifter integrerer flere tilnærminger.
Ad-hoc-testing har spesifikt som mål å finne problemene som formell testing ikke kan dekke – og garanterer en bredere total testdekning.
3. Fleksibel utførelse
Ad hoc-testing kan skje når som helst i kvalitetssikringsprosessen før betatesting, slik at selskaper og team kan bestemme når det er best å utføre disse kontrollene. De kan velge å utføre ad-hoc-tester i takt med konvensjonelle tester eller kan vente til etterpå – uansett hva, drar teamet nytte av valgene de har til rådighet.
4. Større samarbeid
Utviklere er mer involvert i denne prosessen enn mange andre former for testing – spesielt hvis selskapet bruker kompis- og partesting.
Som et resultat får utviklerne bedre innsikt i sine egne applikasjoner og kan kanskje adressere feil til en høyere standard. Dette bidrar til å forbedre programvarens generelle kvalitet ytterligere.
5. Ulike perspektiver
Ad-hoc-testing kan vise applikasjonen fra nye vinkler, og hjelpe testere til å engasjere seg i disse funksjonene på nye måter. Ytterligere perspektiver er kritiske gjennom testingen, da formelle kontroller ofte har minst mindre hull.
Hvis ad-hoc-testere bruker programvaren med den spesifikke hensikten å bryte den, vil de lettere kunne finne programmets grenser.
Utfordringer ved ad hoc-testing
Ad-hoc testprosessen har også flere utfordringer, som:
1. Vanskeligheter med å rapportere
Mangelen på dokumentasjon gjør ad-hoc-testing mye raskere, men kan også gjøre rapportering vanskelig for noe annet enn et stort problem.
For eksempel kan en tidligere utført sjekk bli mer relevant på et senere tidspunkt til tross for at det i utgangspunktet ikke fører til signifikante resultater. Uten omfattende dokumentasjon kan teamet kanskje ikke forklare disse testene.
2. Mindre repeterbar
På samme måte kan det hende at testerne ikke er helt klar over den nøyaktige tilstanden som er nødvendig for å forårsake reaksjonene de observerer. For eksempel kan det hende at en ad-hoc-sjekk som returnerer en feil ikke har tilstrekkelig informasjon til at teamet kan iverksette tiltak. De kan være uvitende om hvordan de skal gjenta denne testen og få samme resultat.
3. Krever programvareerfaring
Siden hastighet er nøkkelen gjennom ad-hoc-testing og det vanligvis innebærer å prøve å bryte applikasjonen, er det viktig at disse testerne har en intim forståelse av dette programmet.
Å vite hvordan det fungerer gjør at testerne kan bryte og manipulere programvaren på flere måter, men dette kan øke ferdighetskravene for ad-hoc-testing betydelig.
4. Begrenset ansvarlighet
Mangel på dokumentasjon kan forårsake flere problemer enn bare dårlig rapportering; det kan også utilsiktet forlenge testprosessen, og påvirke nytten av raske individuelle ad-hoc-tester.
Testere kan slite med å holde oversikt over fremgangen deres uten tilstrekkelig dokumentasjon gjennom hvert trinn. Dette kan til og med føre til at de gjentar en sjekk som andre testere allerede har fullført.
5. Gjenspeiler kanskje ikke brukeropplevelsen
Målet med praktisk talt alle testtyper er å gjøre rede for feil som påvirker sluttbrukere på en eller annen måte. Ad-hoc-testing er først og fremst avhengig av en erfaren tester som prøver å etterligne en uerfaren bruker, og dette bør være konsistent på tvers av hver sjekk til og med deres forsøk på å bryte applikasjonen.
Egenskaper ved ad-hoc-tester
Hovedkarakteristikkene til vellykkede ad-hoc-tester inkluderer:
1. Undersøkende
Hovedprioriteten for ad-hoc-testing er å identifisere feil med applikasjonen ved å bruke teknikker som konvensjonelle kontroller ikke tar hensyn til. Ad hoc-undersøkelser gjennomsøker denne programvaren med det uttrykkelige formålet å finne hull i teamets testprosedyre, inkludert dekningen av testsakene deres.
2. Ustrukturert
Ad hoc-kontroller har vanligvis ingen fast plan utover å gjennomføre så mange tester som mulig utenfor de typiske grensene for formell kvalitetssikring. Testere vil vanligvis gruppere kontrollene etter komponent for enkelhets skyld, men selv dette er ikke nødvendig – de kan til og med utarbeide kontrollene mens de utfører dem.
3. Erfaringsdrevet
Ad-hoc-testere bruker sin eksisterende programvareerfaring for å vurdere hvilke tester som vil gi størst fordeler og adressere vanlige blinde flekker ved formell testing.
Selv om testprosessen fortsatt er fullstendig ustrukturert, bruker testerne kunnskapen om tidligere ad-hoc-kontroller mens de bestemmer strategien deres.
4. Omfattende
Det finnes ingen eksakte veiledninger for hvilke kontroller teamet skal kjøre under ad-hoc-testing, men de dekker vanligvis en rekke komponenter – muligens med mer fokus på applikasjonens mer sensitive aspekter. Dette hjelper testerne med å garantere at eksamenene deres er i stand til å komplettere formell testing fullt ut.
Hva tester vi i ad-hoc-tester?
Kvalitetssikringsteam tester vanligvis følgende under ad-hoc-testing:
1. Programvarekvalitet
Disse kontrollene tar sikte på å identifisere feil i applikasjonen som konvensjonell testing ikke kan avdekke; dette betyr at prosessen hovedsakelig tester applikasjonens generelle helse.
Jo flere feil som ad-hoc-testing kan finne, jo flere forbedringer kan utviklere implementere før deadline.
2. Testtilfeller
Ad-hoc-testing implementerer vanligvis ikke testtilfeller – og dette er spesifikt slik at teamet kan undersøke hvor effektive de er til å gi god dekning. Testtilfellene er sannsynligvis utilstrekkelige hvis ad-hoc-kontroller kan finne feil som konvensjonelle testprosesser ikke kan.
3. Testpersonell
Målet kan også være å sjekke testteamets ferdigheter og kunnskaper, selv om testsakene er tilstrekkelige. For eksempel kan deres metodikk for å implementere sakene være utilstrekkelig, og ad-hoc-testing kan være avgjørende for å løse de resulterende hullene i testdekningen.
4. Programvaregrenser
Ad-hoc-testing søker også å forstå applikasjonens grenser – for eksempel hvordan den reagerer på uventede innganger eller høy systembelastning. Testerne kan spesifikt undersøke programmets feilmeldinger og hvor godt denne applikasjonen fungerer når den er under betydelig press.
Rydder opp litt forvirring:
Ad-hoc testing og utforskende testing
Noen mennesker anser ad-hoc og utforskende testing for å være synonymt, selv om sannheten er mer komplisert enn dette.
1. Hva er utforskende testing?
Utforskende testing refererer til kvalitetssikringsprosedyrer som undersøker programvaren fra et helhetlig synspunkt og spesifikt kombinerer oppdagelses- og testprosessene til én enkelt metode. Dette er vanligvis en mellomting mellom fullstendig strukturert testing og ad-hoc-kontroller i fritt format.
Utforskende testing fungerer best i spesifikke scenarier, for eksempel når rask tilbakemelding er nødvendig eller hvis teamet må ta tak i kantsaker. Denne typen testing når vanligvis sitt fulle potensial når teamet bruker skripttesting ved siden av.
2. Forskjeller mellom Exploratory Testing
og ad hoc-testing
Det største skillet mellom ad-hoc og utforskende testing er førstnevntes bruk av dokumentasjon for å registrere og lette sine kontroller, mens ad-hoc-testing unngår dette helt. Utforskende testing legger mer vekt på testfrihet, men aldri på samme nivå som en ad-hoc-tilnærming som er helt ustrukturert.
Utforskende testing innebærer også å lære om applikasjonen og dens indre funksjoner under disse kontrollene – ad-hoc-testere har i stedet ofte en omfattende kunnskap om programvarens funksjonalitet før de begynner.
Typer ad-hoc-tester
Det er tre hovedformer for ad-hoc-testing i programvaretesting, inkludert:
1. Apetesting
Den kanskje mest populære typen ad-hoc-testing, apetester er de som involverer et team som tilfeldig ser på forskjellige komponenter.
Dette skjer vanligvis under enhetstestprosessen og gjennomfører en rekke kontroller uten noen testtilfeller. Testerne undersøker dataene uavhengig på helt ustrukturerte måter, og lar dem undersøke det bredere systemet og dets evne til å motstå intens belastning fra brukerinndata.
Å observere resultatet av disse uskriptede teknikkene hjelper testteamet å identifisere feil som andre enhetstester har gått glipp av på grunn av mangler i konvensjonelle testmetoder.
2. Buddy testing
I en ad-hoc-sammenheng bruker vennetester minst to ansatte – vanligvis en tester og en utvikler – og finner først og fremst sted etter enhetstestfasen . «kompisene» jobber sammen på samme modul for å finne feil. Deres mangfoldige ferdighetssett og omfattende erfaring gjør dem til et mer effektivt team, noe som bidrar til å lindre mange av problemene som oppstår på grunn av mangel på dokumentasjon.
Utvikleren kan til og med foreslå en rekke av testene selv, slik at de kan identifisere komponentene som kan trenge mer oppmerksomhet.
3. Partesting
Partesting er lik ved at det involverer to ansatte, men dette er vanligvis to separate testere, hvorav den ene utfører selve testene mens den andre tar notater.
Selv uten formell dokumentasjon, kan notater gjøre at teamet uformelt kan holde oversikt over individuelle ad-hoc-kontroller. Rollene som tester og skribent kan byttes avhengig av testen, ellers kan paret beholde sine tildelte roller gjennom hele prosessen.
Testeren som har mer erfaring er vanligvis den som utfører de faktiske kontrollene – selv om de alltid deler arbeidet med hverandre.
Manuelle eller automatiserte ad-hoc-tester?
Automatisert testing kan hjelpe team med å spare enda mer tid gjennom hele kvalitetssikringsfasen; som lar testerne få plass til flere sjekker i timeplanen. Selv uten en bestemt struktur er det viktig at testere jobber for å maksimere dekningen og automatisering oppmuntrer til mer dyptgående inspeksjoner av denne programvaren.
Automatiserte ad-hoc-kontroller er generelt mer nøyaktige enn manuelle tester på grunn av deres evne til å unngå menneskelige feil under utenatlige oppgaver – dette er spesielt nyttig når du utfører de samme testene på forskjellige iterasjoner. Suksessen til denne prosedyren avhenger vanligvis av det automatiserte testverktøyet som teamet velger og dets funksjonalitet.
Imidlertid har automatisert testing visse begrensninger. For eksempel er hovedstyrken til ad-hoc-testing dens evne til å etterligne brukerinndata og utføre tilfeldige kontroller etter hvert som testeren kommer opp med dem. Disse testene kan miste sin tilfeldighet hvis organisasjonens testprogram sliter med komplekse kontroller.
Tiden det tar å automatisere disse svært spesifikke oppgavene kan også begrense de typiske tidsbesparelsene ved denne prosessen. Det er viktig at teamene undersøker de tilgjengelige automatiseringsverktøyene grundig for å finne et som matcher bedriftens prosjekt.
Hva trenger du for å starte ad hoc-testing?
Her er hovedforutsetningene for ad hoc-testing:
1. Kvalifisert personale
Ettersom ad-hoc-tester er raske, tilfeldige inspeksjoner av programvarens indre funksjon, hjelper det vanligvis å ha testere som har erfaring med programvaren. De bør også ha praktisk kunnskap om viktige testprinsipper – dette lar dem enkelt identifisere de mest effektive kontrollene.
2. En ustrukturert tilnærming
Testere må være villige til å forlate sine vanlige strategier for ad hoc-testing; denne tankegangen er like kritisk som selve kvalitetskontrollene. Denne metoden kan bare lykkes uten struktur eller dokumentasjon, og det er viktig at testerne husker dette på alle trinn.
3. Automatiseringsprogramvare
Selv om ad-hoc-testing er mer avhengig av å teste tilfeldige innganger og forhold, er automatisering fortsatt en veldig effektiv teknikk i enhver sammenheng.
Av denne grunn bør ad hoc-kontroller fortsatt implementere automatiserte testverktøy der det er mulig, ettersom riktig applikasjon kan effektivisere prosessen betydelig.
4. Andre former for testing
Ad-hoc-tester fungerer best sammen med andre kontroller som tar en mer formell tilnærming – og hjelper teamet med å garantere betydelig dekning på tvers av programvaren. Det er viktig at testerne blander ulike teknikker, selv om dette kan være før, under eller etter at de fullfører ad-hoc-testing.
Ad-hoc testprosess
De vanlige trinnene som testere bør følge når de utfører ad-hoc-testing i programvaretesting er:
1. Definere ad-hoc testmål
Dette stadiet er begrenset på grunn av mangel på dokumentasjon og struktur, men det er fortsatt viktig at teamet har et klart fokus. Testerne kan begynne å dele vage ideer om hvilke kommende tester som skal kjøres og komponentene som skal prioriteres.
2. Velge ad-hoc testteamet
Ettersom teamet brainstormer en rekke potensielle ad-hoc-sjekker, finner de også ut hvilke testere som vil være best for denne typen testing. De velger vanligvis testere som forstår applikasjonen inngående og kan også koble dem til en utvikler.
3. Utføre ad hoc-tester
Etter å ha bestemt hvilke testere som er riktige for dette stadiet, begynner disse teammedlemmene sine kontroller på et avtalt tidspunkt i testingen. Målet deres er å utføre så mange av ad-hoc-kontrollene som mulig – som testerne kanskje ikke har utviklet før dette stadiet.
4. Evaluering av testresultatene
Etter å ha fullført testene (eller til og med mellom individuelle kontroller) vil testerne evaluere resultatene, men uten å formelt dokumentere dem i en testsak. Hvis de avdekker problemer med applikasjonen, registrerer de dem uformelt og diskuterer teamets neste trinn.
5. Rapportering av oppdagede feil
Når de har evaluert resultatene, må testerne informere utviklerne om feilene som finnes i programvaren, slik at de har god tid til å fikse dem før utgivelse.
Testteamet bruker også informasjonen til å finne ut hvordan de kan forbedre sine formelle testprosesser.
6. Retesting etter behov
Testteamet vil sannsynligvis gjenta ad-hoc-prosessen for nye iterasjoner av applikasjonen for å sjekke hvor godt den håndterer oppdateringer. Ettersom testerne vil ha fikset mange av de tidligere identifiserte hullene i testsakene, kan fremtidige ad-hoc-kontroller kreve en annen tilnærming.
Beste praksis for ad hoc-testing
Det er visse praksiser som testteam bør implementere under ad-hoc-testing, inkludert:
1. Målrett potensielle testhull
Mens ad-hoc-testing innebærer mye mindre planlegging enn andre typer, har teamet fortsatt som mål å løse mangler i kvalitetssikringen. Hvis ad-hoc-testerne mistenker noen spesifikke problemer med teamets testtilfeller, bør de prioritere dette mens de utfører sine kontroller.
2. Vurder automatiseringsprogramvare
Automatiseringsstrategier som hyperautomatisering kan tilby mange fordeler for selskaper som ønsker å gjennomføre ad-hoc-tester.
Suksessen til dette avhenger av flere nøkkelfaktorer, inkludert verktøyet som virksomheten velger, samt den generelle kompleksiteten til ad-hoc-testene deres.
3. Ta omfattende notater
Mangelen på dokumentasjon i ad-hoc-testing er hovedsakelig for å strømlinjeforme denne prosessen ytterligere – teamet kan ha nytte av å lage uformelle notater mens de fortsetter. Dette gir testerne en klar oversikt over disse kontrollene og resultatene deres, og øker deres generelle repeterbarhet.
4. Fortsett å finpusse testene
Ad-hoc-testere forbedrer kontinuerlig sin tilnærming for å ta hensyn til endringer i teamets teststrategi. Når de for eksempel ser på nyere versjoner av selskapets programvare, kan de justere disse sjekkene som svar på nyere og mer inkluderende formelle testsaker.
7 feil og fallgruver ved implementering
Ad-hoc tester
Som med enhver testprosess, er det et bredt spekter av potensielle feil som teamet bør jobbe for å unngå, for eksempel:
1. Uerfarne testere
For å opprettholde det forventede tempoet for ad-hoc testing, må teamlederen tildele testere basert på kunnskapen og ferdighetene de har. Mens mange former for testing kan imøtekomme kvalitetssikringspersonale på nybegynnernivå, krever ad-hoc-kontroller teammedlemmer som fullt ut forstår programvaren; gjerne med erfaring i å kjøre disse testene.
2. Ufokuserte sjekker
Ad hoc-testing kan forbedre testdekningen betydelig på grunn av det raskere tempoet – teamet trenger ikke fylle ut omfattende dokumentasjon før og etter hver sjekk.
Ad-hoc-testerne må imidlertid fortsatt ha et sterkt fokus; for eksempel kan de bestemme seg for å prioritere visse komponenter med større risiko for feil.
3. Ingen planlegging
Å unngå enhver plan overhodet kan begrense effektiviteten til ad hoc-testing. Til tross for den ustrukturerte karakteren til denne tilnærmingen, er det viktig at teamet har en grov ide om hvilke tester som skal kjøres før de begynner.
Tiden er begrenset under denne prosessen, og å vite hvordan du går frem kan gi mange fordeler.
4. Altfor strukturert
På den motsatte enden av spekteret er denne tilnærmingen vanligvis avhengig av mangel på planlegging, da dette hjelper testere med å aktivt undergrave testtilfeller og finne skjulte feil.
Ad hoc-testing er også kjent som tilfeldig testing, og å tvinge en struktur på den kan forhindre at disse sjekkene finner feil.
5. Ingen langsiktige endringer
Hensikten med ad-hoc testing er å identifisere eventuelle svakheter i teamets testcases; dette undersøker deres overordnede strategi like mye som selve programvaren.
Dette betyr imidlertid at ad-hoc-tester vanligvis bare er effektive hvis teamet bruker denne informasjonen til å avgrense sine formelle kontroller over tid.
6. Inkompatible datasett
Praktisk talt alle former for testing krever en form for simulerte data for å vurdere hvordan applikasjonen reagerer; noen verktøy lar testere automatisk fylle et program med falske data .
Dette gjenspeiler imidlertid kanskje ikke hvordan en bruker vil engasjere seg i programvaren – ad hoc-kontroller krever datasett som programvaren sannsynligvis vil møte.
7. Informasjonssiloer
Det er viktig at testerne og utviklerne er i konstant kommunikasjon med hverandre, selv om sistnevnte ikke er en del av ad-hoc testprosessen.
Dette hjelper alle med å forstå hvilke tester som er utført – viser de neste handlingene som må utføres, samtidig som det forhindrer testerne i å unødvendig gjenta visse kontroller.
Typer utdata fra ad-hoc-tester
Ad-hoc-kontroller produserer flere forskjellige utganger, inkludert:
1. Testresultater
De individuelle testene gir forskjellige resultater spesifikke for den eksakte komponenten og tilnærmingen som er involvert – dette kan ha mange former.
Det er vanligvis testerens ansvar å avgjøre om resultatene utgjør en feil, selv om mangel på dokumentasjon gjør det vanskelig å sammenligne dette med deres forventninger. Teamet sender disse resultatene til utviklerne hvis de oppdager problemer.
2. Testlogger
Selve programvaren bruker et komplisert system med interne logger for å overvåke brukerinndata og fremheve en rekke fil- eller databaseproblemer som kan dukke opp.
Dette kan peke mot en intern feil, inkludert den spesifikke delen av programvaren som forårsaker problemet. Med denne informasjonen kan ad hoc-testere og utviklere løse problemene de oppdager mye lettere.
3. Feilmeldinger
Mange ad-hoc-kontroller tar spesifikt sikte på å bryte programvaren og avsløre dens grenser, noe som betyr at applikasjonens feilmeldinger er en av de vanligste resultatene fra disse testene.
Ved bevisst å forårsake feilmeldinger, kan teamet vise frem hva den gjennomsnittlige sluttbrukeren ser når de uventede handlingene de tar har en negativ effekt på programmets drift.
Eksempler på ad hoc-testing
Her er tre ad-hoc testscenarier som viser hvordan et team kan implementere det for forskjellige applikasjoner:
1. E-handel webapplikasjon
Hvis et selskap ønsker å teste en e-handelsbasert nettapp, kan de bruke ad-hoc-testing – spesielt apetesting – for å se hvor godt plattformen håndterer uventede brukerinteraksjoner.
Testerne kan ha som mål å presse hver funksjon til sine grenser, for eksempel ved å legge varer i kurven i urealistiske mengder eller prøve å kjøpe produkter som er utsolgt. De er ikke begrenset av teamets testtilfeller, og det er få grenser for hvilke kontroller de kan utføre; testerne kan til og med prøve å fullføre kjøp ved å bruke utdaterte nettadresser.
2. Desktop-applikasjon
Ad-hoc-testere kan også implementere disse teknikkene for skrivebordsapplikasjoner med mulig fokus på forskjellige maskiner og hvor godt de passer til programmet.
Teammedlemmene kan utføre disse kontrollene gjentatte ganger for å se hvordan endring av maskinvare- eller programvareinnstillinger påvirker en applikasjons generelle ytelse. For eksempel kan et spesifikt grafikkort slite med å gjengi grensesnittet.
Alternativt kan disse testerne ganske enkelt gi programmet umulige inndata og se hvordan det reagerer, for eksempel om det kan vise feilmeldinger som forklarer problemet tilstrekkelig for sluttbrukeren.
3. Mobilapplikasjon
En måte ad-hoc-testere kan undersøke en mobilapplikasjon på er å teste sikkerhetsprotokollene – de kan for eksempel prøve å få direkte tilgang til appens utviklingsverktøy.
Teamet kan prøve å se om de er i stand til å utføre uautoriserte handlinger ved å finne vanlige smutthull og utnyttelser; de kan spesifikt be ansatte med erfaring innen appsikkerhet om å legge til rette for dette.
Dette kan også innebære partesting med utviklerne på grunn av deres innsikt i appens design, la en tester bryte programvaren og vise nøyaktig hvor sikkerheten mangler.
Typer feil og feil oppdaget
gjennom ad hoc-testing
Ad hoc-kontroller kan avdekke mange problemer med et program, for eksempel:
1. Funksjonsfeil
Å bruke ad-hoc-testing for å undersøke en applikasjons grunnleggende funksjoner kan avsløre alvorlige feil som påvirker hvordan sluttbrukere kan engasjere seg i den.
For eksempel vil apetesting av betalingsalternativene til en e-handelsside illustrere forholdene som forhindrer transaksjonen.
2. Ytelsesproblemer
Testerne kan spesifikt jobbe med å skape ytelsesproblemer i programmet – for eksempel ved å fylle databasen med ulike spam-inndata.
Dette kan manifestere seg som betydelig forsinkelsestid eller til og med generell programvareustabilitet, som sannsynligvis vil føre til en (potensielt systemomfattende) krasj.
3. Brukervennlighetsproblemer
Disse kontrollene kan også synliggjøre feil med grensesnittet og den generelle brukeropplevelsen. Brukergrensesnittet til en mobilapp kan for eksempel vises annerledes på et annet operativsystem eller skjermoppløsning. Et dårlig grensesnitt kan føre til at brukere sliter med å betjene denne applikasjonen.
4. Sikkerhetsfeil
Den tilfeldige karakteren til ad-hoc-testing gjør at den kan dekke en rekke vanlige og sjeldne sikkerhetsproblemer; en tester kan bruke disse sjekkene for å finne et programs administrative bakdører.
Alternativt kan inspeksjonen deres vise at programvaren ikke har datakryptering.
Vanlige ad hoc-testmålinger
Ad-hoc-testing bruker ulike beregninger for å lette resultatene, inkludert:
1. Defektdeteksjonseffektivitet
Denne beregningen ser på hvor effektiv testprosessen er til å finne defekter på tvers av hver form for testing, inkludert ad-hoc-testing. Defektdeteksjonseffektivitet er prosentandelen oppdagede defekter delt på det totale antallet problemer – som viser hvor effektive testene er.
2. Testdekningsgrad
En hjelpefunksjon ved ad-hoc-testing er å øke dekningen ved å sjekke komponenter på en måte som testtilfeller ikke tar hensyn til. Dette betyr at testerne også vil ha som mål å radikalt øke testdekningen på tvers av hver sjekk så mye de kan.
3. Total testvarighet
Ad hoc-testing er mye raskere enn andre kvalitetssikringsprosesser – og det er viktig at testerne jobber for å opprettholde denne fordelen. Testvarighetsmålinger viser teammedlemmer hvordan de kan spare tid og forsterke fordelene med ad-hoc-strategier ytterligere.
4. Krasjfrekvens
Disse testene tar ofte sikte på å bryte programvaren og forårsake en krasj eller alvorlig feil – slik at de kan gå utover typiske teststrategier og finne uventede problemer. For dette formål kan det hjelpe å vite hvor ofte programvaren krasjer og hva som forårsaker disse problemene.
5 beste ad-hoc-testverktøy
Det er mange gratis og betalte testverktøy tilgjengelig for ad-hoc-testing i programvaretesting – de fem beste er som følger:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST er et omfattende programvaretestingsprogram som gir et sterkt nivå av test + RPA- funksjonalitet i både gratis- og bedriftsversjoner.
Denne fullstack-programvareautomatiseringen + RPA Suite tillater full testing på forskjellige stasjonære og mobile plattformer; programvarens 1SCRIPT-teknologi lar også brukere utføre de samme sjekkene gjentatte ganger med letthet. På toppen av dette utnytter verktøyet toppmoderne datasyn , som gjør det mulig for ZAPTEST å kjøre ad-hoc-tester fra et menneskelig perspektiv.
2. BrowserStack
BrowserStack er en skyplattform som kan forenkle testing på over 3000 forskjellige maskiner, med tilleggsfunksjonen til å automatisere Selenium-skript. Selv om det gir sterk dekning for programvareprosjekter, fungerer det best med nettleser- og mobilapplikasjoner .
BrowserStack-testløsninger inkluderer også en gratis prøveversjon med 100 minutter med automatisert testing – selv om dette kan ha begrenset bruk.
Selv om den skybaserte tilnærmingen kan være nyttig, påvirker den også plattformens responstid negativt.
3. LambdaTest
LambdaTest bruker på samme måte skybasert teknologi og legger stor vekt på nettlesertesting som kan begrense effektiviteten for andre applikasjoner – selv om den fortsatt passer godt med iOS- og Android -programmer. Dette er en nyttig plattform når skalerbarhet er et problem og integreres med mange andre testhostingtjenester.
Noen brukere har imidlertid blandede reaksjoner på applikasjonens priser på tvers av de forskjellige ikke-prøvealternativene som er tilgjengelige, noe som potensielt begrenser tilgjengeligheten for mindre organisasjoner.
4. TestRail
TestRail er generelt ganske tilpasningsdyktig på grunn av å kjøre helt i nettleseren, og til tross for et sterkt fokus på effektive testtilfeller, kan de også skryte av direkte ad-hoc-funksjonalitet. Analysene den gir etter hver test kan også hjelpe team som aktivt unngår å lage sin egen uavhengige dokumentasjon samtidig som de lar dem validere testprosessen.
Større suiter kan imidlertid slite med det nettleserbaserte formatet, noe som kan begrense tidsbesparelsen ved ad-hoc-testing med en betydelig margin.
5. Zephyr
Zephyr er en testadministrasjonsplattform fra SmartBear som hjelper kvalitetssikringsteam med å forbedre testsynligheten samtidig som de integreres godt med annen programvare for feilsporing.
Denne funksjonen er imidlertid begrenset til visse applikasjoner, med Confluence og Jira som de som drar mest nytte av Zephyr – disse er kanskje ikke de mest effektive løsningene for alle bedrifter. Det er flere skalerbare programmer tilgjengelig under Zephyr-merket til forskjellige priser.
Sjekkliste for ad-hoc-testing, tips og triks
Her er flere tips som team kan ta hensyn til når de utfører ad-hoc-tester:
1. Prioriter sensitive komponenter
Noen funksjoner eller komponenter er naturlig nok mer utsatt for feil enn andre, spesielt hvis de er viktige for programmets generelle funksjon.
Hver tilnærming til testing bør identifisere de delene av en applikasjon som kan dra nytte av mer grundig oppmerksomhet. Dette er spesielt nyttig når den totale tiden for testing er begrenset.
2. Undersøk ulike testverktøy
Verktøyet som en organisasjon implementerer for å lette testene sine, kan påvirke dekningen og påliteligheten til disse kontrollene.
Med ad-hoc-testing er det verdt å se på så mange programmer som mulig for å finne de som passer det brukersentriske aspektet. Programvare som bruker datasynsteknologi, som ZAPTEST, kan nærme seg ad-hoc-tester ved å bruke en menneskelignende strategi.
3. Vedta en ad hoc-tankegang
Ad-hoc-testing gir enorm frihet gjennom hele kvalitetssikringsfasen, men teamet må forplikte seg til det for å motta strategiens viktigste fordeler.
For eksempel bør ad-hoc-testere unngå alle sine vanlige dokumenter utover grunnleggende notattaking, og de må inspisere programvaren fra et helt nytt perspektiv.
4. Stol på testing av instinkter
Erfaring med ad-hoc-testing eller generelle programvaresjekker kan bidra til å fremheve vanlige feilpunkter, og dette hjelper testerne med å finne ut hvordan de skal oppdage feil av alle typer.
Det er viktig at testere stoler på instinktene deres og alltid bruker denne kunnskapen til deres fordel – de kan finne ut hvilke ad hoc-kontroller som vil være mest nyttige.
5. Registrer fullstendig oppdagede feil
Selv om ad-hoc-testing ikke har noen formell dokumentasjon og for det meste er avhengig av uformelle notater, er det fortsatt viktig at teamet er i stand til å identifisere og kommunisere årsaken til en programvarefeil.
De må logge all informasjon testen gir som er relevant for utviklere, for eksempel potensielle årsaker til disse problemene.
6. Ta alltid hensyn til brukeren
Hver form for testing har til hensikt å imøtekomme brukerens generelle opplevelse til en viss grad – og ad-hoc-testing er intet unntak. Selv om den ofte ser dypere på applikasjonens indre funksjoner og til og med dens interne kode, bør ad-hoc-testere prøve å bryte denne programvaren på måter som brukere teoretisk kunne.
7. Forbedre prosessen kontinuerlig
Testteam bør avgrense sin tilnærming til ad-hoc-testing mellom flere iterasjoner av samme programvare og fra ett prosjekt til det neste.
De kan samle inn tilbakemeldinger fra utviklere for å se hvor godt ad-hoc-testene deres hjalp kvalitetssikringsstadiet og om de klarte å øke testdekningen betydelig.
Konklusjon
Ad-hoc-testing kan hjelpe organisasjoner av alle slag med å autentisere sin programvareteststrategi, men måten de implementerer denne teknikken på kan være en viktig faktor for effektiviteten.
Å balansere ulike testtyper er nøkkelen til å få mest mulig utbytte av ad-hoc-kontroller – spesielt siden denne formen for testing har til hensikt å utfylle de andre ved å fylle et strategisk gap.
Med en applikasjon som ZAPTEST er det mulig for team å gjennomføre ad-hoc-tester med større selvtillit eller fleksibilitet, spesielt hvis de implementerer automatisering. Uansett teamets spesifikke tilnærming, kan deres forpliktelse til ad hoc-testing revolusjonere hele programmet eller prosjektet.
