Meny

Hva er utforskende testing i programvaretesting (en komplett guide)

  • Hoved
  • Annen
  • Hva er utforskende testing i programvaretesting (en komplett guide)

what is exploratory testing software testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er utforskende testing?

“Utforskende testing” - som navnet antyder, er en samtidig lærings-, testdesign og testutførelsesprosess. Vi kan si at i denne testingen blir testplanlegging, analyse, design og testutførelse alle gjort sammen og umiddelbart.

Denne testingen handler om å utforske systemet og oppmuntre sanntid og praktisk tenkning av en tester.

I denne serien har vi dekket følgende veiledninger:

Opplæring # 1: Hva er utforskende testing i programvaretesting (Denne opplæringen)
Opplæring nr. 2: Bruke turer for å sikre fullstendig utforskende testing
Opplæring # 3: Exploratory Testing vs Scripted Testing
Opplæring # 4: Utforskende testing med HP Sprinter
Opplæring # 5: Topp 17 Utforskende testverktøy

***********************************
Utforskende testing

Hva du vil lære:

Oversikt

I lekmannstilfeller innebærer utforskende testing samtidig testdesigndesign og testutførelse av et program eller et system som testes. Testeren vil lage eller skrive ned en testidee for å gi retning, og utforske systemet mens han tester for ytterligere å lage kritiske, praktiske og nyttige tester for vellykket testing av et program.

Dette krever minimal planlegging. Testere tar kontinuerlig en avgjørelse om hennes neste handlingstrinn. Det kommer helt an på testers tankeprosess.

Noen ganger kan denne testingen være mer fordelaktig enn den formelle testmetoden for å finne noen subtile feil som mangler i formell testing.

Bevisst eller ubevisst ville hver eneste tester ha gjort utforskende tester på et eller annet tidspunkt i karrieren.

Som vi alle vet, vil en elev lære bedre gjennom praktisk erfaring i stedet for å stappe teorien.

På samme måte vil en tester kun kjenne applikasjonen bedre mens den utforsker og lærer om all funksjonaliteten den gir av seg selv. Det er alltid bra å ha et kunde- og forretningsperspektiv mens du tester for å sikre vellykket testing av en applikasjon.

For eksempel, hvis du åpner et shoppingnettsted, har du en generell ide om at dette shoppingnettstedet lar deg handle ved å velge et produkt du ønsker og deretter betale for det samme.

I løpet av denne prosessen kan det hende du lærer deg at nettstedet gir deg virtuelt menneskelig utseende som hjelper deg i valg av prosess. Du fant også ut at du kan bestille en rekke produkter for prøveversjon hjemme eller at du kan foreta betaling gjennom belønningspoeng fra noen banker osv.

Som tester trenger du ikke bare å kontrollere om et system fungerer som forventet, men også sjekke om systemet ikke oppfører seg på en måte som ikke forventes.

Få ting å huske når du utfører denne testen:

  • Ditt oppdrag skal være klart.
  • Sørg for å lage notater og rapportere om hva du gjør og hvordan et system oppfører seg, noe som kan være en potensiell feil.
  • Lær, observer og kom opp med nye testsaker.

Anbefalt utforskende testtjeneste

# 1) Digivante Direct

Digivante Direct-logo

Digivante Direct utfører undersøkende testing ved hjelp av sitt globale nettverk av profesjonelle testere, slik at du kan dekke testing på alle større enheter i en tidsskala som ikke er oppnåelig av noen annen testleverandør eller internt team.

Slipp raskere, tryggere, og la de digitale plattformene gi deg større kundetilfredshet og økte onlineinntekter.

