Meny

Vad är Exploratory Testing i Software Testing (En komplett guide)

  • Huvud
  • Övrig
  • Vad är Exploratory Testing i Software Testing (En komplett guide)

what is exploratory testing software testing

Prova Vårt Instrument För Att Eliminera Problem

Vad är Exploratory Testing?

'Exploratory testing' - som namnet antyder, är en samtidig inlärning, testdesign och testkörningsprocess. Vi kan säga att i detta test testplanering, analys, design och testkörning, görs alla tillsammans och omedelbart.

Denna testning handlar om att utforska systemet och uppmuntra testare i realtid och praktiskt tänkande.

I denna serie har vi täckt följande handledning:

Handledning nr 1: Vad är Exploratory Testing i Software Testing (Denna handledning)
Handledning nr 2: Använda turer för att säkerställa fullständig utforskande testning
Självstudie 3: Exploratory Testing vs Scripted Testing
Självstudie 4: Exploratory Testing with HP Sprinter
Handledning nr 5: Topp 17 Exploratory Testing Tools

************************************
Exploratory Testing

Vad du kommer att lära dig:

Översikt

I lekmän termer innebär utforskande testning samtidig testdesign och testkörning av en applikation eller ett system som testas. Testaren kommer att skapa eller skriva ner en testidé för att ge vägledning och utforska systemet under testningen för att ytterligare skapa kritiska, praktiska och användbara tester för en framgångsrik testning av en applikation.

Detta kräver minimal planering. Testare fattar kontinuerligt ett beslut om hennes nästa steg. Det beror helt på testarens tankeprocess.

Ibland kan denna testning vara mer fördelaktig än den formella testmetoden för hitta några subtila defekter som saknas vid formell testning.

Medvetet eller omedvetet skulle varje testare ha gjort undersökande någon gång i sin karriär.

Som vi alla vet kommer en elev att lära sig bättre genom praktisk erfarenhet snarare än att klämma in teorin.

På samma sätt kommer en testare att känna till applikationen bara bättre när han utforskar och lär sig om alla funktioner som den tillhandahåller av sig själv. Det är alltid bra att ha ett kund- och affärsperspektiv under testningen för att säkerställa framgångsrik testning av en applikation.

Till exempel, om du öppnar en shoppingwebbplats har du en allmän uppfattning om att den här shoppingwebbplatsen låter dig handla genom att välja en produkt efter eget val och sedan betala för samma.

Under denna process kan du lära dig att webbplatsen ger dig virtuellt mänskligt utseende som hjälper dig i produktvalsprocessen. Du upptäckte också att du kan beställa ett antal produkter för hemförsök eller att du kan betala genom belöningspoäng från vissa banker etc.

Som testare behöver du inte bara verifiera om ett system fungerar som förväntat utan också kontrollera om det inte fungerar på ett sätt som inte förväntas.

Få saker att komma ihåg när du utför denna testning:

  • Ditt uppdrag ska vara klart.
  • Se till att skapa anteckningar och rapportera om vad du gör och hur ett system beter sig, vilket kan vara ett potentiellt fel.
  • Lär dig, observera och kom sedan med nya testfall.

Rekommenderad Exploratory Testing Service

# 1) Digivante Direct

Digivante Direct-logotyp

Digivante Direct utför undersökande test med sitt globala nätverk av professionella testare så att du kan täcka testning på alla större enheter i en tidsskala som inte kan nås av någon annan testleverantör eller internt team.

Släpp snabbare, säkrare och låt dina digitala plattformar leverera högre kundnöjdhet och ökade onlineintäkter.

Funktioner:

  • 24 arbetsdagar med testning på bara 24 timmar eller 90 arbetsdagar på 72 timmar, och oöverträffad, omfattande testnivå som inte kan nås på något annat sätt.
  • Låg kostnad , lättförståeliga prissättningspaket utan dolda tillägg.
  • Självbetjäning online-portal som inte kräver något löpande åtagande.
  • Verkliga människor testar på riktiga enheter - mycket större enhets- och webbläsartäckning än vad du kan uppnå internt och allt inom snabbare behandlingstid.
  • Komplett testande täckning - minska risken och förbättra slutanvändarnöjdheten och omvandlingsfrekvensen och därmed öka intäkterna samtidigt som kostnaderna minskas.
