Menu

Hvad er sonderende test i softwaretest (En komplet guide)

  • Vigtigste
  • Andet
  • Hvad er sonderende test i softwaretest (En komplet guide)

what is exploratory testing software testing

Hvad er sonderende testning?

'Undersøgende test' - som navnet antyder, er en samtidig lærings-, testdesign og testudførelsesproces. Vi kan sige, at i denne test udføres testplanlægning, analyse, design og testudførelse alle sammen og øjeblikkeligt.

Denne test handler om at udforske systemet og tilskynde til en testers realtid og praktisk tænkning.

I denne serie har vi dækket følgende tutorials:

Tutorial # 1: Hvad er sonderende test i softwaretest (Denne vejledning)
Tutorial # 2: Brug af ture til at sikre komplet sonderende test
Tutorial # 3: Eksplorativ testning vs scriptet testning
Tutorial # 4: Undersøgende test med HP Sprinter
Tutorial # 5: Top 17 Udforskende testværktøjer

************************************
Undersøgende test

Hvad du lærer:

qa manager interview spørgsmål svar pdf

Oversigt

I lægmandssprog involverer sonderende test samtidig testdesigndesign og testudførelse af en applikation eller et system, der testes. Testeren opretter eller skriver en testidé ned for at give retning og udforsker systemet under test for yderligere at skabe kritiske, praktiske og nyttige tests til en vellykket test af en applikation.

Dette kræver minimal planlægning. Testere træffer løbende en beslutning om hendes næste handlingstrin. Det afhænger fuldstændigt af testers tankeproces.

Nogle gange kan denne test være mere fordelagtig end den formelle testmetode for at finde nogle subtile mangler som forsvinder i formel test.

Bevidst eller ubevidst ville hver eneste testere have foretaget sonderende test på et eller andet tidspunkt i deres karriere.

Som vi alle ved, lærer en elev bedre gennem praktisk erfaring snarere end at klemme teorien.

På samme måde vil en tester kun kende applikationen bedre, mens den udforsker og lærer om al den funktionalitet, den giver af sig selv. Det er altid godt at have et kunde- og forretningsperspektiv under test for at sikre en vellykket test af en applikation.

For eksempel, hvis du åbner et shoppingwebsted, har du en generel idé om, at dette shoppingwebsted giver dig mulighed for at shoppe ved at vælge et produkt efter eget valg og derefter betale for det samme.

I løbet af denne proces lærer du muligvis, at webstedet giver dig virtuelt menneskeligt udseende, som hjælper dig med produktudvælgelsesprocessen. Du fandt også ud af, at du kan bestille et antal produkter til prøveversion af hjemmet, eller at du kan foretage betaling via belønningspunkter fra nogle banker osv.

Som tester skal du ikke kun kontrollere, om et system fungerer som forventet, men også kontrollere, om systemet ikke opfører sig på en måde, som ikke forventes.

Få ting at huske, når du udfører denne test:

  • Din mission skal være klar.
  • Sørg for at oprette noter og rapportere om, hvad du laver, og hvordan et system opfører sig, hvilket kan være en potentiel fejl.
  • Lær, observer og kom derefter med nye testsager.

Anbefalet eftersøgningstjeneste

# 1) Digivante Direct

Digivante Direct-logo

Digivante Direct udfører sonderende test ved hjælp af sit globale netværk af professionelle testere, så du kan dække test på alle større enheder i en tidsskala, der ikke kan nås af nogen anden testleverandør eller internt team.

Slip hurtigere, mere sikkert, og lad dine digitale platforme levere højere kundetilfredshed og øgede onlineindtægter.

Funktioner:

  • 24 arbejdsdage med test på bare 24 timer eller 90 arbejdsdage på 72 timer og uovertruffen, omfattende testniveau, der ikke kan nås på nogen anden måde.
  • Lavpris , let forståelige prispakker uden skjulte ekstramateriale.
  • Selvbetjening online portal, der ikke kræver nogen løbende forpligtelse.
  • Ægte mennesker, der tester på rigtige enheder - langt større enhed og browser dækning end du kan opnå internt og alt inden for hurtigere leveringstid.
  • Komplet sonderende testdækning - reducere risiko og forbedre slutbrugernes tilfredshed og konverteringsfrekvenser og derved øge indtægterne samtidig med at omkostningerne reduceres.
=> Besøg Digivante Direct-webstedet

Eksplorative testeksempler