Egenskaper:

  • 24 virkedager med testing på bare 24 timer eller 90 virkedager på 72 timer, og enestående, omfattende testnivå som ikke kan nås på noen annen måte.
  • Lav pris , lettfattelige prispakker uten skjulte tillegg.
  • Selvbetjening online portal som ikke krever kontinuerlig forpliktelse.
  • Ekte mennesker som tester på ekte enheter - mye større enhets- og nettleserdekning enn du kan oppnå internt, og alt innen raskere behandlingstid.
  • Komplett utforskende testdekning - redusere risikoen og forbedre sluttbrukertilfredshet og konverteringsfrekvenser, og øke inntektene samtidig som kostnadene reduseres
=> Besøk Digivante Direct-nettstedet

Eksplorerende testeksempler

Eksempel 1:

Et nettsted for leverandører av hjemmetjenester med følgende komponenter:

  • Logg Inn
  • Tjenester
  • Handlevogn
  • innbetaling
  • Ordrehistorikk
  • Tildeling av tekniker

En generell idé å starte utforskende testing vil være å logge inn eller bestille en tjeneste.

Hvordan dekke test tilfeller?

Eksplorerende testtilfeller

type feil ved programvaretesting

I ovennevnte Eksempel, ideen er å starte med funksjonalitet basert på din kunnskap. Når du lærer og observerer mer om applikasjonen, kan du styre ditt neste sett med testtilfeller.

Eksempel 2:

Jeg ble en gang inkludert i et lite prosjekt som involverte tillegg av et nytt fond i søknaden. Min oppgave var å teste søknaden for å sikre at det nye fondet er tilgjengelig for brukere å kjøpe og sjekke om den tilhørende verdsettelsen er riktig. Jeg hadde bare to dager på meg til å fullføre testingen.

Da jeg fikk den stramme fristen og alvorlighetsgraden av testing, brukte jeg den utforskende tilnærmingen til testing. Målet mitt var å teste nye funksjoner og finne brudd på kompatibilitetskravene.

Ovennevnte mål ble charteret mitt for denne testøkten.

Følgende testsaker ble utviklet under denne testen:

  • Testing for å sikre at det nye fondet er lagt til applikasjonen.
  • Ny MF er kjøpt med suksess.
  • Verdsettelse av ny MF er riktig.
  • Forsøkte å kjøpe ny MF til en eksisterende portefølje.
  • Kan ny MF legges til i alle porteføljene?
  • Effekten av New MF på en verdsettelse av eksisterende.
  • Så i andre test tilfeller ble utviklet.

Jeg utarbeidet notater og rapporter under testingen for å diskutere observasjonen min med BA og klienten som var involvert.

Den grunnleggende strategien for utforskende testing er å ha en plan for angrep. Begynn å teste med ideen din og improvisere nye testsaker basert på din kunnskap og observasjon.

Eksempel 3:

Utforskende testing av IRCTC-nettstedet

=> Klikk her for å laste ned eksempler på testtilfeller av utforskende testing av IRCTC-nettstedet.

Testing Approach

  • Benytt deg av heuristikk for å veilede testing.
  • Utførelse av testsaker og oppretting av testsaker går hånd i hånd.
  • Test tilfeller fortsetter å utvikle seg basert på testers observasjon og læring.
  • Ulike testteknikker som Grenseverdianalyse , ekvivalensprøving osv. kan brukes på ET.
  • Sesjonsbasert ET kan brukes til å gjøre den mer strukturert og fokusert.
  • Testere kan forgrene ideer der, men aldri avvike fra oppdraget ditt.
  • ET-testing bruker ikke skript, men avhenger i stedet av testers intuisjon, dyktighet og erfaring.

fordeler

Fordelene med denne testingen inkluderer:

  • Fremme sanntid tenking og hjelper med å avdekke flere mangler.
  • Fremme brukstilfeller og scenariobasert testing.
  • Minimal dokumentasjon, maksimal testing.
  • Vekt er mer på å lære og utvide en testers horisont.
  • Unngå duplikatarbeid.
  • Nyttig når du vil kontrollere andre testers arbeid.

Demeriter