=> Besök Digivante Direct-webbplatsen

Exploratory Testing Exempel

Exempel 1:

En hemsjukvårdsleverantörswebbplats med följande komponenter:

  • Logga in
  • Tjänster
  • Vagn
  • Betalning
  • Beställningshistorik
  • Tilldelning av tekniker

En allmän idé att börja utforskande testning är att logga in eller boka en tjänst.

Hur man täcker testfall?

Exploratory test testfall

typ av defekter i programvarutestning

I ovanstående Exempel, tanken är att börja med funktionalitet baserat på din kunskap. När du lär dig och observerar mer om applikationen kan du styra din nästa uppsättning testfall.

Exempel 2:

Jag ingick en gång i ett litet projekt som innebar tillägget av en ny fond i ansökan. Min uppgift var att testa ansökan för att se till att den nya fonden är tillgänglig för användare att köpa och kontrollera om tillhörande värdering är korrekt. Jag hade bara två dagar på mig att slutföra testningen.

Med tanke på att testerna var strama och hur allvarliga det var, använde jag det utforskande sättet att testa. Mitt mål var att testa nya funktioner och hitta överträdelser av kompatibilitetskraven.

Ovan nämnda mål blev min stadga för denna testperiod.

Följande testfall utvecklades under denna testning:

  • Testar för att se till att den nya fonden har lagts till i ansökan.
  • Ny MF köpt framgångsrikt.
  • Värdering av ny MF är korrekt.
  • Försökte köpa ny MF för en befintlig portfölj.
  • Kan ny MF läggas till i alla portföljer?
  • Inverkan av nya MF på en värdering av befintlig.
  • Så i andra testfall utvecklades.

Jag utarbetade anteckningar och rapporter under mina tester för att diskutera min observation med BA och klienten.

Den grundläggande strategin för utforskande testning är att ha en attackplan. Börja testa med din idé och improvisera nya testfall baserat på din kunskap och observation.

Exempel 3:

Exploratory Testing of IRCTC Website

=> Klicka här för att ladda ner exemplet på testfall av Exploratory Testing på IRCTC-webbplatsen.

Testmetod

  • Använd heuristik för att styra testningen.
  • Utförande av testfall och skapande av testfall går hand i hand.
  • Testfall fortsätter att utvecklas baserat på testarobservation och inlärning.
  • Olika testtekniker som Gränsvärdesanalys , ekvivalensprovning etc. kan tillämpas på ET.
  • Sessionsbaserad ET kan användas för att göra den mer strukturerad och fokuserad.
  • Testare kan förgrena sina idéer men aldrig avvika från ditt uppdrag.
  • ET-test använder inte skript, utan beror på testarens intuition, skicklighet och erfarenhet.

Fördelar

Fördelarna med denna testning inkluderar:

  • Främja tänkande i realtid och hjälper till att upptäcka fler defekter.
  • Främja användningsfall och scenariobaserad testning.
  • Minimal dokumentation, maximal testning.
  • Tyngdpunkten ligger mer på att lära sig och utvidga en testares horisont.
  • Undvik dubbelarbete.
  • Användbar när du vill granska andra testares arbete.

Demeriter

Nedgångar är listade nedan:

  • Testning beror på testarens erfarenhet, skicklighet och kunskap.
  • Kräva tid för att lära sig ansökan. Det är mer sannolikt att testaren missar om de vet mindre om applikationen.
  • Inte lämpligt för projekt med lång exekveringstid.

Sessionsbaserad Exploratory Testing

Under testande är det mycket svårt för testare att sätta ord på hur mycket han har testat och på vilken grund.

I grund och botten är det svårt att kvantifiera arbetet och tiden. I varje projekt måste vi dock tillhandahålla mätvärden, uppskattningar och framstegsrapport till teamledare och chefer. Som man säger, 'om du inte kan kvantifiera det, kan du inte hantera det'.

Sessionsbaserad testning är en tidsbasmetod för att utföra denna testning som hjälper till att hantera och spåra. Den inkluderar en dedikerad testbox utan tidsavbrott från e-post, telefon, meddelanden etc.

Närma sig:

Testuppgifter är indelade i sessioner.

