Utforskende testing er en spesifikk type programvaretesting som har mange fordeler for en applikasjon, slik at den kan nå sitt fulle potensial.
Måten et team integrerer utforskende testing på i rutinekontrollene sine, kan til og med avgjøre hvor godt programvaren fungerer, spesielt ettersom dette nærmer seg testprosedyrene på nye og uventede måter. Dette hjelper testere med å avdekke problemer i applikasjonen som ellers kan gå ubemerket hen til lansering og føre til at nøkkelfunksjoner ikke fungerer.
Å forstå prosessene, typene og tilnærmingene til utforskende testing kan hjelpe deg med å lede organisasjonen og dens testteam om hvordan de skal innlemme det i deres vanlige kontroller.
Det finnes også en rekke gratis verktøy teamet kan bruke for å lette disse inspeksjonene og legge merke til problemer før de potensielt blir veisperrer for utvikling.
I denne veiledningen viser vi frem fordelene med utforskende testing sammen med de viktigste hensynene et team bør vurdere før implementering.
Hva er utforskende testing?
Utforskende testing kombinerer testdesign- og utførelsesstadiene, og sikrer fullstendig operativ frihet for testeren og lar dem kontinuerlig strømlinjeforme arbeidet sitt.
Når disse teamene sjekker programvaren, vil de sannsynligvis oppdage nye komponenter som krever grundige inspeksjoner og kan lett komme opp med nye tester som vil være til nytte for applikasjonen.
Utforskende testing ligner på ad hoc-testing, men følger mye mer streng dokumentasjon, og inkluderer også en mer aktiv læringsprosess.
Den mindre strukturerte tilnærmingen hjelper testere med å finne ut hvordan en applikasjon sannsynligvis vil reagere på realistiske scenarier og testtilfeller og fungerer som et viktig supplement til skripttesting.
Kvaliteten på et teams utforskende testing avhenger ofte av ferdighetene til individuelle testere, da kontrollene krever kreativitet og en grundig forståelse av programvaren. Dette er en prosess med kontinuerlig oppdagelse – en der testere bruker deduktiv resonnement for å veilede deres generelle teknikk.
Utforskende testing er spesielt nyttig fordi den gjenspeiler hvordan brukere kan bruke programvaren. De fleste brukere finner feil og problemer ved et uhell, så disse uskriptede prosessene kan hjelpe testere med å finne problemer som forhåndsbestemte kontroller kanskje ikke avdekker.
Det er også mulig for et team å automatisere denne prosedyren for å sikre et høyere effektivitetsnivå.
1. Når må du gjøre Exploratory Testing?
Utforskende testing er generelt nyttig på tvers av nesten alle programvaretestingsprosesser, selv om den utmerker seg spesielt ved å gi rask tilbakemelding om en applikasjon.
Teamet kan også inkludere disse sjekkene hvis de går tom for skripttester. Uten en klar retning for programvareinspeksjonene deres, kan utforskende testing bidra til å avdekke problemer som passer utenfor standardsjekkene.
Å sikre ulike testprosedyrer lar testerne forstå denne programvaren på et langt dypere nivå på et hvilket som helst stadium, men å utføre dem tidlig kan gi flere fordeler.
Det er mulig for team å gjennomføre utforskende tester på nytt senere etter behov for ekstra trygghet.
2. Når du ikke trenger å gjøre Exploratory Testing
Det er noen få scenarier der utforskende testing ikke gir noen fordeler, selv om det kan være mer nyttig for testere å vente til programvaren har sin kjernefunksjonalitet.
Funksjonene til en applikasjon krysser eller samhandler typisk med hverandre, noe som betyr at utforskende tester på én funksjon kan være foreldet når utviklingsteamet legger til mer til denne programvaren.
Det er også mulig å gjennomføre disse testene sammen med skriptkontroller uten problemer, forutsatt at testerne kan sikre et sterkt nivå av dokumentasjon for å unngå forvirring.
Utforskende testing er svært allsidig sammenlignet med andre testtyper, noe som gjør disse kontrollene svært anvendelige.
3. Hvem er involvert i Exploratory Testing?
Utforskende testing involverer mange ansatte i noen henseende, inkludert:
• Programvaretestere på alle ferdighetsnivåer kan utføre disse testene, selv om teammedlemmer med en bedre forståelse av programvaren kan utforme et større utvalg av kontroller.
Erfaring kan også påvirke deres evne til å bestemme de mest nyttige testene.
• Programvareutviklere som anerkjenner resultatene av disse testene, vil reagere på eventuelle forslag og ofte utvikle sin egen løsning på problemet.
Deres svar på testene er det som gjør at applikasjonen kan nå en egnet tilstand for en vellykket utgivelse.
• Prosjektledere som overvåker hele denne prosessen og kan til og med være de som bestemmer hvilke testtyper teamene bruker.
De kan også være ansvarlige for å anskaffe programvare for teamene som kan strømlinjeforme eller til og med automatisere tester.
Exploratory Testing livssyklus
Den utforskende testprosessen har et sterkt fokus på testerfrihet, men følger likevel en bestemt struktur.
De tre viktigste stadiene i denne tilnærmingen er:
Trinn 1: Læring
Testere begynner med å utvikle en sterk forståelse av programvaren og dens funksjonalitet – kritisk analysere den for å finne ut hvordan den passer sammen.
Dette lar testeren finne ut de vanlige inndataene som en bruker kan gjøre, selv om de kanskje allerede er klar over applikasjonen og hvordan den fungerer.
Læringsstadiet kan til og med kreve en veiledning om hvordan du bruker programvaren. Dette er utforskningsstadiet og utstyrer testeren med all informasjonen som er nødvendig for at de skal kunne designe et omfattende utvalg nyttige tester.
Trinn 2: Testdesign
Utforskende testdesign involverer forskjellige regler og parametere, men gir fortsatt betydelig mer frihet sammenlignet med skripttesting – spesifikasjonene av disse er allerede kjent før testingen begynner.
Testeren kan utarbeide kontroller som de mener passer applikasjonen mer presist og kan potensielt avdekke verdifulle data for utviklingsteamet, inkludert bemerkelsesverdige feil som de kan fikse.
Testteam bruker dette stadiet til å finne ut hvilken tilnærming de skal ta og hvordan de skal fordele arbeidet mellom de ulike testerne på måter som spiller på deres styrker.
Trinn 3: Utførelse
Etter å ha utformet sjekkene som skal brukes, kan testerne nå inspisere applikasjonen på de måtene de mener er mest effektive – de kan utføre dette umiddelbart etter å ha utviklet den spesifikke testen.
Dette er stadiet der testere aktivt søker etter problemer og hvordan eventuelle problemer de avdekker kan inngå i andre funksjoner og funksjoner.
Selv om det er en viss grad av intuitivt arbeid involvert i utforskende testutførelser, følger det fortsatt fastsatte prosesser og mål, noe som gir mulighet for en flytende test som enkelt kan imøtekomme de spesifikke testmålene.
Utforskende vs. skripttesting
Utforskende testing er faktisk det motsatte av skripttesting, selv om begge kan være viktige for å sikre at en applikasjon er klar for utgivelse. Sistnevnte er vanligvis mer formell og strukturert, og omfatter mange brede tester sammenlignet med utforskende kontroller, som ofte er mer spesifikke for applikasjonens funksjonalitet.
Som en del av dette er utforskende testing også betydelig mer tilpasningsdyktig, mens skriptede tester kan slite dersom det skjer store endringer i programvaren. Utforskende tester kan avdekke feil og handle mot dem raskere, noe som gjør førstnevnte spesielt nyttig i tilfeller der rask tilbakemelding er avgjørende.
1. Aktiv utforskende testing
Aktiv utforskende testing innebærer at en tester designer et automatisert skript for sine sjekker, som en annen tester utfører. Disse skriptene tar de tidligere testene i betraktning hvis det er aktuelt.
De to testerne bytter vanligvis roller gjennom inspeksjonsprosedyren for å dobbeltsjekke påliteligheten til disse skriptene og prosessene.
Aktive tester har en bredere dekning uten å ofre varemerkespesifisiteten til utforskende kontroller. Disse skriptene gir også bedre dokumentasjon, noe som gjør det lettere å reprodusere eventuelle problemer som testerne finner.
Dokumentasjon er en viktig komponent i aktive tester, da dette også hjelper interessenter med å se applikasjonens generelle fremgang.
2. Passiv utforskende testing
Passiv utforskende testing krever bare én tester, selv om arbeid i par kan strømlinjeforme prosessen ytterligere.
Denne tilnærmingen involverer spesifikk programvare som registrerer testerhandlinger – gir dem enkle trinn for å replikere ethvert problem de avdekker. Dette er vanligvis i form av en video der testeren gir kommentarer som forklarer handlingene deres trinn for trinn.
Registrering av testprosessen gir også innsikt i applikasjonens ytelse, inkludert hvor raskt den svarer på inputforespørsler.
Passiv testing gir både testerne og utviklingsteamet et vell av detaljert informasjon om hvordan programvaren fungerer.
Utforskende testteknikker
Utforskende testing følger vanligvis et “tur”-format – der en tester utforsker programvaren på den mest effektive måten.
Det er forskjellige turer laget kan velge mellom, inkludert:
• Guidebokturer
Denne tilnærmingen prioriterer applikasjonens fremhevede funksjonalitet, og gjenskaper nøye hvordan en gjennomsnittlig bruker engasjerer seg i programvaren og avdekker problemer de naturlig ville finne.
• Historieturer
Denne omvisningen inspiserer applikasjonens eldste funksjoner for å sikre at de fortsatt fungerer; dette er spesielt viktig hvis utviklerne har lagt til nye funksjoner som er i konflikt med det.
• Pengetur
Denne utforskende testen sjekker de kritiske applikasjonsfunksjonene, spesielt de som kunder og klienter betaler penger for å få tilgang til – disse er vanligvis de høyeste prioriteringene blant testteamet.
• Kriminaltur
Testere jobber noen ganger aktivt for å bryte en applikasjon eller indusere negative scenarier, for eksempel ved å legge inn ugyldig informasjon og undersøke hvordan applikasjonen reagerer på dette.
• Omvisning i bakgaten
Denne prosessen involverer funksjoner som færre kunder sannsynligvis vil benytte seg av; disse er like viktige for enhver testmetode, spesielt siden de vil samhandle med andre funksjoner.
• Intellektuell omvisning
Denne omvisningen presser applikasjonen videre, og tester de mest kompliserte funksjonene med høyere (noen ganger maksimale) verdier for å bestemme programvarens behandlingshastighet.
Exploratory Testing tilnærminger
Det er to hovedtilnærminger til utforskende testing:
1. Sesjonsbasert utforskende testing
Dette er en tidsbasert teknikk som tar sikte på å kvantifisere testprosessen ved å dele denne inn i “økter” med to komponenter: oppdrag og charter.
Oppdraget er den spesielle øktens formål og varighet, og gir en utforskende tester et klart fokus.
Et charter angir omfanget av hver økt og beskriver eventuelle spesifikke mål som testeren har til hensikt å oppfylle. Dette resulterer i et høyere nivå av ansvarlighet (og dokumentasjon) ved å dele opp disse sjekkene i mer håndterbare komponenter.
Øktbaserte tester forbedrer også produktiviteten og gir en tester klare beregninger og feilsøkingsinformasjon.
2. Parbasert utforskende testing
Parbasert testing ligner på aktiv utforskende testing, da det først og fremst innebærer å jobbe i par – vanligvis på samme enhet – for kontinuerlig å sjekke applikasjonen samtidig. I denne ordningen foreslår en tester en rekke testtilfeller og fører notater om fremdriften mens den andre tester programvaren.
Kommunikasjon er essensielt gjennom parbasert testing, da dette sikrer at begge testerne er klar over sjekkene og deres formål.
Hvis du tildeler disse parene selv, sørg for å imøtekomme styrkene og svakhetene til hver tester, da dette lar deg bygge sterkere utforskende testprosesser.
Hvilke faktorer påvirker Exploratory Testing?
Faktorene som kan påvirke kvaliteten på et teams utforskende testing inkluderer:
• Programvarens overordnede mål og kjernefunksjonalitet.
• De spesifikke testmålene for en applikasjons nåværende fase.
• De individuelle rollene og evnene til hver tester på laget.
• Verktøyene som er tilgjengelige, for eksempel gratis programvare for å automatisere tester.
• Støtten som testerne får fra jevnaldrende eller ledelsen.
• Kundens ønsker og markedets nåværende brede trender.
• Applikasjonens brukervennlighet, for eksempel grensesnittets smidighet.
• Tiden testerne har til å fullføre testfasen.
• Inndataene og andre assorterte data testerne har til hensikt å bruke.
• Funksjonene som utviklere legger til programvaren over tid.
Typer utforskende testing
De tre hovedtypene av utforskende testing som et team kan inkludere er:
1. Freestyle Exploratory Testing
Freestyle-testing omfatter ad hoc-tilnærmingen til å sjekke en applikasjon. Dette har få regler å ta hensyn til, så effektiviteten kan variere; noen programvare og komponenter garanterer en mer robust metodikk.
Disse sjekkene kan fortsatt tilby mange fordeler ved å hjelpe testere med å gjøre seg kjent med denne applikasjonen og validere en tidligere testers arbeid.
Selv uten strenge regler kan erfarne og dyktige testere enkelt bruke dette til å formatere til sin fordel. De kan enkelt bevege seg gjennom alle aspekter av programvaren – i noen situasjoner er testreglene restriktive og kan utilsiktet begrense teamets resultater.
2. Scenariobasert utforskende testing
Scenariobasert testing bruker realistiske situasjoner som grunnlag for hver test, for eksempel ved å sjekke inndata som brukere sannsynligvis vil gjøre under denne programvarens typiske drift.
Testere jobber hardt for å sikre at hvert scenario de utarbeider stemmer overens med hvordan en bruker engasjerer seg i applikasjonen.
Tid kan være en begrensning ettersom teamets mål er å teste så mange scenarier som mulig; avhengig av tidsfristene fremover, vil dette sannsynligvis ikke kunne dekke alle muligheter.
Testere bør bruke et bredt spekter av tester på tvers av forskjellige kategorier.
3. Strategibasert utforskende testing
Strategibasert testing involverer et bredt spekter av spesifikke metoder, inkludert grenseverditesting, ekvivalensteknikker, risikobaserte teknikker og mer. Dette prioriterer generelt testere som allerede er kjent med applikasjonen, da de kan utvikle skreddersydde strategier som inkluderer disse individuelle metodene.
En strategibasert tilnærming fokuserer først og fremst på programvarens funksjonalitet (og indre funksjoner) uten å se på mulige scenarier som kan føre til at en bruker møter problemene som dukker opp. Dette kan resultere i en bredere analyse av en applikasjon og dens ulike funksjoner, potensielt i større dybde enn ulike andre tilnærminger.
Manuelle eller automatiserte utforskende tester?
Testteam kan utføre utforskende kontroller enten manuelt eller de kan automatisere dem. Begge alternativene har kapasitet til å tilby enorme fordeler; det riktige alternativet avhenger ofte av detaljene i prosjektet.
Manuell utforskende testing
Manuell utforskende testing gir mulighet for et større utvalg skreddersydde kontroller. Selv om dette kan ta lengre tid på grunn av at menneskelige testere er tregere enn datamaskiner, kan manuell inspeksjon være medvirkende til å bestemme brukeropplevelsen.
En tester fungerer ikke bare for å sikre at funksjonene til en applikasjon alle fungerer som de skal, men også for å finne ut om brukerbasen kan betjene den med letthet. Dette er kanskje den vanligste formen for utforskende testing – selv om dette ikke nødvendigvis gjør den mest effektiv.
1. Fordeler med å utføre utforskende tester manuelt
Fordelene med manuell utforskende testing inkluderer:
Sterkere fokus på brukervennlighet
Automatiserte utforskende tester kan oppdage avvik i programvaren, men kan kanskje ikke tolke disse problemene på samme måte som en menneskelig tester.
Dette inkluderer å forstå hvordan programvarens brukere sannsynligvis vil navigere eller samhandle med applikasjonen, noe automatisering ikke kan ta hensyn til.
Manuelle utforskende testere kan tilby et høyere nivå av tilbakemelding, inkludert spesifikke detaljer om hvordan problemene de finner påvirker den generelle programvaren eller den generelle opplevelsen.
Kan gjøre endringer i sanntid
En av hovedstyrkene til utforskende testing er at det er mulig å identifisere behovet for en test og utføre den relativt raskt før auksjonering av nødvendige forbedringer.
Automatisert testing er generelt en mye raskere prosess, men testere må vente til alt er fullført før de gjør endringer – manuelle testere kan gjøre dette mens den utforskende testprosessen fortsatt er i gang.
Dette er imidlertid ofte bare mulig for feil som påvirker mindre deler av programvaren.
Større oppmerksomhet på detaljer
Utforskende testing handler hovedsakelig om å oppdage nye måter å teste en applikasjon på samtidig som man forstår den; dette kan noen ganger bety at en test fører til en annen ved å gi ideer til testeren.
Automatiserte tester kan ikke ta hensyn til dette på grunn av at de er relativt hands-off for testteamet. Manuelle testere forbedrer kontinuerlig kunnskapen om programvaren og utarbeider nye, men like viktige tester – men dette kan være vanskelig hvis tredjepartsprogramvare automatiserer dem.
Kan finne feil utenfor koden
Manuelle utforskende kontroller lar testere se på alle fasetter av applikasjonen og programvaren, inkludert utover selve koden.
Mange automatiserte tilnærminger er begrenset til koden og hvordan den fungerer, noe som kan føre til at testteam ikke legger merke til problemer som kan dukke opp i andre deler av applikasjonen.
Dette avhenger hovedsakelig av automatiseringsprogramvaren du har, da noen løsninger kan tilby en bredere tilnærming til utforskende testing.
Sikrer kvalitet på tvers av prosjektet
Automatiserte utforskende kontroller ser kun etter feil og beregninger i applikasjonen; manuelle testere kan i stedet inspisere programvaren og gi sine egne omfattende tilbakemeldinger.
For eksempel kan de teste koden og finne ut at den er for kompleks – spesielt viktig ettersom død kode kan redusere ytelsen, men i praksis vil bli uoppdaget av automatiserte prosesser.
En testers kunnskap om programvaren kan være medvirkende til å diagnostisere problemer som dukker opp under andre testfaser.
2. Utfordringer ved manuell utforskende testing
Utfordringene med manuell utforskende testing inkluderer:
Mulighet for menneskelige feil
Automatisert utforskende testing kan kjøre nøyaktig samme sjekk så mange ganger som nødvendig uten endringer i den nøyaktige fremdriften, noe som sikrer konsistens og pålitelige resultater.
Manuell utforskende testing er sårbar for menneskelige feil, noe som betyr at testeren kan skrive inn feil verdi. Det er vanligvis mulig å dobbeltsjekke disse testene og fikse eventuelle avvik, da de kan virke åpenbare selv ved første øyekast.
Å gjøre om en test etter å ha oppdaget en feil kan imidlertid ta mer tid.
Generelt mer tidkrevende
Selv om testerne utfører hver utforskende sjekk riktig uten menneskelige feil, tar denne generelle prosessen en betydelig mengde tid sammenlignet med automatisert programvare som kan beregne testene mye raskere.
Dette kan være en forskjell på minst flere timer; tid som testere muligens kan bruke på deler av applikasjonen som ikke vil ha noen fordeler av automatisering.
Utforskende tester krever også konstant tilsyn, mens automatisering lar tester kjøre over natten.
Langvarig dokumentasjonsprosess
På samme måte kan manuell dokumentasjon under og etter den manuelle testingen være en unødvendig belastning på den utforskende testprosessen.
Dette gjør det vanskeligere å spore endringer og programvareredigeringer over tid – automatisert programvare er vanligvis i stand til å intuitivt ta hensyn til dette når du kjører tester.
Dette er et annet administrativt problem som tar tid og energi bort fra andre saker, noe som effektivt reduserer omfanget og bredden av den generelle programvaretestprosedyren.
Må kjenne programvaren inngående
Manuelle testere på alle ferdighetsnivåer kan inspisere applikasjonen og teste den grundig. Dette er på grunn av arbeidet de legger ned i å forstå programvaren – den første fasen av den utforskende prosessen.
Men hvis en tester sliter eller unnlater å lære hvordan denne applikasjonen fungerer, vil de sannsynligvis slite med å utarbeide og utføre et passende utvalg av tester.
Å kjenne programvaren godt lar testerne gå utover de vanlige testparametrene.
Kostbar å vedlikeholde
En avhengighet av manuell utforskende testing krever vanligvis et større testteam, noe som kan resultere i høyere langsiktige kostnader sammenlignet med automatiserte kontroller. Tredjepartsprogramvaren som utfører disse utforskende testene kan gi en enorm verdi eller kan til og med være helt gratis.
Avhengig av kompleksiteten til oppgavene, kan et selskap kreve svært dyktige testere med mange års erfaring for å sjekke søknaden fullstendig. Dette kan øke testutgiftene betydelig sammenlignet med bruk av gratis automatiseringsprogramvare.
3. Når skal man bruke manuell utforskende testing
Manuell utforskende testing kommer ofte med flere utfordringer, men er fortsatt en viktig del av grundig programvaretesting. Dette er fordi det er sider ved programvaren som automatisering ikke fullt ut kan ta hensyn til, som også krever et sterkt fokus.
For eksempel kan ikke programvare på en pålitelig måte gi tilbakemelding på brukergrensesnitt eller brukeropplevelsestester. Testere kan bare få et godt inntrykk av hvordan en applikasjon fungerer i praksis hvis de manuelt tester for den. Dette betyr at både utviklere og testteam må vurdere å integrere minst en viss grad av manuell utforskende testing i sjekkene sine.
Automatisert utforskende testing
Automatisert testing bruker tredjepartsprogramvare for å automatisere visse kontroller – testere kan vanligvis tilpasse dette for å imøtekomme praktisk talt alle tester.
Dette krever imidlertid vanligvis at teamet kjører sjekken manuelt minst én gang for å kalibrere automatiseringen. Dette kan effektivisere prosessen betydelig for både test- og utviklingsteam.
Selv om automatisering av utforskende tester kan være uvanlig, er det flere klare fordeler ved å gjøre dette for applikasjonen din og ytelsen.
1. Fordeler med Exploratory Test Automation
De viktigste fordelene med eksplorativ testautomatisering inkluderer:
Konsekvent testutførelse
Menneskelige feil kan lett føre til testfeil som tar både tid og penger å fikse; automatiserte utforskende kontroller lar testteam omgå dette problemet.
Testere lærer effektivt automatiseringsprogramvare hvordan de utfører en test på riktig måte, og sikrer at den utfører dette identisk hver gang. Dette forbedrer den generelle påliteligheten til testene og reduserer tiden utviklerne bruker på å vente på resultater – spesielt ettersom testere kan stille inn dette til å kjøre over natten med letthet.
Sparer tid for alle
Automatiserte tester lar utviklere begynne å jobbe med å løse problemer mye raskere, samtidig som de lar testerne dekke et bredere spekter av utforskende kontroller. Det er bare så mange scenarier som teamet kan gjøre rede for uansett tidsfrist, noe som betyr at det er viktig at testerne passer inn så mange sjekker som mulig i deres tillatte tidsramme.
Automatisering hjelper ved å utføre disse utforskende testene med en mye raskere hastighet enn manuelle testere.
En kostnadseffektiv tilnærming
Avhengig av programvaren teamet velger, kan automatisering være langt mer kostnadseffektiv enn manuell testing – dette kan til og med være gratis.
Mens manuelle testere fortsatt er kritiske å ansette, og noen av dem vil være ansvarlige for å kalibrere automatiseringsprosedyrene, gir automatisering av så mange utforskende tester som praktisk mulig selskapet en sjanse til å redusere personalkostnadene.
Når teamet forstår automatiseringsprogramvaren, kan de tilpasse den til et bredt spekter av oppgaver.
Kan tilpasses flere enheter
Manuell testing kan kreve ansatte med erfaring på tvers av ulike enheter, for eksempel kunnskap om ulike telefonoperativsystemer, inkludert Android og iOS hvis de bygger en mobilapplikasjon.
Automatisert programvare kan gjøre rede for dette og teste på tvers av flere enheter for å sikre at applikasjonen konsekvent kan fungere godt. Testing av team med kunnskap om disse enhetene kan finne prosessen kjedelig; automatisering er igjen i stand til å strømlinjeforme de vanlige utforskende testprosessene og teste hver iterasjon samtidig.
Gjenbrukbare skript
Hvis teamet tester flere versjoner av samme programvare eller til og med flere produkter med lignende arkitektur eller funksjoner, er det mulig å gjenbruke skript fra en testsyklus til den neste.
Hvis det er noen justeringer som er nødvendige for å sikre kompatibilitet, kan manuelle testere lage disse mye raskere enn å skrive et helt nytt skript.
Automatisering optimaliserer praktisk talt alle trinn i den utforskende testprosessen, og er enkel å sette opp gjennom ulike programvarekonfigurasjoner.
2. Utfordringer ved å automatisere utforskende tester
Denne prosessen innebærer også ulike utfordringer, som:
Representerer bare én side av testen
Det er ikke praktisk eller lurt å automatisere hver sjekk mens du tester applikasjonen fordi det er noen aspekter som bare en manuell tester kan gi tilbakemelding på pålitelig.
Dette inkluderer brukeropplevelsen, selv om det kan være mulig å få grundig ytelse og belastningstesting via automatisering, avhengig av programvaren du velger.
Utforskende testautomatisering mangler menneskelig dømmekraft og kan fungere best sammen med en manuell tester for noen kontroller.
Urealistiske forventninger til evner
På lignende måte kan automatiserte utforskende testprosedyrer gi enorme fordeler for en applikasjon ved siden av det overordnede prosjektet.
Denne tilnærmingen er imidlertid ikke alltid svaret. Organisasjoner som er avhengige av automatisering på hvert trinn, kan ha et ufullstendig perspektiv på programvaren.
Automatisering identifiserer problemer, men test- og utviklingsteamene er ansvarlige for å fikse dem. Det er viktig å definere en overordnet automatiseringsstrategi slik at alle i prosjektet forstår dets muligheter og begrensninger.
Høyere krav til ferdigheter
Automatisering innebærer vanligvis å vite hvordan man utfører komplekse kontroller, sammen med hvordan man programmerer og faktisk automatiserer dem. Dette krever ofte mange års erfaring med skripting, selv om automatiseringsprogramvare kan bidra til å optimalisere disse prosessene betydelig.
Det er avgjørende at selskapet rekrutterer testere med varierte og robuste ferdigheter for å tilrettelegge for effektiv automatisering.
Testere med erfaring innen automatisering vet også hvilke funksjoner de skal prioritere mens de velger fra tredjeparts programvarealternativer som er tilgjengelige, og sikrer at teamet får et godt produkt.
Feil strategier og kommunikasjon
Å kommunisere en sammenhengende strategi er avgjørende for all vellykket automatisering; utviklere, testere og til og med prosjektledere må være på samme side gjennom hele testingen.
Teamene må jobbe sammen for å identifisere omfanget og tidsplanen for deres kommende prosedyrer. Dette gjelder for enhver testprosess, men er spesielt viktig på grunn av den ekstra kompleksiteten ved automatisering. Bedre kommunikasjonslinjer og mangel på informasjonssiloer lar teamene dine gjennomføre testene mer effektivt.
Velge riktig automatiseringsprogramvare
Automatisering innebærer vanligvis å velge en tredjepartsapplikasjon som er kompatibel med teamets testmål. Hvert alternativ har forskjellige prisplaner og funksjonalitet. Dette kan være en betydelig langsiktig kostnad, selv om programvaren utfører automatiserte tester med suksess samtidig som den gir en betydelig verdi.
Det finnes en rekke gratis alternativer som tilbyr imponerende funksjonalitet som kan sammenlignes med premiumalternativer. Det er viktig at testteamet undersøker alle tilgjengelige alternativer, inkludert gratis programvare.
Konklusjon: Exploratory Test Automation vs. Manuell Exploratory Testing
Det er få prosjekter som drar nytte av enten hel manuell testing eller helautomatisert testing, da applikasjoner av alle slag gir bedre resultater med en kombinasjon av begge.
Mens automatiserte tester kan optimere prosessen for utviklings- og kvalitetssikringsteamene, krever noen aspekter av designet manuell utforskende testing; dette er den eneste måten å få brukerbevisste tilbakemeldinger på.
Over tid jobber flere organisasjoner med å implementere hyperautomatisering , en prosess som tar sikte på å maksimere automatisering på en intelligent måte, for å sikre at virksomheten har en effektiv strategi – dette kan fortsatt eksistere sammen med manuell testing.
Automatisert testing blir mer tilgjengelig for selskaper på grunn av den økte utbredelsen av automatiseringsprogramvare, spesielt med flere gratis alternativer tilgjengelig med mange funksjoner. Dette gjør det lettere for bedrifter å ta i bruk en kombinert manuell/automatisert utforskende testmetode.
Den økende populariteten til Agile (en prosjektledelsesteknikk som fokuserer på inkrementell, men betydelig fremgang) i utviklingen har også vært en faktor da det krever korte testsykluser. En kombinert teststrategi kan imøtekomme denne og forskjellige andre utviklingsstrategier, for eksempel kontinuerlig integrasjon, som på samme måte nødvendiggjør gjentatt testing for å sikre suksess på tvers av mange iterasjoner av samme programvare.
Hva du trenger for å starte Exploratory Testing
Forutsetningene for utforskende testing er:
1. Tydelige testmål
Selv om utforskende testing er synonymt med frihet og noen ganger forveksles med ad hoc-testing, følger dette fortsatt spesifikke regler eller definerbare mål. Den eneste måten for et QA-team å lykkes med å navigere i nesten hvilken som helst teststruktur, er å vite det forventede resultatet av hver test, spesielt ettersom testerne vanligvis utformer disse sjekkene selv.
2. Kreative, intuitive testere
Utforskende testing fokuserer på å designe nye og kreative tester som kan avdekke problemer med en applikasjon. Selv testere med begrenset erfaring kan gjøre dette, forutsatt at de forstår programvaren.
Det er viktig at testerne forstår applikasjonen og hvordan den fungerer; dette lar dem intuitivt utvikle en rekke nyttige sjekker.
3. Sammenhengende dokumentasjon
Hver type testing må ha sterk dokumentasjon for å sikre at hvert teammedlem følger en forventet testplan og at ingen ved et uhell gjentar en sjekk.
Dette er et viktig aspekt ved kommunikasjon gjennom en enkelt avdeling og på tvers av flere, for eksempel utviklere som krever regelmessige testoppdateringer for å finne ut hvordan de kan fikse problemer.
4. En kundes perspektiv
Utforskende testing dekker mange strategier og scenarier, inkludert de som reflekterer hvordan brukere praktisk talt vil engasjere seg i applikasjonen. Det er viktig at testteam gjør rede for dette under kontrollene sine, selv om de ikke gjennomfører scenariobaserte tester.
Ved å ta i bruk dette kan en tester nærme seg testing fra forskjellige perspektiver, og forbedre kvaliteten på disse kontrollene.
5. Automatisert testprogramvare
Siden teamet sannsynligvis kan automatisere en betydelig mengde av testene de designer, er det viktig at de kan skaffe høykvalitets automatisert testprogramvare før utførelsesfasen.
Utviklerne og testteamet kan bruke sin forståelse av prosjektet til å finne ut hvilken tredjepartsapplikasjon som vil passe deres egne krav.
Utforskende testprosess
De spesifikke trinnene for utforskende testing er som følger:
1. Klassifiser testprosedyren
Det første trinnet i utforskende testing er at de relevante teammedlemmene skal forstå hvordan de kan nærme seg disse kontrollene, for eksempel ved å klassifisere vanlige feil og gjennomføre en rotårsaksanalyse.
Det er her testerne utvikler ideene sine for testene selv; avhengig av deres eksakte metodikk, kan de også utforme et testcharter.
Dette angir omfanget og testene for den økten eller arbeidsdagen.
2. Begynn testene
Mens de nøyaktige parametrene (som tiden for hver test eller en samlet økt) avhenger av teamets egne preferanser og prosjektets krav, følger alle utforskende visse fellestrekk.
Etter å ha klassifisert de relevante kontrollene, begynner kvalitetssikringspersonalet å utføre testene og registrere eventuelle resultater.
Hvis kontrollene krever automatisering, kan testerne sette dette opp til å fungere over natten eller overvåke det selv på dagtid.
3. Gjennomgå resultatene
Neste trinn er å gjennomgå resultatene, sammenligne dem med standard og forventede resultater. Hvis disse testene resulterer i betydelige uventede avvik av noe slag, kan testerne gjenta kontrollen eller umiddelbart begynne å finne ut hvordan de kan reparere dette. Forslagene de kommer med til utviklere kan være medvirkende til å bestemme riktig tilnærming – og feilrapportene deres kan beskrive dette i detalj.
4. Testdebriefingen
Etter å ha auksjonert testresultatene, begynner kvalitetssikringsteamet å gjennomgå selve testprosedyren og bruker denne for å finne ut om deres utforskende testmetode var egnet.
Denne testsammendragsrapporten kan til og med konkludere med at det var driftsfeil under kontrollene som krever en ny test. Testteamet kan også sjekke applikasjonen på nytt når utviklerne har reparert disse problemene for å avgjøre om de var vellykkede.
Beste praksis for utforskende testing
De mest effektive praksisene for utforskende testing inkluderer:
1. Sammenkobling av testere
Mange former for utforskende testing drar nytte av at testere jobber sammen – dette strømlinjeformer prosessen ytterligere og gir mulighet for flere perspektiver av de samme kontrollene.
Partesting unngår også muligheten for tunnelsyn, og oppmuntrer til mer kreativ testdesign.
Flere personer som jobber med de samme testene kan føre til større nøyaktighet over hele linjen, og å dele opp arbeidsmengden bidrar også til å gjøre testingen mye raskere for hele teamet.
2. Blanding av manuelle og automatiserte tester
Noen selskaper sliter fortsatt med å ta i bruk automatisering mens andre overbruker det, selv når manuelle perspektiver kan være mer fordelaktige. Å balansere disse sjekkene sammen lar testteamet dekke flere baser og sikre kvalitet gjennom hele applikasjonen, inkludert for mer subjektive aspekter som programvarens grensesnitt.
Å gjennomføre manuelle og automatiserte tester sammen er den eneste måten å garantere fullstendig testdekning av hver funksjon eller funksjon.
3. Forstå markedet
Det er viktig at testerne kjenner både målgruppen sin og konkurrentene under testprosessen; dette hjelper dem med å vurdere hvordan folk sannsynligvis vil reagere på applikasjonens nåværende funksjonalitet.
Enkelte funksjoner er svært etterspurte, og testteamet kan dra nytte av å prioritere disse under kontrollene. Selv om de også må opprettholde bred testdekning. Dette kan bestemme retningen for testing sammen med programvarens potensielle suksess ved lansering.
4. Bruk ekte enheter for testing
Programvaretestteam kan bruke emulatorer for å lette deres utforskende kontroller; dette kan være nyttig, men reflekterer sjelden et praktisk brukermiljø.
Ekte enheter bidrar til å forbedre påliteligheten til utforskende testing ved å generere en mer realistisk opplevelse – emulatorer er ufullkomne og kan ha feil som ikke er tilstede for kundene.
Emulering er en rask måte å teste flere plattformer på, men det er ingen erstatning for de faktiske enhetene.
Typer utdata fra en utforskende test
Det er forskjellige utdata som testere kan motta etter å ha utført en sjekk, inkludert:
1. Testresultater
Resultatene i seg selv tar mange former ettersom utforskende testing kan omfatte hundrevis av unike tester. Disse resultatene utgjør det meste av en testrutine sine utganger, og gir viktig informasjon om applikasjonens tilstand og dens evne til å tilfredsstille brukerbehov.
Testerne kan sjekke systemet på nytt og validere informasjonen når de mottar disse resultatene for å bestemme deres neste handling.
2. Testlogger
En applikasjons egne logger avslører ofte feil og problemer under testprosessen; disse gir de sterkeste ledetrådene for hvorfor programvaren mislyktes i en test. Senior testere er spesielt flinke til å tolke en applikasjons logger, slik at de kan identifisere årsaken til kompliserte problemer.
Jo mer informasjon testere henter fra disse loggene, jo mer er de i stand til å hjelpe utviklere.
3. Testrapporter
Avhengig av teamets automatiseringsprosedyre, kan utdataene deres automatisk generere en feilrapport. Dette angir eventuelle feil i en applikasjon, muligens inkludert årsakene deres og andre data som er relevante for utviklere.
Testerne kan bruke dette til å gi sin egen mening om programvaren er klar for lansering, som vanligvis er kjent som en go/no-go-beslutning.
Eksempler på utforskende testing
Her er tre eksempler på hvordan en bedrift kan bruke utforskende testing:
1. En mobil spillapp
Hvis et spillselskap ønsker å gi ut en større oppdatering for en mobilapp, kan utforskende testere sjekke både gamle og nye funksjoner for å finne ut om applikasjonen fortsatt er stabil. Dette kan øke programvarens kompleksitet til det punktet at den ikke klarer å kjøre på visse enheter.
Testere jobber for å minimere effekten av dette samtidig som de sikrer brukervennlighet på tvers av så mange plattformer som mulig.
Utforskende testere sjekker spillet og dets mange kompliserte scenarier grundig for å sikre at hver funksjon fungerer etter hensikten; denne prosessen krever vanligvis en manuell tester.
2. En tjenesteleverandørs nettsted
Nettsteder gjennomgår også utforskende testing for å sikre at de fungerer for både brukere og ansatte, så testere kan begynne med å logge på nettstedet. Dette tester nettstedets evne til å opprette nye brukerprofiler og sjekker at brukere ikke får tilgang til administrative funksjoner.
Testerne går deretter videre til å sjekke tjenesten som kan være i form av å bestille time eller bestille. De vil deretter fullføre kjøpet for å sikre at kassen fungerer tilstrekkelig, etterfulgt av å se på bestillingens e-postbekreftelse og kontohistorikken.
3. Et sykehuss styringssystem
Applikasjoner og systemer av alle slag kan dra nytte av utforskende testing. For sykehusadministrasjonssystemer kan en tester se på hvordan betalingsmodulen samhandler med andre funksjoner.
Høyere integrasjonsnivåer kan føre til betydelige feil uten streng testing. Disse kontrollene kan innebære et arkitektonisk diagram som sporer systemets mange komponenter og hvordan de krysser hverandre.
Testere ser også på problemene i tidligere iterasjoner av systemet og tester spesifikt for å se om disse fortsatt er tilstede, og tar raske grep hvis de avdekker feil.
Typer feil og feil oppdaget gjennom utforskende testing
Feil som testere kan avdekke under utforskende testing inkluderer:
1. Inkompatible funksjoner
Enkelte funksjoner i applikasjonen vil kanskje ikke samhandle med hverandre som forventet – noe som kan føre til at brukere ikke kan gjennomføre kjøp eller bruke appen. Testere sjekker funksjonene isolert og i takt med hverandre for å sikre at alt passer sammen.
2. Feil UI-design
En applikasjons brukergrensesnitt bestemmer nøyaktig hvordan noen bruker programvaren. For eksempel, hvis viktige funksjoner ikke er synlige for kunder, kan det hende de ikke legger merke til at disse funksjonene eksisterer, noe som begrenser deres glede av applikasjonen.
Manuell UI-testing identifiserer og korrigerer brukeruvennlig design.
3. Autentiseringsfeil
Mange applikasjoner og nettsteder tillater opprettelse av en brukerprofil med visse privilegier. Det er viktig at testerne sjekker om gjennomsnittsbrukere på en eller annen måte kan få tilgang til sensitive data eller til og med administrative funksjoner mens de bruker programvaren på uventede måter.
4. Død kode
Testere kan finne utdatert kode som fortsatt er til stede i applikasjonen, noe som til og med kan være årsaken til bemerkelsesverdige ytelsesproblemer. Død kode overkompliserer applikasjonens indre funksjon og kan føre til feil som kan unngås. Å identifisere og optimalisere dette gjør programvaren mer responsiv for ansatte og brukere.
Vanlige beregninger for utforskende testing
De vanlige beregningene som testere kan støte på under sine utforskende tester inkluderer:
1. Ytelsestestmålinger
Utforskende tester som ser på en applikasjons generelle ytelse kan resultere i et bredt spekter av beregninger. Dette kan inkludere minimums-, gjennomsnitts- og maksimumsresponstider sammen med feil- og suksessrater for å bestemme stabilitet.
2. Test dekningsberegninger
Testdekning er viktig fordi dette bestemmer hvor mange kategorier og fasetter av en applikasjon testene omfatter. Kravdekningsprosent vurderer for eksempel om det er noen funksjoner som krever ytterligere testrunder.
3. Samlet testeffektivitet
Sporing av antall vellykkede og mislykkede kontroller hjelper testere med å finne ut en applikasjons generelle helse. På toppen av dette kan teamet spore hvor mange av feilene de oppdager er kritiske.
4. Fordeling av mangler
På lignende måte viser kontroll av defektfordelingen komponentene eller funksjonene som er mest utsatt for feil. Dette kan være deler av applikasjonen som ofte samhandler med andre, noe som gjør det viktig å prioritere disse testene.
5. Regresjonsberegninger
Utforskende regresjonstesting lar testere se hvordan ulike iterasjoner av samme programvare oppfører seg og hvordan dette kan påvirke ytelsen.
Defektinjeksjonshastighet og defekter per konstruksjon er de spesifikke beregningene som hjelper med dette.
Løser opp litt forvirring: Utforskende testing vs. ad hoc-tester
Med et sterkt fokus på testerfrihet, forveksler noen ofte utforskende testing med ad hoc-testing. De to formatene deler flere viktige likheter, men tjener til slutt forskjellige formål.
1. Hva er ad hoc-testing?
Ad hoc-testing er en helt ustrukturert tilnærming som bryter med konvensjonell testdesign for å finne defekter som ellers ikke ville dukket opp.
Denne formen for testing innebærer vanligvis ingen dokumentasjon, noe som gjør det vanskelig å reprodusere problemer med mindre testeren er helt sikker på årsaken.
Et eksempel på dette er ‘apetesting’, en sjekk som involverer tilfeldige inndata og til slutt tar sikte på å bryte systemet.
I likhet med utforskende testing jobber mange ad hoc-testere som par for å fullføre disse kontrollene; dette forbedrer deres pålitelighet. En ad hoc-tilnærming kan være nyttig etter formell testutførelse for å sikre at sjekkene tar hensyn til alle muligheter; Dette hjelper også når det er begrenset tid til å utføre ytterligere testing. Med riktig utførelse er ad hoc-tester svært fordelaktige.
2. Forskjeller mellom utforskende testing og ad hoc-tester
Ad hoc-testing innebærer vanligvis ingen formell dokumentasjon. Dette står i skarp kontrast til utforskende tester der den improviserte naturen til disse sjekkene gjør journalføring enda viktigere.
Utforskende tester bruker et større utvalg av formelle testteknikker, mens ad hoc-kontroller unngår dette ved å se utenfor konvensjonell testetikett. Dette hjelper dem med å avdekke feil som testere ellers aldri ville funnet.
Utforskende testing har klare mål og grenser, men lar fortsatt teammedlemmer bruke kreative tester. Ad-hoc-tester har vanligvis ikke definerbare sluttmål utover å presse programvaren slik den kan. Ad hoc-testing involverer ofte også en forhåndseksisterende kunnskap om programvaren og dens funksjoner, mens utforskende testing inkorporerer læring av applikasjonen i de vanlige prosessene.
Utforskende testing i Agile
Smidig metodikk fremmer i stor grad kontinuerlig forbedring. Dette betyr at den passer godt sammen med utforskende tester, spesielt ettersom etterspørselen etter hyppige programvareoppdateringer øker.
Å kombinere utforskende testing med Agile kan gi teammedlemmer en sterkere teststruktur ved å inkorporere utgivelsesplanlegging og sprintkjøring på tvers av timeplanene deres. Et selskap som omfavner smidige teknikker kan utnytte dette enda mer ved å koble det sammen med utforskende testing; dette er en fin måte å teste hver enkelt programvarekomponent i en applikasjon. Ettersom testere kan utføre utforskende kontroller uten skript, sparer dette både kvalitetssikringsmedarbeidere og utviklere for mye dyrebar tid.
Automatisert utforskende testing forsterker disse besparelsene, og hjelper bedrifter med å sjekke applikasjonens siste iterasjoner mye raskere, potensielt over natten. Utforskende sjekker gir raske, brukbare resultater, og utviklerne kan handle på nødvendige endringer som en del av deres neste sprint.
Manuell utforskende testing gir fortsatt mange fordeler i forbindelse med Agile på grunn av dens kapasitet til å identifisere problemer som en automatisert tilnærming kan gå glipp av. Andre former for testing tar rett og slett for lang tid eller gir for få fordeler til å passe komfortabelt innenfor Agile-rammeverket. Utforskende kontroller kan sørge for at hvert Agile-trinn forbedrer programvaren og dens funksjonalitet betydelig.
7 feil og fallgruver å unngå ved implementering av utforskende tester
Her er syv vanlige feil som bedrifter ofte gjør mens de implementerer utforskende tester, sammen med hvordan firmaer kan unngå disse problemene:
1. Ubalansert manuell/automatiseringstesting
Å finne ut hvilke tester som fungerer best med manuelle kontroller, og hvilke som vil ha nytte av automatisering, tar tid, men gjør at teamene kan teste langt mer effektivt.
Automatisering av for mange tester kan resultere i en applikasjon som er uhåndterlig eller ikke brukervennlig på grunn av mangelen på en menneskelig tester.
2. Tidsbegrensninger
Utforskende testing er raskere enn mange andre former for testing, men realiteten med prosjektfrister betyr at det fortsatt er grenser for hvor mange tester teamet kan gjennomføre.
Tidsstyring og en forpliktelse til testdekning hjelper testteamet med å utføre så mange kontroller som mulig på tvers av mange brede kategorier.
3. Ufleksible testere
Mens utforskende testere ikke krever forhåndseksisterende kunnskap om programvaren eller spesielt dype ferdigheter, er sjekkene fortsatt avhengige av evnene og initiativet til individuelle teammedlemmer.
Prosjektlederen må tildele disse testrollene klokt, og reservere dem for mer kreative og intuitive medlemmer av teamet om nødvendig.
4. Vanskeligheter med å gjenskape feil
Det er ikke alltid tydelig hvilke handlinger som bidrar til en testfeil; det kan også være uklart hvilke sider av søknaden som har skylden.
Dette er grunnen til at mange utforskende tilnærminger innebærer å pare testere sammen eller til og med ta opp en testers skjerm direkte for å få en klarere forståelse av problemene og deres eksakte årsaker.
5. Uklar dokumentasjon
Enten det er en automatisert feilrapport eller en manuell registrering av de fullførte testene, gjør god dokumentasjon det enklere for utviklere å handle ut fra testteamets funn.
Testteamet må forplikte seg til å sikre journalføring av høy kvalitet gjennom hver enkelt kontroll, og tilby så mange detaljer som mulig i hver rapport.
6. Høye forventninger
Utforskende testing er fordelaktig for nesten alle programvareprosjekter, men er fortsatt begrenset i omfang – det fungerer best sammen med andre testmetoder.
Testteam må utføre disse kontrollene sammen med de vanlige skripttestene; dette er den eneste måten kvalitetssikringsavdelinger kan sikre konsekvent bred testdekning.
7. Feil automatisering
Det er viktig at testteamet og prosjektlederen forstår hvilken automatiseringsprogramvare som gir de fleste fordelene for den aktuelle applikasjonen.
Ulike tredjepartsalternativer tilbyr sine egne unike funksjoner, slik at teamets valg kan avgjøre suksessen til deres robotprosessautomatisering ; de må vurdere alle alternativer foran seg.
5 beste gratis utforskende testverktøy
De fem beste utforskende testverktøyene som kvalitetssikringsteam kan bruke gratis inkluderer:
1. ZAPTEST GRATIS utgave
ZAPTEST Free leverer funksjonalitet på førsteklasses nivå til absolutt null kostnader, slik at enhver organisasjon kan dra nytte av enkel utforskende testimplementering.
Denne applikasjonen kan automatisere hvilken som helst plattform, enhet og nettleser med innovativ 1SCRIPT-teknologi.
ZAPTEST gir også fleksibel RPA-automatisering, som lar deg kombinere dette med en manuell tilnærming.
2. XRAY Exploratory App
XEA lar brukere lage omfattende testskjemaer og enkelt registrere fremgangen deres, og strømlinjeforme feilrapporteringsstadiet i utforskende testing.
Dette alternativet fokuserer utelukkende på brukerperspektivet og tilbyr en sentralisert resultathub for å oppdatere andre testere.
Imidlertid har ikke XRAY for øyeblikket integrert automatisering, noe som kan begrense dens langsiktige effektivitet.
3. Feilmagnet
Bug Magnet er en nettleserutvidelse som tilbyr grundig utforskende testing, og lar testere sjekke kantsaker og andre problematiske verdier.
Denne utvidelsen gir også enkel integrasjon av dummy-tekst, e-postadresser og flere tegnsett.
Dette er imidlertid bare tilgjengelig for Firefox og Chrome-baserte nettlesere, noe som gjør det til et mindre allsidig valg enn konkurrentene.
4. Azure-testplaner
Azure Test Plans er en sentral del av Microsofts Azure-plattform og lar testere fange rike data på tvers av mange scenarier.
Dette alternativet er egnet for både skrivebords- og nettbaserte applikasjoner, samtidig som det gir ende-til-ende-sporbarhet som har en klar oversikt over programvarens utvikling.
Imidlertid krever denne tilnærmingen ofte dypere integrasjon med Azure, og den kommer derfor på bekostning av fleksibilitet.
5. Vitnesbyrd
Testiny spesialiserer seg på manuell utforskende testing, og tilbyr en smart editor som lar testere designe sjekker ved hjelp av en trestruktur for maksimal fleksibilitet.
Hver endring i en kjøring eller testsak forblir i applikasjonens historie for å sikre full ansvarlighet og sporbarhet.
Dette er imidlertid bare gratis for små team og åpen kildekode-prosjekter.
Når bør du bruke Enterprise vs. Gratis Exploratory Test-verktøy?
Mens utforskende testing er en verdifull investering og premiumapplikasjoner vanligvis tilbyr større funksjonalitet, er det mange gratis alternativer som gir mer enn nok funksjoner.
Utforskende testing kan være en betydelig driftskostnad hvis du forplikter deg til en premiummodell, men ikke alle programvareutviklingsselskaper eller -team har penger til dette. Det beste utvalget av tredjepartsprogramvare avhenger ofte av firmaets spesifikke krav.
En betalt løsning kan være den eneste måten å tilfredsstille behovene til det prosjektet; teamet må undersøke de ulike valgene før de forplikter seg til en søknad.
Bedrifter med mindre team kan ha mest nytte av gratis testverktøy ettersom mange av alternativene er gratis for et begrenset antall brukere.
Alternativt kan de velge alternativer uten denne begrensningen og de som er i stand til å imøtekomme testteamets skala. Dette kan gjøre det enda mer lønnsomt å koble sammen utforskende testere for å sikre mer nøyaktige resultater – teamet vil naturligvis kreve færre brukerprofiler.
Mange tjenester tilbyr en gratis prøveversjon av programvaren deres, slik at organisasjoner kan se om den oppfyller deres behov; disse varer vanligvis bare i et par uker.
Sjekkliste, tips og triks for utforskende testing
Det er mange tilleggstips som testere kan ta hensyn til når de begynner sine utforskende kontroller, inkludert:
1. Del funksjonene og modulene på riktig måte
For å unngå feilkommunikasjon bør testteam lage en klar liste over hver funksjon og kontrollene de har til hensikt å kjøre. Dette betyr også å sikre at testene er tilstrekkelig spredt over programvarefunksjonene.
For best resultat er det avgjørende at testteamet forhandler hvilke medlemmer som gjennomfører hver test basert på deres respektive ferdigheter og styrker.
2. Arbeid med å forstå programvaren
Læringsstadiet er en kritisk del av utforskende testing. Dette betyr at testerne må aktivt engasjere seg i programvaren og finne ut hvordan den fungerer før de utarbeider tester.
Å lære om den indre funksjonen til denne programvaren kan være en samarbeidsprosess, som sikrer en større forståelse på tvers av teamet. Dette lar testerne utvikle bedre kontroller og testtilfeller.
3. Finn ut problematiske områder
Hver applikasjon har funksjoner eller komponenter som krysser andre. Etter hvert som programvare blir mer kompleks, er det mer sannsynlig at det oppstår feil; dette kan kreve mer testing. Teamet må aktivt jobbe for å finne ut hvilke komponenter som trenger ekstra hjelp.
De kan bruke spesifikke testturer som best reflekterer applikasjonens behov og teamets generelle testprioriteringer.
4. Begynn med grunnleggende brukerscenarier
Kvalitetssikringsteam kan utføre utforskende tester i hvilken som helst rekkefølge, om nødvendig, men det kan være mer nyttig å starte med enklere kontroller før du går inn i mer kompliserte funksjoner.
Dette gir en jevn progresjon når det gjelder kompleksitet, og gir testerne en sjanse til å forstå programvaren. Det hjelper også å teste om de grunnleggende funksjonene fungerer som forventet.
5. Par testere sammen
Paret utforskende testing både effektiviserer og validerer kvalitetssikringsstadiet, og lar testerne jobbe med absolutt selvtillit i hver sjekk. Samarbeid gjør enhver form for testing mer effektiv ved å forbedre hvert teammedlems kjennskap til programvaren.
De kan også gi feilrapporter med langt større dybde på grunn av deres individuelle perspektiver, noe som gir utviklerne mer informasjon å jobbe med.
6. Kjør flere tester
Teamets evne til å teste en søknad på nytt avhenger av tidsplanen og fristene foran dem. Men hvis det er mulig, kan det være nyttig å dobbeltsjekke spesielt problematiske komponenter.
På toppen av dette kan gjentatte tester bekrefte at et tidligere oppdaget problem nå er fikset og ikke vil påvirke programvaren ytterligere. Denne omhu er noen ganger nødvendig for å sikre at testingen er vellykket.
Konklusjon
Utforskende testing har mye å tilby programvareutviklingsselskaper av alle slag, og fungerer som et supplement til skripttesting og mange andre kontroller.
Ved hjelp av utforskende testing kan kvalitetssikringsteam teste applikasjoner til en høyere standard, forbedre den endelige programvarens kvalitet og hjelpe utviklere med å fikse eventuelle feil hvis de eksisterer.
En kombinasjon av manuell og automatisert utforskende testing kan sikre de fleste fordelene, noe som gir lik oppmerksomhet til alle programvarekomponentene.
Hvis bedriften din trenger utforskende automatiseringsprogramvare, tilbyr ZAPTEST FREE Edition en mye bredere og mer fleksibel funksjonalitet enn andre premiumapplikasjoner, slik at testere enkelt kan optimere disse sjekkene.
Vanlige spørsmål og ressurser
1. Beste kurs om Exploratory Test automation
Både nye og erfarne utforskende testere kan ha nytte av kurs for å forbedre sine ferdigheter. Dette inkluderer å finne ut hvordan du kan nærme deg ny programvare.
Nyttige kurs som kan hjelpe med dette inkluderer:
• Udemys komplette 2023-programvaretesting Bootcamp; dette lærer ut bred programvaretesting over 28 timer.
• Coveros sin utforskende testing; dette fokuserer på hvordan man utvikler charter og anvender utforskende tester på APIer.
• Polteqs to-dagers utforskende testopplæring; dette ser på hvordan utforskende tester fungerer i en smidig kontekst.
• LinkedIns utforskende testing; dette viser hvordan moderne programvaretesting har omfavnet utforskende kontroller.
• Courseras introduksjon til programvaretesting; dette hjelper førstegangstestere å forstå de typiske prosedyrene.
2. Hva er de 5 beste intervjuspørsmålene om Exploratory Testing?
Når du intervjuer for utforskende teststillinger, er det viktig at ansettelsesledere stiller gode spørsmål for å nøyaktig vurdere en kandidats ferdigheter og erfaring.
De fem beste spørsmålene å stille er:
• Inkludert deres egnethet, hva er de viktigste forskjellene mellom skriptet og utforskende testing?
• Hvilke utfordringer har du støtt på som utforskende tester og hvordan kom du over dem?
• Gi eksempler på utforskende tester som ville ha størst nytte av robotprosessautomatisering.
• Etter din mening, hva er den viktigste ferdigheten (teknisk eller på annen måte) for en utforskende tester?
• Hvilke råd vil du gi til en tester som sliter med å forstå programvaren og hvordan sjekke den?
3. Beste YouTube-veiledninger om utforskende testing
Det er mange gratis veiledninger tilgjengelig på videodelingsnettsteder som YouTube, som kan hjelpe potensielle testere å forstå kjerneprinsippene. Noen er en del av en serie, mens andre er enkeltvideo-dypdykk i emnet.
Kanaler som tilbyr disse veiledningene inkluderer:
• Testing Academy tilbyr hundrevis av videoer som dekker alle aspekter av programvaretesting.
• Software Testing Mentor, som på samme måte tilbyr omfattende videoer om grunnleggende programvaretesting.
• QAFox, som også gir eksempler fra den virkelige verden og live-prosjekter for å komplettere alle videoene deres.
• SDET-QA Automation Techie, som har flere omfattende videoer om forskjellige testmetoder.
• GlitchITSystem, som ser på ulike nettsteder med utforskende testing for å prøve å avdekke feil.
4. Hvordan vedlikeholde utforskende tester?
Godt utførte utforskende tester inkluderer sterk dokumentasjon som utviklere og fremtidige testere refererer tilbake til for nyere iterasjoner av programvaren.
Når det er betydelige oppdateringer til en applikasjon, blir det nødvendig å teste dens primære funksjoner på nytt for å sikre at disse tilleggene ikke har noen negativ innvirkning på eksisterende funksjoner.
Dette er den eneste måten å garantere at de utforskende testene forblir vellykkede på lang sikt. Det hjelper også å ta fremtidige planer som foreløpige funksjoner i betraktning når du utformer den opprinnelige applikasjonen og dens sjekker.
QA-ansatte må planlegge disse testene tilstrekkelig og finne ut når de skal sjekke søknaden på nytt; automatiserte testverktøy kan hjelpe teamet med dette.
5. Er Exploratory Testing black-box testing?
Utforskende testing er veldig lik black-box-testing, som refererer til å sjekke en applikasjon ved å se på funksjonene uten å inspisere koden direkte.
Det er ingen eksplisitt grense for hvilke typer kontroller som kommer under utforskende testing; denne tilnærmingen kan omfatte alle aspekter av programvaren, inkludert koden.
En av de viktigste likhetene mellom disse to testtypene er testerens mangel på forhåndskunnskap. Black-box-testere er vanligvis ikke kjent med programvaren før de tester den, og utforskende testere lærer hvordan programvaren fungerer som en del av deres første undersøkelse.
Selv om utforskende testing generelt ikke alltid klassifiseres som black-box-testing, er det sant at det er en betydelig mengde crossover mellom disse to tilnærmingene.