Nedbrytelser er vervet nedenfor:

  • Testing avhenger av testers erfaring, dyktighet og kunnskap.
  • Krever tid til å lære programmet. Det er mer sannsynlig at tester vil savne hvis de vet mindre om applikasjonen.
  • Ikke passende for prosjekter med lang gjennomføringstid.

Sesjonsbasert utforskende testing

Mens det er utforskende testing, er det veldig vanskelig for testere å sette ord på hvor mye han har testet og på hvilket grunnlag.

I utgangspunktet er det vanskelig å tallfeste arbeidet og tiden brukt. I hvert prosjekt må vi imidlertid gi beregninger, estimater og fremdriftsrapport til teamledere og ledere. Som ordtaket sier, 'hvis du ikke kan kvantifisere det, kan du ikke klare det'.

Sesjonsbasert testing er en tidsbasert tilnærming for å utføre denne testen som hjelper til med å administrere og spore. Det inkluderer en dedikert testboks med tidsbokser uten avbrudd fra e-post, telefon, meldinger etc.

Nærme seg:

Testoppgaver er delt inn i økter.

Følgende er komponentene i sesjonsbasert testing (SBT):

  • Oppdrag: Misjon roper ut formålet med økten og gir på en måte fokus for testeren. Det vil også omfatte en øktvarighet.
  • Charter: Inkluderer omfanget av testingen. I utgangspunktet en agenda som beskriver målene som må fullføres under økten.

Eksempel på testcharter for påloggingsfunksjonalitet til hjemmesiden for hjemmetjeneste:

Eksempel på testcharter for påloggingsfunksjonalitet

  • Økt: Forhåndsdefinert testboks med tidsboks uten avbrudd. Hver økt kan ha følgende varighet:
    • “Kort” (60 minutter)
    • 'Normal' (90 minutter)
    • “Lang” (120 min)
  • Sesjonsrapport: Inkluder notater og lett rapport for å gi beregninger til lederne og lederne. Den gir detaljer om gjenværende eller ferdig charterøkt, sesjonstestetid, scenario testet, om testprosessen, en liste over feil og problemene som er funnet og annen informasjon for beregningene.
  • Økt-de-brief: Et kort møte eller stand-up mellom testeren og testledelsen / lederen for å gjennomgå funnene fra testsesjonen.

Ledere kan få praktisk beregning basert på sesjonsrapport:

  • Antall økter fullført og gjenværende.
  • Antall rapporterte feil.
  • Tid brukt på øktoppsett.
  • Tid brukt på testing.
  • Tid brukt på å analysere problemer eller problemer.
  • Funksjoner dekket.

For å oppsummere det ovennevnte:

SBT muliggjør ansvarlighet er utforskende testing og gir bedre styring av tid brukt på testing. Det øker også produktiviteten og gir bedre forståelse for deteksjon av feil. Det er en fin måte å gi teamledere og ledere beregninger for å kontrollere prosjektfremdriften.

Parbasert utforskende testing

Pair Testing er en tilnærming der to personer tester det samme / funksjonen til applikasjonen samtidig ved å dele en PC. De deler kontinuerlig sine tanker og ideer. Under denne testen tar den ene ansvaret for tastaturet, mens den andre foreslår testsaker og noterer seg.

Det er alltid nyttig å ha en god kommunikasjon mellom partnerne, slik at begge er klar over hva som blir gjort og hvorfor. Et par der testernes styrke gjensidig utfyller deres svakhet, blir ansett som en sterk gruppering.

Slik sammenkobling fordeler begge parter, og hver kan lære noe fra partneren. Det er også en god måte å trene nye ressurser ved å parre dem med erfarne ressurser.

Fordeler med paretesting

  • Hjelper en tester å fokusere på oppgaven.
  • Oppmuntre gjensidig tillit og respekt blant partnere.
  • Idemyldring mellom sammenkoblede testere fører vanligvis til mer konstruktive ideer.
  • Unngå tunnelsyn.
  • Det er mindre sjanse for at andre forstyrrer dem.