Följande är komponenterna i sessionbaserad testning (SBT):

  • Uppdrag: Uppdraget ropar ut syftet med sessionen och på ett sätt ger testaren fokus. Det kommer också att innehålla en sessionstid.
  • Charter: Inkluderar omfattningen av testningen. I grund och botten en agenda som beskriver de mål som behöver slutföras under sessionen.

Exempel på testcharter för inloggningsfunktionalitet på hemsjukvårdens webbplats:

Exempel på testcharter för inloggningsfunktionalitet

  • Session: Fördefinierad testbox utan tidsavbrott. Varje session kan ha följande varaktighet:
    • “Kort” (60 minuter)
    • 'Normal' (90 minuter)
    • “Lång” (120 min)
  • Sessionsrapport: Inkludera anteckningar och lätt rapport för att ge mätvärden till ledarna och cheferna. Det ger information om återstående eller slutförda chartersession, sessionstid för session, testat scenario, om testprocessen, en lista med buggar och de hittade problemen och annan information för mätvärdena.
  • Session de-brief: Ett kort möte eller stand-up mellan testaren och testledaren / chefen för att granska testresultaten.

Chefer kan få praktisk mätvärde baserat på sessionsrapport:

  • Antalet avslutade och återstående sessioner.
  • Antalet rapporterade buggar.
  • Tid spenderad på sessionens inställning.
  • Tidsbruk på testning.
  • Tid på att analysera problem eller problem.
  • Funktioner täckta.

För att sammanfatta ovanstående:

SBT möjliggör ansvarsskyldighet är utforskande testning och erbjuder bättre hantering av tid som testas. Det ökar också produktiviteten och ger bättre grepp om buggdetektering. Det är ett utmärkt sätt att ge teamledare och chefer mätvärden för att kontrollera projektets framsteg.

Parbaserad utforskande testning

Pair Testing är ett tillvägagångssätt där två personer testar samma sak / funktion i applikationen samtidigt genom att dela en dator. De delar kontinuerligt sina tankar och idéer. Under denna testning tar en person ansvar för tangentbordet medan den andra personen föreslår testfall och noterar.

Det är alltid bra att ha en bra kommunikation mellan parterna så att båda är medvetna om vad som görs och varför. Ett par där testarnas styrka ömsesidigt kompletterar sin svaghet betraktas som en stark gruppering.

Sådan parning gynnar både parterna och var och en kan lära sig något av sin partner. Det är också ett bra sätt att träna nya resurser genom att para ihop dem med erfarna resurser.

Fördelar med parprovning

  • Hjälper en testare att fokusera på uppgiften.
  • Uppmuntra ömsesidigt förtroende och respekt bland partners.
  • Brainstorming mellan parade testare leder vanligtvis till mer konstruktiva idéer.
  • Undvik tunnelsyn.
  • Det finns en mindre chans att andra avbryter dem.

Exploratory Testing Techniques

Rundturer: Det är en enkel teknik som gör att en testare kan använda sin fantasi och tänka på sig själv som en turist som utforskar en stad han besöker. Här är en ansökan om att testa staden och testarna är turisterna. Det är mycket svårt att utforska hela staden om du inte har mycket tid och pengar i handen, så en turist måste ha en plan med ett visst mål i åtanke.

En turist kan ta följande turer:

  • Guidebokstur - Testning av markerad funktion i applikationen. Använd användarbaserade scenarier.
  • Utforska stadens historia - Testa gamla funktioner i en applikation.
  • Pengar turné, vilket innebär att se till att alla kritiska funktioner i referens till kunden eller klienten testas och fungerar framgångsrikt.
  • Brottsturné - Ange ogiltig inmatning och testa negativa scenarier.
  • Back gränd turné - Testa de minst använda funktionerna i applikationen.
  • Tråkig turné - Spendera minsta tid på varje skärm i applikationen, fyll i minsta fält och ta den kortaste vägen. Detta hjälper till med standardvärdet och valideringstestningen.

När du tar en tur har du alltid valet att ta vilken rutt som helst. Du kan navigera genom programvara och hitta en unik sökväg för att testa funktionen.