Eksempel 1:

Et websted med hjemmeplejeudbydere med følgende komponenter:

  • Log på
  • Tjenester
  • Vogn
  • Betaling
  • ordre historik
  • Tildeling af teknikere

En generel idé at starte sonderende testning vil være at logge ind eller bestille en tjeneste.

Hvordan dækker jeg testtilfælde?

Eksplorerende testtestsager

I ovenstående Eksempel, ideen er at starte med funktionalitet baseret på din viden. Når du lærer og observerer mere om applikationen, kan du styre dit næste sæt testsager.

Eksempel 2:

Jeg blev engang inkluderet i et lille projekt, der involverede tilføjelsen af ​​en ny gensidig fond i ansøgningen. Min opgave var at teste applikationen for at sikre, at den nye gensidige fond er tilgængelig for brugere til at købe og kontrollere, om den tilhørende værdiansættelse er korrekt. Jeg havde kun 2 dage til at gennemføre min test.

Da jeg fik den stramme deadline og sværhedsgraden af ​​testning, brugte jeg testens udforskende tilgang. Mit mål var at teste nye funktioner og finde overtrædelser af kompatibilitetskrav.

Ovennævnte mål blev mit charter for denne testsession.

Følgende testsager blev udviklet under denne test:

  • Test for at sikre, at den nye gensidige fond er føjet til applikationen.
  • Ny MF er købt med succes.
  • Værdiansættelse af ny MF er korrekt.
  • Forsøgte at købe ny MF til en eksisterende portefølje.
  • Kan ny MF føjes til alle porteføljer?
  • Effekten af ​​New MF på en vurdering af eksisterende.
  • Så i andre testsager blev der udviklet sig.

Jeg udarbejdede noter og rapporter under min test for at diskutere min observation med BA og involveret klient.

Den grundlæggende strategi for sonderende test er at have en angrebsplan. Begynd at teste med din idé og improvisere nye testsager baseret på din viden og observation.

Eksempel 3:

Undersøgende test af IRCTC-webstedet

=> Klik her for at downloade eksempler på testtilfælde fra Exploratory Testing på IRCTC-webstedet.

Testmetode

  • Brug heuristikker til at guide test.
  • Udførelse af testsager og oprettelse af testsager går hånd i hånd.
  • Testcases udvikler sig fortsat baseret på testobservation og læring.
  • Forskellige testteknikker som Grænseværdianalyse , ækvivalens test osv. kan anvendes på ET.
  • Sessionsbaseret ET kan bruges til at gøre det mere struktureret og fokuseret.
  • Testere kan forgrene deres ideer, men afviger aldrig fra din mission.
  • ET-test bruger ikke scripts, men afhænger i stedet af testers intuition, dygtighed og erfaring.

Fordele

Fordelene ved denne test inkluderer:

  • Fremme realtids tænkning og hjælper med at afdække flere mangler.
  • Fremme brugssager og scenariebaseret test.
  • Minimal dokumentation, maksimal test.
  • Der lægges mere vægt på at lære og udvide en testers horisont.
  • Undgå dobbeltarbejde.
  • Nyttigt, når du vil kontrollere andre testers arbejde.

Ulemper

Nedsættelser er anført nedenfor:

  • Test afhænger af testers erfaring, dygtighed og viden.
  • Kræver tid til at lære applikationen. Det er mere sandsynligt, at testeren går glip af, hvis de ved mindre om applikationen.
  • Ikke egnet til projekter med lang udførelsestid.

Sessionsbaseret sonderende test

Mens testende test er meget vanskeligt for testere at sætte ord på, hvor meget han har testet, og på hvilket grundlag.

Dybest set er det svært at kvantificere arbejdet og den brugte tid. I hvert projekt er vi dog nødt til at levere målinger, estimater og statusrapporter til teamledere og ledere. Som man siger, 'hvis du ikke kan kvantificere det, kan du ikke klare det'.

Sessionsbaseret test er en tidsbaseret tilgang til at udføre denne test, som hjælper med styring og sporing. Det inkluderer en dedikeret testboks med tidsbokse uden afbrydelse fra e-mail, telefon, meddelelser osv.

Nærme sig:

Testopgaver er opdelt i sessioner.

Følgende er komponenterne i session-baseret test (SBT):

  • Mission: Mission råber formålet med sessionen og giver på en måde testeren fokus. Det inkluderer også en sessionstids varighed.
  • Charter: Omfatter testens omfang. Dybest set en dagsorden, der beskriver de mål, der skal afsluttes under sessionen.