Utforskende testteknikker

Turer: Det er en enkel teknikk som lar en tester bruke fantasien og tenke på seg selv som en turist som utforsker en by han besøker. Her er en applikasjon for å teste byen og testere er turistene. Det er veldig vanskelig å utforske hele byen med mindre du har mye tid og penger i hånden, så en turist må ha en plan med et visst mål i tankene.

En turist kan ta følgende turer:

  • Guidebokstur - Testing uthevet funksjon av applikasjonen. Bruk brukerbaserte scenarier.
  • Utforske byens historie - Test gamle funksjoner i et program.
  • Pengetur, som betyr å sørge for at alle kritiske funksjoner i referanse til kunden eller klienten blir testet og fungerer.
  • Krimturné - Angi ugyldige input og test negative scenarier.
  • Back smug tur - Test de minst brukte funksjonene i applikasjonen.
  • Kjedelig tur - Bruk minimum tid på hvert skjermbilde i applikasjonen, fyll ut minimumsfelt og ta den korteste veien. Dette vil hjelpe med standardverdien og valideringstesten.

Mens du tar en tur, har du alltid valget mellom å ta en hvilken som helst rute. Du kan navigere gjennom programvare og finne en unik bane for å teste funksjonen.

Nedenfor er noen tips / triks du kan bruke i ET:

  • Del applikasjonen i moduler og del to moduler på forskjellige sider. Start ET fra sidene. Dette vil gi riktig dekning.
  • Lag en sjekkliste over alle funksjonene og sett et hake når det er dekket.
  • Start med et grunnleggende scenario, og forbedr det deretter gradvis for å legge til flere funksjoner for å teste det.
  • Test alle inntastingsfeltene.
  • Test for feilmeldingen
  • Test alle negative scenarier.
  • Sjekk brukergrensesnittet mot standardene.
  • Kontroller integrasjonen av applikasjonen med andre eksterne applikasjoner.
  • Se etter komplisert forretningslogikk.
  • Prøv å gjøre etisk hacking av applikasjonen.

Faktorer som påvirker ET er som følger:

  • Målet med prosjektet
  • Testing strategi
  • Testingsmålet for en bestemt fase
  • Tilgjengelige verktøy og fasiliteter
  • Testernes rolle og ferdigheter
  • Tilgjengelig tid
  • Ledelsesstøtte
  • Jevnaldrende støtte
  • Tilgjengelige ressurser (studiemateriell, testforhold osv.)
  • Kundene interesserer seg
  • Produktets forståelse.
  • UI for applikasjonen
  • Funksjonaliteten til applikasjonen
  • Tidligere testresultater
  • Risiko forbundet med applikasjonen
  • Tidligere mangler
  • Nylige endringer
  • Typer data som skal brukes til testing
  • Type bruker som skal bruke den

I stedet for å spørre testerne hva de skal løpe, overlater vi det til å teste dommen å bestemme hva de vil teste og hvordan de vil teste.

Forskjellen mellom utforskende testing og ad-hoc-testing

Ikke forveksle ET med Ad-hoc test .

  • Ad-hoc-testing refererer til en prosess med ikke-skriptet, ikke-planlagt og improvisert mangelsøk, mens utforskende testing er en gjennomtenkt metode for ad-hoc-testing.
  • Ad-hoc-testing er en vellykket metode for å finne en feil mens ET ikke er det. I ET-tilnærming lærer en tester om systemet når de utforsker og til slutt utvikler testene ved hjelp av tilegnet kunnskap.
  • Ad-hoc-testing er en ustrukturert aktivitet, mens ET er noe en strukturert aktivitet.

Exploratory Automated Testing (EAT)

Exploratory Automated Testing er en metode som hjelper en tester med å effektivisere feilrapportering og reproduksjon, samle øyeblikksbilder og for å forberede fremtidig regresjonsdrakt. Det er en prosess som kombinerer automatiseringstesting med utforskende testing.