Nedan följer några tips / tricks som du kan använda i ET:

  • Dela applikationen i moduler och dela upp modulerna på olika sidor. Starta din ET från sidorna. Detta ger rätt täckning.
  • Gör en checklista med alla funktioner och sätt en bock när den är täckt.
  • Börja med ett grundläggande scenario och sedan gradvis förbättra det för att lägga till fler funktioner för att testa det.
  • Testa alla inmatningsfält.
  • Testa felmeddelandet
  • Testa alla negativa scenarier.
  • Kontrollera GUI mot standarderna.
  • Kontrollera integrationen av applikationen med andra externa applikationer.
  • Sök efter komplex affärslogik.
  • Försök göra etisk hackning av applikationen.

Faktorer som påverkar ET är följande:

  • Syftet med projektet
  • Teststrategi
  • Testmålet för en viss fas
  • Tillgängliga verktyg och faciliteter
  • Testarnas roll och färdigheter
  • Tillgänglig tid
  • Ledningsstöd
  • Kamratstöd
  • Tillgängliga resurser (studiematerial, testvillkor etc)
  • Kundernas intresse
  • Produktens förståelse.
  • Programmets användargränssnitt
  • Applikationens funktionalitet
  • Tidigare testresultat
  • Risker förknippade med applikationen
  • Tidigare brister
  • Senaste ändringarna
  • Typer av data som ska användas för testning
  • Typ av användare som kommer att använda den

Istället för att fråga testarna vad de ska springa, låter vi det testa bedömningen att bestämma vad de vill testa och hur de vill testa.

Skillnad mellan Exploratory Testing och Ad-hoc Testing

Blanda inte ET med Ad-hoc-test .

  • Ad-hoc-testning avser en process med oskriptad, oplanerad och improviserad defektsökning medan utforskande testning är en genomtänkt metod för ad-hoc-testning.
  • Ad-hoc-testning är en hit och testmetod för att hitta ett fel medan ET inte är det. I ET-tillvägagångssätt lär sig en testare om systemet när de utforskar och så småningom utvecklar testerna med hjälp av den förvärvade kunskapen.
  • Ad-hoc-testning är en ostrukturerad aktivitet medan ET är något en strukturerad aktivitet.

Exploratory Automated Testing (EAT)

Exploratory Automated Testing är en metod som hjälper en testare att effektivisera felrapportering och reproduktion, samla ögonblicksbilder och förbereda en framtida regressionsdräkt. Det är en process som kombinerar automatiseringstest med Exploratory testing.

Det finns två typer av EAT-tillvägagångssätt:

  • Passiv EAT
  • Aktiv EAT

Passiv EAT

Passiv EAT kan utföras av en enda testare eller i ett par också. I denna metod är vanligtvis ett verktyg som registrerar och registrerar varje enskild aktivitet som utförs av en testresurs (er) och installeras på resursens dator.

Passiv EAT liknar ET som utförs manuellt eftersom det inte sker någon förändring i hur testen utförs bortsett från att skapa testresultatet baserat på den fångade sessionen. Dessa testresultat kan användas för rapportering och återskapande av inspelade åtgärder senare i tiden.

Det installerade videoverktyget hjälper en testare med inspelning av testfall och rapportering av fel.

Det har också få andra fördelar som:

  • Ger tydliga steg för att reproducera buggarna.
  • Det är lättare att reproducera defekter även när defektrapporten inte är tillgänglig.
  • Ta bort konflikterna mellan test- och utvecklingsteamet när ett intermittent fel rapporteras.
  • Hjälper vid prestandatestning genom att få systemets svarstid vid den specifika tidpunkten.

Här är några andra punkter som ska tas i beaktande före Passiv EAT:

  • Det rekommenderas att utföra ett pilottest innan verktyget helt anpassas för Automated EAT. Detta för att säkerställa att den tid som krävs för att omforma de testloggar som skapats under testsessionen inte är mer än testkörningen. Om så är fallet måste laget ta ett gemensamt beslut om följande:
    • Om det alls krävs testautomatisering för det specifika projektet.
    • Om verktyget som används behöver bytas ut.
    • Om prestanda för verktyget som används kan optimeras.
  • Verktyget som används för att utföra automatiserad EAT måste installeras på varje testresurs som är involverad i testningen. Det är också en bra idé att involvera utvecklarna som kan uppnås genom att antingen ge utvecklarna VPN eller fjärråtkomst till testmaskiner eller genom att installera verktyget i utvecklingsmiljön.
  • Det är alltid en bra idé att ha ett GUI-objekt för applikationen organiserat i testverktyget så att när det är dags att analysera felet eller ett problem kan objektet kännas igen på grund av ett meningsfullt namn.
  • Det är en bra metod att ge ett meningsfullt namn till GUI-objektet som används i AUT och hålla dem organiserade för senare användning.