Eksempel på testcharter for loginfunktionalitet på hjemmesiden til hjemmepleje:

Eksempel på testcharter for loginfunktionalitet

  • Session: Foruddefineret testboks med tidsbokse uden afbrydelse. Hver session kan have følgende varighed:
    • “Kort” (60 minutter)
    • 'Normal' (90 minutter)
    • “Lang” (120 min)
  • Sessionsrapport: Inkluder noter og letvægtsrapport for at give metrics til lederne og lederne. Det giver detaljer om den resterende eller udførte chartersession, sessionens opsætningstid, testet scenario, om testprocessen, en liste over fejl og de fundne problemer og anden information til metrics.
  • Session de-brief: Et kort møde eller stand-up mellem testeren og Test Lead / Manager for at gennemgå testsessionens resultater.

Ledere kan få praktisk måling baseret på sessionsrapport:

  • Antallet af afsluttede og resterende sessioner.
  • Antallet af rapporterede fejl.
  • Tid brugt på sessionopsætning.
  • Tid brugt på testning.
  • Tid brugt på at analysere problemer eller problemer.
  • Funktioner dækket.

For at sammenfatte ovenstående:

SBT giver mulighed for ansvarlighed er udforskende test og giver bedre styring af den tid, der bruges på testningen. Det øger også produktiviteten og giver bedre forståelse for bugdetektion. Det er en fantastisk måde at give teamledere og ledere metrics til at kontrollere projektets fremskridt.

Parbaseret sonderende test

Parringstest er en tilgang, hvor to personer tester den samme ting / funktion i applikationen på samme tid ved at dele en pc. De deler løbende deres tanker og ideer. Under denne test tager den ene ansvar for tastaturet, mens den anden person foreslår testsager og noterer sig.

Det er altid nyttigt at have en god kommunikation mellem partnerne, så begge er opmærksomme på, hvad der gøres, og hvorfor. Et par, hvor testernes styrke indbyrdes supplerer deres svaghed, betragtes som en stærk gruppering.

Sådan parring gavner begge parter, og hver kan lære noget af deres partner. Det er også en god måde at træne nye ressourcer på ved at parre dem med erfarne ressourcer.

Fordele ved parringstest

  • Hjælper en tester med at fokusere på den aktuelle opgave.
  • Tilskynd gensidig tillid og respekt blandt partnere.
  • Brainstorming mellem parrede testere fører normalt til mere konstruktive ideer.
  • Undgå tunnelsyn.
  • Der er en mindre chance for, at andre afbryder dem.

Undersøgende testteknikker

Ture: Det er en simpel teknik, der gør det muligt for en tester at bruge sin fantasi og tænke på sig selv som en turist, der udforsker en by, han besøger. Her er en ansøgning om at teste byen og testere er turisterne. Det er meget vanskeligt at udforske hele byen, medmindre du har meget tid og penge i hånden, så en turist skal have en plan med et bestemt mål i tankerne.

En turist kan tage følgende ture:

  • Guidebog-rundvisning - Test af fremhævet funktion i applikationen. Brug brugerbaserede scenarier.
  • Udforsk byens historie - Test gamle funktioner i en applikation.
  • Penge tur, hvilket betyder at sikre, at alle de kritiske funktioner i forhold til kunden eller klienten testes og fungerer med succes.
  • Kriminalitet tur - Indtast ugyldigt input og test negative scenarier.
  • Tilbagegangstur - Test de mindst anvendte funktioner i applikationen.
  • Kedelig tur - Brug minimum tid på hver skærm i applikationen, udfyld minimumsfelter og tag den korteste vej. Dette hjælper med standardværdien og valideringstesten.

Mens du tager en tur, har du altid valget mellem at tage en hvilken som helst rute. Du kan navigere gennem software og finde en unik sti til at teste funktionen.