Det er to typer EAT-tilnærming:

  • Passiv EAT
  • Aktiv EAT

Passiv EAT

Passiv EAT kan utføres av en enkelt tester eller i et par også. I denne metoden, vanligvis et verktøy, som fanger opp og registrerer hver eneste aktivitet utført av en testressurs (er) og er installert på ressursens PC.

Passiv EAT ligner på ET som utføres manuelt, da det ikke er noen endring i måten testene utføres bortsett fra å lage testresultatet basert på den fangede økten. Disse testresultatene kan brukes til rapportering og gjeninnføring av registrerte handlinger senere i tid.

Det installerte videoverktøyet hjelper en tester med registrering av testtilfeller og rapportering av feil.

Det har også få andre fordeler som:

  • Gir klare trinn for å reprodusere feilene.
  • Å reprodusere mangler er lettere, selv når manglerapporteren ikke er tilgjengelig.
  • Fjern konfliktene mellom test- og utviklingsteamet når det rapporteres om en periodisk feil.
  • Hjelper i ytelsestesting ved å få systemets responstid på det bestemte tidspunktet.

Her er noen få andre punkter du må ta i betraktning før Passiv EAT:

  • Det anbefales å utføre en pilottest før du tilpasser verktøyet til Automated EAT. Dette for å sikre at tiden som kreves for å re-designe testloggene som ble opprettet under testøkten, ikke er mer enn testutførelse. I så fall må teamet ta en gjensidig beslutning om følgende:
    • Hvis det i det hele tatt er behov for testautomatisering for det aktuelle prosjektet.
    • Hvis verktøyet som brukes må endres.
    • Hvis ytelsen til verktøyet som brukes kan optimaliseres.
  • Verktøyet som brukes til å utføre automatisert EAT, må installeres på alle testressurser som er involvert i testing. Det er også en god ide å involvere utviklerne som kan oppnås ved å enten gi utviklerne VPN eller ekstern tilgang til testmaskiner eller ved å installere verktøyet i utviklingsmiljøet.
  • Det er alltid en god ide å ha GUI-objektet til applikasjonen organisert i testverktøyet, slik at når tiden kommer for å analysere feilen eller et problem, er objektet gjenkjennelig på grunn av et meningsfylt navn.
  • Det er en god praksis å gi et meningsfylt navn til GUI-objektet som brukes i AUT og holde dem organisert for senere bruk.

La oss nå gå videre til den andre tilnærmingen.

Aktiv EAT

Det anbefales å utføre Active EAT med paretesting. I denne tilnærmingen brukes Keyword Driven testing i synkronisering med Session testing. Én tester oppretter det automatiserte testskriptet, og den andre tester utfører testskriptene opprettet av den første testeren.

Opprettelse av automatiseringstestskript i denne tilnærmingen tar en annen vei enn ved konvensjonell testing. Automatiske testskripter lages under testing, og det som er oppdaget i de forrige testene, bestemmer utformingen.

En avslutningsfase utføres på slutten av testøkten. Og det skal ha følgende oppgaver:

  • Involverte testere bør bytte roller slik at testressursen som opprettet testskriptet har en sjanse til å utføre skriptene på nytt for å bekrefte påliteligheten og robustheten til den opprettet suiten.
  • En kort beskrivelse sammen med få identifiserende egenskaper skal gis for hvert automatiserte testskript.
  • Et kriterium må defineres for å identifisere hvilke automatiserte testskripter som kan brukes til regresjonstest.

Fordeler med EAT

  • Ved starten av hver økt kjøres allerede opprettede automatiserte testskripter, noe som forbedrer testdekningen hver gang.
  • Bedre feilrapportering og dokumentasjon for reproduksjon av mangler.
  • EAT gir nok bevis og dokumentasjon til at en interessent kan se fremdriften.

Typer utforskende testing