Nu går vi vidare till den andra metoden.

Aktiv EAT

Det är tillrådligt att utföra Active EAT med Pair Testing. I detta tillvägagångssätt används nyckelordsdriven testning synkroniserad med sessionstestning. En testare skapar det automatiska testskriptet och den andra testaren kör testskripten som skapats av den första testaren.

Skapandet av automatiseringstestskript i detta tillvägagångssätt tar en annan väg än vid konventionell testning. Automatiserade testskript görs under testningen och vad som har upptäckts i tidigare tester avgör deras design.

En avslutningsfas utförs i slutet av testsessionen. Och det bör ha följande uppgifter:

  • Inblandade testare bör byta roller så att testresursen som skapade testskriptet har en chans att köra skripten på nytt för att bekräfta tillförlitligheten och robustheten i den skapade sviten.
  • En kort beskrivning tillsammans med få identifierande egenskaper bör ges för varje automatiserat testskript.
  • Ett kriterium måste definieras för att identifiera vilka automatiserade testskript som kan användas för regressionstest.

Fördelar med EAT

  • I början av varje session körs redan skapade automatiserade testskript, vilket förbättrar testtäckningen varje gång.
  • Bättre felrapportering och dokumentation för reproduktion av defekter.
  • EAT ger tillräckligt med bevis och dokumentation för att en intressent ska kunna se framstegen.

Typer av utforskande testning

Nedan följer några få typer av ET:

1) Freestyle OCH:

Utforskning av applikation i ad hoc-stil.

I den här typen av ET finns det inga regler, inget konto för täckning osv. Denna typ av testning är dock bra när du behöver bekanta dig med applikationen snabbt, när du vill verifiera de andra testarnas arbete och när du vill undersöka en defekt eller vill göra ett snabbt röktest.

2) Scenariobaserad ET:

Som själva namnet antyder är testet gjort scenariobaserat. Det börjar med riktiga användarscenarier, end-to-end-scenarier eller testscenarier. Efter inledande testning kan testare injicera variation enligt deras inlärning och observation.

Scenarier är som en allmän guide för vad man ska göra under ET. Testare uppmuntras att utforska flera möjliga vägar medan de utför ett scenario för att säkerställa alla möjliga vägar till funktionsarbete. Testare bör också se till att samla så många scenarier som möjligt från olika kategorier.

3) Strategibaserad ET:

Kända testtekniker som gränsvärdesanalys, ekvivalensteknik och riskbaserad teknik som kombineras med utforskande testning. En erfaren testare eller en testare som är bekant med applikationen utses för denna typ av testning.

Agile Exploratory Testing

Även om du inte har arbetat i en smidig miljö är jag säker på att du måste ha läst eller hört talas om det på grund av dess växande popularitet. Agil metodik har korta sprints och snäva deadlines vilket ger ett team några veckor att avsluta planering, uppskattning, utveckling, kodning, testning och release.

Explorerande testning blir praktiskt i så snäva tidsfrister, eftersom man i denna testmetod lägger vikt vid det snabba och användbara resultatet. När du väl har förstått kravet kan du börja testa baserat på din erfarenhet och kunskap.

När du väl är bekant med applikationsfunktionerna och beteendet kan du designa fler testfall för att validera applikationsfunktionaliteten och upptäcka oplanerade buggar. Eftersom det är en freestyle testmetod måste du dokumentera allt. Du måste dock behålla anteckningar och en kort rapport om vad du har testat, buggar och problem hittats etc.

Meriter av Exploratory in Agile

  • Bevisa feedback till utvecklarna så snart som möjligt.
  • Ett bredare utbud av fel upptäcks.
  • En mångskiftande grupp av en resurs som en utvecklare, testare, BA, designers kan utföra ET eftersom det inte finns några skripta testfall och var och en ger ett annat perspektiv.
  • Scouting gjort i ET hjälper till att utforska nya territorier och avslöja kritiska buggar.
  • Vid Iterativ kodning av en applikation kan ET fokusera på att testa nya funktioner medan automatisering gör regression och bakåtkompatibilitetstestning.
  • Vid instabila krav kan ET hjälpa till att testa nya krav inom en begränsad tid.