Nedenfor er nogle tip / tricks, som du kan bruge i ET:

  • Opdel applikationen i moduler og del to moduler i forskellige sider. Start din ET fra siderne. Dette giver den rigtige dækning.
  • Lav en tjekliste med alle funktionerne, og sæt et flueben, når det er dækket.
  • Start med et grundlæggende scenario, og forbedr det derefter gradvist for at tilføje flere funktioner til at teste det.
  • Test alle indtastningsfelterne.
  • Test for fejlmeddelelsen
  • Test alle de negative scenarier.
  • Kontroller GUI mod standarderne.
  • Kontroller integrationen af ​​applikationen med andre eksterne applikationer.
  • Kontroller for kompleks forretningslogik.
  • Prøv at foretage den etiske hacking af applikationen.

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

  • Formålet med projektet
  • Teststrategi
  • Testmålet for en bestemt fase
  • Tilgængelige værktøjer og faciliteter
  • Testers rolle og færdigheder
  • Tilgængelig tid
  • Ledelsessupport
  • Peer-support
  • Tilgængelige ressourcer (studiemateriale, testbetingelser osv.)
  • Kundernes interesse
  • Produktets forståelighed.
  • Applikationens brugergrænseflade
  • Applikationens funktionalitet
  • Tidligere testresultater
  • Risici forbundet med applikationen
  • Tidligere mangler
  • Seneste ændringer
  • Typer af data, der skal bruges til testning
  • Type bruger, der skal bruge den

I stedet for at spørge testerne, hvad de skal køre, overlader vi det til testernes vurdering at beslutte, hvad de vil teste, og hvordan de vil teste.

Forskel mellem sonderende test og ad hoc-test

Bland ikke ET med Ad-hoc test .

  • Ad-hoc-test henviser til en proces med uskrevet, ikke-planlagt og improviseret fejlsøgning, mens sonderende test er en tankevækkende metode til ad-hoc-test.
  • Ad-hoc-test er en hit and trial-metode til at finde en fejl, mens ET ikke er det. I ET-tilgang lærer en tester om systemet, når de udforsker og til sidst udvikler testene ved hjælp af den erhvervede viden.
  • Ad-hoc-test er en ustruktureret aktivitet, mens ET er noget en struktureret aktivitet.

Eksplorativ automatiseret test (EAT)

Exploratory Automated Testing er en metode, der hjælper en tester med at strømline fejlrapportering og reproduktion, snapshots-indsamling og forberedelse af fremtidig regressionsdragt. Det er en proces, der kombinerer automatiseringstest med sonderende test.

Der er to typer af EAT-tilgang:

  • Passiv SPIS
  • Aktiv EAT

Passiv SPIS

Passiv EAT kan også udføres af en enkelt tester eller i et par. I denne metode er det normalt et værktøj, der registrerer og registrerer hver eneste aktivitet, der udføres af en testressource (r) og installeres på ressourceens pc.

Passiv EAT svarer til ET, der udføres manuelt, da der ikke er nogen ændring i den måde, testene udføres på, bortset fra at udarbejde testresultatet baseret på den fangede session. Disse testresultater kan bruges til rapportering og genoptagelse af registrerede handlinger senere i tiden.

Det installerede videoværktøj hjælper en tester med test case-registrering og rapportering af mangler.

Det har også få andre fordele som:

  • Giver klare trin til at gengive bugs.
  • Det er lettere at gengive mangler, selv når manglereporteren ikke er tilgængelig.
  • Fjern konflikterne mellem test- og udviklingsteamet, når der rapporteres om en intermitterende fejl.
  • Hjælper med ydelsestest ved at få systemets responstid på det specifikke tidspunkt.

Her er nogle få andre punkter, der skal tages i betragtning før Passiv EAT:

  • Det tilrådes at udføre en pilottest, før værktøjet tilpasser sig helt til Automated EAT. Dette er for at sikre, at den tid, der kræves til re-design af testlogfiler, der er oprettet under testsessionen, ikke er mere end testudførelse. I så fald skal holdet tage en gensidig beslutning om følgende:
    • Hvis det overhovedet er testautomatisering nødvendigt for det pågældende projekt.
    • Hvis det anvendte værktøj skal udskiftes.
    • Hvis effektiviteten af ​​det anvendte værktøj kan optimeres.
  • Det værktøj, der bruges til at udføre automatiseret EAT, skal installeres på alle testressourcer, der er involveret i testningen. Det er også en god ide at involvere udviklerne, som kan opnås ved enten at give udviklerne VPN eller fjernadgang til testmaskiner eller ved at installere værktøjet i udviklingsmiljøet.
  • Det er altid en god ide at have GUI-objektet til applikationen organiseret i testværktøjet, så når tiden er inde til at analysere fejlen eller et problem, kan objektet genkendes på grund af et meningsfuldt navn.
  • Det er en god praksis at give et meningsfuldt navn til GUI-objektet, der bruges i AUT, og holde dem organiseret til senere brug.