Nedenfor er noen få typer ET:

1) Freestyle OG:

Utforsking av applikasjon i ad-hoc-stil.

I denne typen ET er det ingen regler, ingen konto for dekning osv. Denne typen testing er imidlertid bra når du trenger å bli kjent med applikasjonen raskt, når du vil verifisere arbeidet til de andre testerne, og når du vil undersøke en mangel eller ønsker å gjøre en rask røykprøve.

2) Scenariobasert ET:

Som navnet antyder, er testing gjort scenariobasert. Det starter med ekte brukerscenarier, end-to-end-scenarier eller testscenarier. Etter første testing kan testere injisere variasjoner i henhold til læring og observasjon.

Scenarier er som en generell guide for hva du skal gjøre under ET. Testere oppfordres til å utforske flere mulige baner mens de utfører et scenario for å sikre all mulig vei til funksjonsarbeid. Testere bør også sørge for å samle så mange scenarier som mulig fra forskjellige kategorier.

3) Strategibasert ET:

Kjente testteknikker som grenseverdianalyse, ekvivalensteknikk og risikobasert teknikk som kombineres med utforskende testing. En erfaren tester eller en tester som er kjent med applikasjonen er utnevnt for denne typen testing.

Agile Exploratory Testing

Selv om du ikke har jobbet i et smidig miljø, er jeg sikker på at du må ha lest eller hørt om det på grunn av den økende populariteten. Agile metodikk har korte sprinter og stramme tidsfrister som gir et team et par uker å fullføre planlegging, estimering, utvikling, koding, testing og utgivelse.

Utforskende testing blir nyttig i så stramme tidsfrister, fordi det i denne testtilnærmingen legges vekt på det raske og nyttige resultatet. Når du har forstått kravet, kan du begynne å teste ut fra din erfaring og kunnskap.

Når du er kjent med applikasjonsfunksjonene og oppførselen, kan du designe flere testtilfeller for å validere applikasjonsfunksjonaliteten og oppdage ikke planlagte feil. Siden det er en freestyle-testtilnærming, må du dokumentere alt. Du må imidlertid ha notater og en kort rapport om hva du har testet, feil og problemer funnet osv.

Meritter av Exploratory in Agile

  • Å gi tilbakemelding til utviklerne så snart som mulig.
  • Et bredere utvalg av mangler blir avdekket.
  • En mangfoldig gruppe av en ressurs som en utvikler, tester, BA, designere kan utføre ET ettersom det ikke er noen skriptede testtilfeller, og hver gir et annet perspektiv.
  • Scouting gjort i ET hjelper med å utforske nye territorier og avsløre kritiske feil.
  • I tilfelle Iterativ koding av et program, kan ET fokusere på å teste nye funksjoner mens automatisering gjør regresjon og bakoverkompatibilitetstesting.
  • I tilfelle ustabile krav, kan ET hjelpe til med å teste nye krav innen en begrenset periode.

Poeng å huske:

1. Krever forskjellige ferdigheter: Testerne som utfører ET må ha gode lytte-, lese-, tenke- og rapporteringsevner. Domenerfaring er påkrevd ettersom det ikke er skript og testtilfeller.

2. Noen ganger er det vanskelig å rapporter en feil: Mens vi er i en ET-strømning, kan vi støte på en defekt, men vi kan ikke være i stand til å reprodusere den. Dette er fordi vi ikke sporer teststrinnene, og vi kan glemme de nøyaktige trinnene for å reprodusere problemet.

3. Kan gjøres som fritidsaktiviteter: Jeg gjør personlig ET når jeg vil ha en pause fra min vanlige testutførelsessyklus. Men mange lag har ET som en egen fase av testsyklusen.

4. Det kan gjøres i alle testfaser: Vi kan implementere ET før begynnelsen av en testfase. Du kan utføre ET selv før funksjonell testfase.

5. Rask tilbakemelding: ET krever rask tilbakemelding om problemene og eventuelle avvik.