Poäng att komma ihåg:

1. Kräver olika färdigheter: Testarna som utför ET behöver ha goda lyssnings-, läs-, tänk- och rapporteringsförmågor. Domänerfarenhet krävs eftersom det inte finns några skript och testfall.

2. Ibland är det svårt att göra det rapportera en bugg: I ett ET-flöde kan vi stöta på en defekt men vi kanske inte kan reproducera den. Detta beror på att vi inte spårar teststegen och vi kan glömma de exakta stegen för att återskapa problemet.

3. Kan göras som rekreationsaktivitet: Jag gör personligen ET när jag vill ha en paus från min vanliga testkörningscykel. Men många lag har ET som en separat fas i sin testcykel.

4. Det kan göras för alla testfaser: Vi kan implementera ET före början av en testfas. Du kan utföra ET även före funktionell testfas.

5. Snabb feedback: ET kräver snabb återkoppling om problemen och eventuella avvikelser.

6. Kritiskt tänkande och olika idéer: Denna testning kräver kritiskt tänkande. Testare ska kunna reproducera, granska och uttrycka sina idéer på ett logiskt sätt. En testare kan implementera sin erfarenhet av de olika teknikerna och domänerna de arbetade med.

Hur man tänker bortom traditionella testgränser i Exploratory Testing

”Jag uppskattar verkligen din oro för produkten och gör oss hjälpsamma i ett förståeligt slutanvändarperspektiv. Det kommer att vara till stor hjälp. Tack för det goda arbetet och fortsätt !!! ”

Detta var det sista e-postmeddelandet från en e-postkedja med 21 e-postmeddelanden från vår klient. Det var midnatt och vår produktutgåva försenades på grund av ett kritiskt fel som vi hittade. Du kanske tror, ​​vad är nytt i det? Det kan hända många gånger. Men detta var väldigt annorlunda eftersom det kritiska fel som vi rapporterade inte var ett resultat av något dokumenterat testfall.

Efter avslutad regressionstestning för sista gången den kvällen spelade jag bara med produkten. Vad betyder det? Du är fri att göra vad du inte ska göra. Baserat på min erfarenhet och projektkunskap hade jag några idéer om hur jag testade produkten förutom vårt typiska testförvar, kallad Exploratory Testing .

Den undersökande testningen som gjordes hittade ett kritiskt fel relaterat till ett serverproblem medan man gjorde något oväntat.

Att vara ett fan av utforskande tester, jag älskar att utforska produkten på olika sätt. För mig är definitionen av programvara:

'Den ska göra vad den ska göra, och den ska inte göra vad den inte ska göra.'

Explorativ testprocess

Att begränsa testgränserna för att kontrollera om produkter som ska fungera gör dig till en ofullständig testare. Faktum är att en testares liv börjar när dokumenterad regressionstest slutar och resultaten uppdateras. Att titta på produkter från olika perspektiv och förstå slutanvändarens krav i olika scenarier gör stor skillnad. Så idag, låt oss förstå tillsammans hur skillnaden kan göras:

Hur ser man på en produkt från olika perspektiv?

utforskande testning

# 1. Förstå kund / slutanvändare

Programvarutestning handlar om att kontrollera produktens kvalitet när det gäller kundnöjdhet. Hur känner du till kundens synvinkel? Svaret är enkelt - du måste vara kund. OK, låt mig göra en korrigering. Att vara kund räcker inte. Du måste förstå hur kunden vill hantera produkten. Inga kunder som köpt samma råvaror kommer att göra samma recept. Ja, produkten vi utvecklar / levererar är en råvara för kundens företag och de har en annan inställning när de använder den.

Som programvarutestare måste vi kontrollera syftet med produkten och inte objektet eller aspekten av den.

Låt mig ge dig några praktiska exempel:

  • Saxen var aldrig begränsad till att bara klippa papper. Klippning är syftet och inte papperet (objektet).
  • Mobiltelefoner var aldrig begränsade till att bara ringa, men 'att kunna ringa' har alltid varit det grundläggande syftet.
  • Förvaringsboxar används för att lagra, men säkerheten för det lagrade materialet är lika viktigt som förvaring.