Lad os nu gå videre til den anden tilgang.

Aktiv EAT

Det tilrådes at udføre Active EAT med par-test. I denne tilgang bruges Keyword Driven-testen i synkronisering med Session-test. Én tester opretter det automatiske testscript, og det andet tester udfører testscripts oprettet af den første tester.

Oprettelse af automatiseringstestscripts i denne tilgang tager en anden vej end ved konventionel test. Automatiske testskripter laves under testningen, og hvad der er blevet opdaget i de tidligere tests bestemmer deres design.

En afslutningsfase udføres i slutningen af ​​testsessionen. Og det skal have følgende opgaver:

  • De involverede testere bør bytte roller, så testressourcen, der oprettede testscriptet, har en chance for at genudføre scripts for at bekræfte pålideligheden og robustheden af ​​den oprettede suite.
  • En kort beskrivelse sammen med få identificerende egenskaber skal gives til hvert automatiseret testscript.
  • Der skal defineres et kriterium for at identificere, hvilke automatiserede test-scripts, der kan bruges til regressionstest.

Fordele ved EAT

  • I starten af ​​hver session udføres allerede oprettede automatiserede testscripts, hvilket forbedrer testdækningen hver gang.
  • Bedre fejlrapportering og dokumentation til reproduktion af mangler.
  • EAT giver tilstrækkelig dokumentation og dokumentation til, at en interessent kan se fremskridtene.

Typer af sonderende test

Nedenfor er et par typer ET:

1) Freestyle OG:

Undersøgelse af anvendelse i ad hoc-stil.

I denne type ET er der ingen regler, ingen konto for dækning osv. Denne type test er dog god, når du har brug for at blive fortrolig med applikationen hurtigt, når du vil kontrollere de andre testers arbejde, og når du vil undersøge en defekt eller ønsker at lave en hurtig røgtest.

2) Scenariobaseret ET:

Som navnet selv antyder, er test udført scenariobaseret. Det starter med ægte brugerscenarier, end-to-end-scenarier eller testscenarier. Efter indledende test kan testere injicere variation i henhold til deres læring og observation.

Scenarier er som en generisk guide til, hvad man skal gøre under ET. Testere opfordres til at udforske flere mulige stier, mens de udfører et scenarie for at sikre alle mulige stier til funktionsarbejde. Testere bør også sørge for at samle så mange scenarier som muligt fra forskellige kategorier.

3) Strategibaseret ET:

Kendte testteknikker som grænseværdianalyse, ækvivalensteknik og risikobaseret teknik, der er kombineret med sonderende test. En erfaren tester eller en tester, der er fortrolig med applikationen, udpeges til denne type test.

Agil sonderende test

Selvom du ikke har arbejdet i et smidigt miljø, er jeg sikker på at du skal have læst eller hørt om det på grund af dets voksende popularitet. Agil metode har korte sprints og stramme deadlines, hvilket giver et hold et par uger til at afslutte planlægning, estimering, udvikling, kodning, test og frigivelse.

Undersøgende test bliver praktisk i så stramme tidsfrister, fordi der i denne testtilgang lægges vægt på det hurtige og nyttige resultat. Når du har forstået kravet, kan du starte test baseret på din erfaring og viden.

Når du er fortrolig med applikationsfunktionerne og adfærden, kan du designe flere testtilfælde for at validere applikationsfunktionaliteten og opdage ikke-planlagte fejl. Da det er en freestyle-testtilgang, skal du dokumentere alt. Du skal dog vedligeholde noter og en kort rapport om, hvad du har testet, fejl og fundne problemer osv.

Fortjeneste ved Exploratory in Agile

  • Beviser feedback til udviklerne så hurtigt som muligt.
  • En bredere række mangler afdækkes.
  • En forskellig gruppe af en ressource som en udvikler, tester, BA, designere kan udføre ET, da der ikke er nogen scripted testcases, og hver bringer et andet perspektiv.
  • Scouting udført i ET hjælper med at udforske nye territorier og udsætte kritiske fejl.
  • I tilfælde af Iterativ kodning af en applikation kan ET fokusere på at teste nye funktioner, mens automatisering foretager regression og bagudkompatibilitetstest.
  • I tilfælde af ustabilt krav kan ET hjælpe med at teste nye krav inden for en begrænset periode.