6. Kritisk tenking og forskjellige ideer: Denne testen krever kritisk tenkning. Testere skal kunne reprodusere, gjennomgå og uttrykke sine ideer på en logisk måte. En tester kan implementere sin erfaring innen de forskjellige teknologiene og domenene de jobbet med.

Hvordan tenke utover tradisjonelle testgrenser i utforskende testing

“Jeg setter stor pris på din bekymring for produktet og gjør oss nyttige i et forståelsesfullt sluttbrukerperspektiv. Det kommer til å være veldig nyttig. Takk for det gode arbeidet og fortsett! ”

Dette var den siste e-posten til en e-postkjede med 21 e-post fra vår klient. Det var midnatt, og produktutgivelsen vår ble forsinket på grunn av en kritisk feil vi fant. Du tenker kanskje, hva er nytt i det? Det kan skje mange ganger. Men dette var veldig annerledes, ettersom den kritiske feilen vi rapporterte ikke var et resultat av noen dokumentert testsak.

Etter fullført Regresjonstesting for siste gang den kvelden lekte jeg bare med produktet. Hva betyr det? Du står fritt til å gjøre det du ikke skal gjøre. Basert på min erfaring og prosjektkunnskap hadde jeg noen ideer om hvordan jeg skulle teste produktet bortsett fra vårt typiske testlager, kalt Utforskende testing .

De undersøkende testene som ble gjort, fant en kritisk feil relatert til et serverhang-problem mens du gjorde noe uventet.

Som en fan av utforskende testing, elsker jeg å utforske produktet på forskjellige måter. For meg er definisjonen av programvare:

'Den skal gjøre det den skal gjøre, og den skal ikke gjøre det den ikke skal gjøre.'

Utforskende testprosess

Å begrense testgrensene for å sjekke om produkter som skal fungere, gjør deg til en ufullstendig tester. Faktisk begynner en testers liv når dokumentert regresjonstest slutter og resultatene oppdateres. Å se på produkter fra forskjellige perspektiver og forstå sluttbrukernes krav i forskjellige scenarier gjør en stor forskjell. Så i dag, la oss forstå sammen hvordan denne forskjellen kan gjøres:

Hvordan se på et produkt fra forskjellige perspektiver?

utforskende testing

#1. Forstå kunde / sluttbruker

Programvaretesting handler om å sjekke produktets kvalitet når det gjelder kundetilfredshet. Hvordan vet du kundens synspunkt? Svaret er enkelt - du må være kunde. OK, la meg gjøre en rettelse. Å være kunde vil ikke være nok. Du må forstå hvordan kunden ønsker å håndtere produktet. Ingen kunder som kjøpte samme råvarer, vil lage den samme oppskriften. Ja, produktet vi utvikler / leverer er et råstoff for kundens virksomheter, og de har et annet tankesett når de bruker det.

Som programvaretester må vi sjekke formålet med produktet og ikke gjenstanden eller aspektet av det.

La meg gi deg noen praktiske eksempler:

  • Saks var aldri begrenset til å kutte papir. Skjæring er formålet og ikke papiret (objektet).
  • Mobiltelefoner var aldri begrenset til bare å ringe, men 'stand til å ringe' har alltid vært det grunnleggende formålet.
  • Oppbevaringsbokser brukes til å lagre, men sikkerheten til det lagrede materialet er like viktig som lagring.

Å forstå interessenter og et bredt spekter av forventningene deres bør være grunnlaget for utforskende testing.

# 2. En tankegang

Mens du leter etter (la oss si) en jobbansettelsesannonse, ser du den jackpotten og mellom sidene med den fet skrift? De fleste av oss gjør det ikke (tro meg, det er sant). Fordi vi har bedt oss om å se etter hva som er nyttig eller å bli sjekket. Alt annet nytter ikke, så sinnet nekter oss å gjenkjenne det.