Att förstå intressenter och ett brett spektrum av deras förväntningar bör ligga till grund för utforskande testning.

# 2. En tänkesätt

När du letar efter (låt oss säga) en jobbannons, ser du den jackpotten och mellan sidorna med fet stil? De flesta av oss gör det inte (tro mig, det är sant). Eftersom vi har instruerat oss att leta efter vad som är användbart eller att kontrolleras. Allt annat är till nytta, så sinnet förnekar oss att känna igen det.

Öppna ditt sinne och ställ inte några förväntningar när du börjar utforska en produkt . Kom alltid ihåg att det inte är OK om produkten gör vad den ska göra. Det är också viktigt att den inte ska göra vad den inte ska göra.

Jag minns ett klassiskt exempel:

I Linux används kommandot 'cat' för att kontrollera innehållet i en fil och kommandot 'ls' är att kontrollera innehållet i katalogen. Arbetade med Linux och var i programvarutestning i fem år, jag tänkte aldrig göra katt eftersom jag var inställd; om jag behövde dir-innehåll måste jag använda 'ls'. Det fungerade, men den motsatta sidan av förväntningen är att produkten inte skulle bete sig som den inte skulle, var fel. En av våra kunder, som inte kände Linux bra, kattade av misstag och systemet kraschade. Vi betalade för detta tänkesätt.

Var alltid redo att göra misstag med programvaran eftersom det är vad slutanvändaren ska göra. För att testa programvaran har du blivit utbildad, men slutanvändaren blir inte lika utbildad som du eller han / hon kommer inte att vara lika mycket av en teknisk expert som du. Han / hon kommer också att göra vad som helst med programvaran när de är i trubbel.

Tänk på dessa scenarier och ge feedback om test. Livet för programvaran och din (som testare) kommer att rocka.

# 3. Känn konkurrenterna

När du testade någon programvara för din klient, försökte du någonsin känna till och förstå annan programvara med samma syfte? Föreslog du någon användbar funktionalitet som du observerade i en konkurrent? Det faller inte in i vår arbetsbeskrivning, är det typiska svaret. Men vet du fördelen med att göra det?

Här är några verkliga exempel som får dig att förstå poängen:

  • Gillar du inte designern som inte bara syr din klänning utan också ger dig information om matchande tillbehör mest?
  • Gillar du inte pizzamärket som inte bara gör fantastiska pizzor utan levererar hem mest i tid?
  • Gillar du inte fotografen som inte bara tar bra bilder utan föreslår en annan typ av ramar för fotograferingen?

Alla vill ha något extra för vad de betalar för. Vår analys av konkurrenskraftig programvara kan fungera på samma sätt för oss. Kunden gillar alltid att höra värdefulla förslag - främst jämförande förslag för att göra produkten mer användbar eller marknadsförbar.

skapa ett binärt sökträd i Java

Dessutom gör denna typ av jämförelse och analys av samma produktsortiment vår analys mer kraftfull och så småningom skapar vi en skatt som vi kan gå tillbaka när som helst och hitta något användbart.

Slutsats

Exploratory kommer inte under ett konventionellt sätt att testa men det är ändå ett mycket kraftfullt sätt att testa.

Det tar fram testerna från en testare och uppmuntrar dem att komma med praktiska och realtidsprovfall för att hitta en defekt. Dess freestyle-natur ger den en fördel jämfört med andra testtyper och kan utföras var som helst, vare sig det är ett projekt med Agile eller vattenfall eller något annat projekt som kräver minimal dokumentation.

Framgången med utforskande testning beror på många immateriella saker som en testares skicklighet, förmågan att skapa effektiva testfall, deras erfarenhet och skickligheten att följa tarmkänslan.

Det är absolut nödvändigt att komma ihåg att ET är en adaptiv process snarare än en förutsägbar process och det är viktigt att upprätthålla en sund balans mellan utforskande och skriptad eller regelbunden testning.

Är du en testare som har typiska utforskande testupplevelser? Vi väntar på att höra dina tankar. Dela dem gärna i kommentarfältet nedan.

Nästa handledning # 2: Hur man använder rundturer för att säkerställa fullständig utforskande testning

Rekommenderad läsning

^