Punkter at huske:

1. Kræver forskellige færdigheder: Testere, der udfører ET, skal have gode lytte-, læse-, tænke- og rapporteringsevner. Domæneoplevelse er påkrævet, da der ikke er nogen scripts og testsager.

2. Nogle gange er det svært at Anmeld en fejl: Mens vi er i en ET-strøm, kan vi støde på en defekt, men vi kan muligvis ikke reproducere den. Dette skyldes, at vi ikke sporer testtrinene, og vi kan glemme de nøjagtige trin til at gengive problemet.

3. Kan gøres som rekreativ aktivitet: Jeg laver personligt ET, når jeg vil have en pause fra min regelmæssige testudførelsescyklus. Men mange hold har ET som en separat fase af deres testcyklus.

4. Det kan gøres i alle testfaser: Vi kan implementere ET inden begyndelsen af ​​en testfase. Du kan udføre ET selv inden den funktionelle testfase.

5. Hurtig feedback: ET kræver hurtig feedback om problemerne og eventuelle uregelmæssigheder, der opstår.

6. Kritisk tænkning og forskellige ideer: Denne test kræver kritisk tænkning. Testere skal være i stand til at reproducere, gennemgå og udtrykke deres ideer på en logisk måde. En tester kan implementere hendes erfaring i de forskellige teknologier og domæner, de arbejdede på.

Hvordan man tænker ud over traditionelle testgrænser i sonderende test

”Jeg sætter stor pris på din bekymring for produktet og gør os nyttige i et forståeligt slutbrugerperspektiv. Det vil være meget nyttigt. Tak for det gode arbejde og fortsæt det !!! ”

Dette var den sidste e-mail i en e-mail-kæde med 21 e-mails fra vores klient. Det var midnat, og vores produktudgivelse blev forsinket på grund af en kritisk fejl, vi fandt. Du tænker måske, hvad er nyt i det? Det kan ske mange gange. Men dette var virkelig anderledes, da den kritiske fejl, vi rapporterede, ikke var et resultat af nogen dokumenteret testsag.

Efter afslutning regressionstest for sidste gang den aften spillede jeg bare med produktet. Hvad betyder det? Du er fri til at gøre, hvad du ikke skal gøre. Baseret på min erfaring og projektviden havde jeg nogle ideer til, hvordan jeg kunne teste produktet bortset fra vores typiske testlager, hedder Undersøgende test .

Den udforskende test udført fandt en kritisk fejl relateret til et server-hang-problem, mens man gjorde noget uventet.

At være fan af sonderende test, elsker jeg at udforske produktet på forskellige måder. For mig er definitionen af ​​software:

”Den skal gøre, hvad den skal gøre, og den skal ikke gøre, hvad den ikke skal gøre.”

Undersøgende testproces

At begrænse testgrænser for at kontrollere, om produkter, der skal fungere, gør dig til en ufuldstændig tester. Faktisk starter en testers liv, når dokumenteret regressionstest slutter, og resultaterne opdateres. At se på produkter fra forskellige perspektiver og forstå slutbrugernes krav i forskellige scenarier gør en stor forskel. Så i dag, lad os forstå sammen, hvordan denne forskel kan gøres:

Hvordan ser man på et produkt fra forskellige perspektiver?

sonderende test

# 1. Forstå kunde / slutbruger

Softwaretest handler om at kontrollere produktets kvalitet med hensyn til kundetilfredshed. Hvordan kender du kundens synspunkt? Svaret er simpelt - du skal være kunde. OK, lad mig foretage en korrektion. At være kunde vil ikke være nok. Du skal forstå, hvordan kunden ønsker at håndtere produktet. Ingen kunder, der har købt samme råvarer, forbereder den samme opskrift. Ja, det produkt, vi udvikler / leverer, er et råmateriale til kundens virksomheder, og de har en anden tankegang, når de bruger det.

Som softwaretester skal vi kontrollere produktets formål og ikke genstanden eller aspektet af det.

Lad mig give dig nogle praktiske eksempler i det virkelige liv:

  • Saksen var aldrig begrænset til kun at skære papir. Skæring er formålet og ikke papiret (objektet).
  • Mobiltelefoner var aldrig begrænset til kun at ringe, men 'stand til at ringe' har altid været det grundlæggende formål.
  • Opbevaringsbokse bruges til opbevaring, men sikkerheden ved det opbevarede materiale er lige så vigtig som opbevaring.