Åpne tankene dine, og ikke sett noen forventninger når du begynner å utforske et produkt . Husk alltid at det ikke er OK hvis produktet gjør det det skal. Det er også viktig at den ikke skal gjøre det den ikke skal.

Jeg husker ett klassisk eksempel:

I Linux brukes 'cat' -kommandoen til å kontrollere innholdet i en fil, og 'ls' -kommandoen er å sjekke innholdet i katalogen. Jobbet med Linux og vært i programvaretesting i fem år, jeg trodde aldri å gjøre katt fordi tankene mine var satt; hvis jeg trengte dir-innhold, må jeg bruke ‘ls’. Det fungerte, men baksiden av forventningen er at produktet ikke skulle oppføre seg slik det ikke skulle, var feil. En av kundene våre, som ikke kjente Linux godt, gjorde en feil ved en feil, og systemet krasjet. Vi betalte for denne tankegangen.

Vær alltid klar til å gjøre feil med programvaren, for det er det sluttbrukeren skal gjøre. For å teste programvaren har du fått opplæring, men sluttbrukeren vil ikke være så opplært som deg eller han / hun vil ikke være så mye av en teknisk ekspert som deg. Dessuten vil han / hun gjøre alt med programvaren når de er i trøbbel.

Tenk på disse scenariene, og gi tilbakemelding om testing. Livet til programvaren og din (som tester) vil rocke.

c ++ kompilator for formørkelse

# 3. Kjenn konkurrentene

Mens du testet programvare for klienten din, prøvde du noen gang å kjenne og forstå annen programvare med samme formål? Har du noen gang foreslått noen nyttige funksjoner du observerte i en konkurrent? Det faller ikke inn i stillingsbeskrivelsen vår, er det typiske svaret. Men vet du fordelen med å gjøre det?

Her er noen virkelige eksempler for å få deg til å forstå poenget:

  • Liker du ikke designeren som ikke bare syr kjolen din, men som også gir deg innspill om matchende tilbehør mest?
  • Liker du ikke pizzamerket som ikke bare lager gode pizzaer, men som leverer hjemme til tiden mest?
  • Liker du ikke fotografen som ikke bare tar gode bilder, men foreslår en annen type rammer for fotograferingen?

Alle vil ha noe ekstra for det de betaler for. Vår analyse av konkurransedyktig programvare kan fungere på samme måte for oss. Kunden liker alltid å høre verdifulle forslag - hovedsakelig komparative forslag for å gjøre produktet mer nyttig eller omsettelig.

Dessuten gjør denne typen sammenligning og analyse av det samme produktspekteret vår analyse kraftigere, og til slutt skaper vi en skatt som vi når som helst kan gå tilbake til og finne noe nyttig.

Konklusjon

Exploratory kommer ikke under en konvensjonell måte å teste på, men likevel er det en veldig kraftig måte å teste på.

Det bringer ut av boksen tenking av en tester og oppfordrer dem til å komme med praktiske og sanntids test tilfeller for å finne en defekt. Dens freestyle-natur gir den et forsprang i forhold til de andre testtypene og kan utføres hvor som helst, det være seg et prosjekt som bruker Agile eller foss eller et hvilket som helst annet prosjekt som krever minimal dokumentasjon.

Suksessen med utforskende testing avhenger av mange immaterielle ting som en testers dyktighet, evnen til å lage effektive testtilfeller, deres erfaring og evnen til å følge magefølelsen.

Det er viktig å huske at ET er en adaptiv prosess i stedet for en prediktiv prosess, og det er viktig å opprettholde en sunn balanse mellom utforskende og skriptet eller regelmessig testing.

Er du en tester som har typiske utforskende testopplevelser? Vi venter på å høre tankene dine. Del dem gjerne i kommentarfeltet nedenfor.

Neste opplæring # 2: Hvordan bruke turer for å sikre fullstendig utforskende testing

Anbefalt lesing

^