Forståelse af interessenter og en bred vifte af deres forventninger bør være grundlaget for sonderende test.

# 2. En tankegang

Mens du leder efter (lad os sige) en jobannonce, ser du den jackpot og mellem siderne med den fed skrift? De fleste af os gør det ikke (tro mig, det er sandt). Fordi vi har instrueret vores sind om at se efter, hvad der er nyttigt eller kontrolleres. Alt andet nytter ikke, så sindet nægter os at genkende det.

Åbn dit sind, og sæt ikke nogen forventninger, når du begynder at udforske et produkt . Husk altid, at det ikke er OK, hvis produktet gør, hvad det skal. Det er også vigtigt, at det ikke skal gøre, hvad det ikke skal.

Jeg husker et klassisk eksempel:

I Linux bruges 'cat' kommando til at kontrollere indholdet af en fil, og kommandoen 'ls' er til at kontrollere indholdet af biblioteket. Arbejdede med Linux og var i softwaretest i fem år, jeg tænkte aldrig på at lave kat, fordi mit sind var sat; hvis jeg havde brug for dir-indhold, skal jeg bruge 'ls'. Det fungerede, men den modsatte side af forventningen er, at produktet ikke skulle opføre sig som det ikke skulle, var forkert. En af vores kunder, der ikke kendte Linux godt, katte ved en fejltagelse, og systemet styrtede ned. Vi betalte for denne tankegang.

Vær altid klar til at lave fejl med softwaren, for det er det slutbrugeren vil gøre. For at teste softwaren er du blevet uddannet, men slutbrugeren vil ikke være så trænet som dig eller han / hun vil ikke være så meget af en teknisk ekspert som dig. Han / hun vil også gøre noget med softwaren, når de er i problemer.

Tænk over disse scenarier, og giv testfeedback. Livet til softwaren og din (som tester) vil rocke.

# 3. Kend konkurrenterne

Forsøgte du nogensinde at kende og forstå anden software med det samme formål, mens du testede en softwareapplikation til din klient? Foreslog du nogensinde nogle nyttige funktioner, du observerede i en konkurrents produkt? Det falder ikke i vores jobbeskrivelse, er det typiske svar. Men ved du fordelen ved at gøre det?

Her er få eksempler fra det virkelige liv, der får dig til at forstå pointen:

  • Kan du ikke lide designeren, der ikke kun syr din kjole, men også giver dig input om matchende tilbehør mest?
  • Kan du ikke lide pizzamærket, der ikke kun laver gode pizzaer, men som leverer hjemme til tiden mest?
  • Kan du ikke lide fotografen, der ikke kun tager gode fotografier, men foreslår en anden slags rammer til fotoshoot?

Alle vil have noget ekstra for det, de betaler for. Vores analyse af konkurrencedygtig software kan fungere på samme måde for os. Kunden kan altid lide at høre værdifulde forslag - hovedsageligt komparative forslag for at gøre produktet mere nyttigt eller salgbart.

sql grundlæggende interview spørgsmål og svar pdf

Også denne form for sammenligning og analyse af det samme produktsortiment gør vores analyse mere kraftfuld, og til sidst skaber vi en skat, som vi til enhver tid kan vende tilbage til og finde noget nyttigt.

Konklusion

Exploratory kommer ikke under en konventionel måde at teste på, men det er stadig en meget kraftfuld måde at teste på.

Det bringer en testers tankegang ud af boksen og tilskynder dem til at komme med praktiske og realtids testsager for at finde en defekt. Dens freestyle-natur giver det et forspring i forhold til de andre testtyper og kan udføres hvor som helst, det være sig et projekt, der bruger Agile eller vandfald eller ethvert andet projekt, der kræver minimal dokumentation.

Succesen med sonderende test afhænger af adskillige immaterielle ting som en testers dygtighed, evnen til at skabe effektive testtilfælde, deres erfaring og evnen til at følge deres tarmfølelse.

Det er bydende nødvendigt at huske, at ET er en adaptiv proces snarere end en forudsigende, og det er vigtigt at opretholde en sund balance mellem udforskende og scripted eller regelmæssig test.

Er du en tester, der har typiske sonderende testoplevelser? Vi venter på at høre dine tanker. Del dem gerne i kommentarfeltet nedenfor.

Næste tutorial # 2: Sådan bruges ture til at sikre komplet sonderende test

Anbefalet læsning

^