Menu

Wat is verkennend testen bij softwaretests (een complete gids)

  • Hoofd
  • Andere
  • Wat is verkennend testen bij softwaretests (een complete gids)

what is exploratory testing software testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is verkennend testen?

'Exploratory testing' - zoals de naam al doet vermoeden, is een proces van gelijktijdig leren, testontwerp en testuitvoering. We kunnen zeggen dat bij deze test testplanning, analyse, ontwerp en testuitvoering allemaal samen en direct gebeuren.

Dit testen gaat over het verkennen van het systeem en het stimuleren van real-time en praktisch denken van een tester.

In deze serie hebben we de volgende tutorials behandeld​

Tutorial # 1: Wat is verkennend testen bij softwaretests (Deze tutorial)
Tutorial # 2: Rondleidingen gebruiken om volledige verkennende tests te garanderen
Tutorial # 3: Verkennende tests versus scripttests
Tutorial # 4: Verkennend testen met HP Sprinter
Tutorial # 5: Top 17 hulpmiddelen voor verkennende tests

​
Exploratory Testing

Wat je leert:

Overzicht

In termen van de leek, omvat verkennende tests het gelijktijdig ontwerpen van testcases en de testuitvoering van een applicatie of systeem dat wordt getest. De tester zal een testidee bedenken of opschrijven om richting te geven, en al testend het systeem verkennen om kritische, praktische en bruikbare tests te maken voor het succesvol testen van een applicatie.

Dit vereist een minimale planning. Testers nemen continu een beslissing over haar volgende stap. Het hangt volledig af van het denkproces van de tester.

Soms kan dit testen voordeliger zijn dan de formele testaanpak het vinden van enkele subtiele defecten die bij formele tests ontbreken.

Bewust of onbewust zou elke tester op een bepaald moment in zijn carrière verkennende tests hebben gedaan.

Zoals we allemaal weten, zal een leerling beter leren door praktische ervaring in plaats van de theorie te proppen.

Op dezelfde manier zal een tester de applicatie alleen beter kennen terwijl hij alle functionaliteit die hij zelf biedt, verkent en leert kennen. Het is altijd goed om tijdens het testen een klant- en zakelijk perspectief te hebben om een ​​succesvolle test van een applicatie te garanderen.

Bijvoorbeeld​ Als u een winkelwebsite opent, heeft u een algemeen idee dat u op deze winkelwebsite kunt winkelen door een product van uw keuze te selecteren en vervolgens voor hetzelfde te betalen.

Tijdens dit proces zou u kunnen ontdekken dat de website u een virtuele menselijke look-alike biedt die u helpt bij het productselectieproces. Je hebt ook ontdekt dat je een aantal producten kunt bestellen om thuis uit te proberen of dat je kunt betalen via spaarpunten van sommige banken, enz.

Als tester moet u niet alleen controleren of een systeem werkt zoals verwacht, maar ook of dat systeem zich niet gedraagt ​​op een manier die niet wordt verwacht.

Enkele dingen om te onthouden tijdens het uitvoeren van deze test:

  • Uw missie moet duidelijk zijn.
  • Zorg ervoor dat u notities maakt en rapporteert over wat u doet en hoe een systeem zich gedraagt, wat een mogelijke bug kan zijn.
  • Leer, observeer en bedenk vervolgens nieuwe testcases.

Aanbevolen dienst voor verkennende tests

# 1) Digivante Direct

Digivante Direct-logo

Digivante Direct voert verkennende tests uit met behulp van zijn wereldwijde netwerk van professionele testers, zodat u tests op alle belangrijke apparaten kunt uitvoeren in een tijdschaal die niet haalbaar is voor een andere testleverancier of een intern team.

Laat sneller en veiliger vrij, en laat uw digitale platforms een hogere klanttevredenheid en hogere online inkomsten opleveren.

Kenmerken:

  • 24 werkdagen testen in slechts 24 uur of 90 werkdagen in 72 uur, en een ongeëvenaard, uitgebreid testniveau dat op geen enkele andere manier kan worden bereikt.
  • Goedkoop , eenvoudig te begrijpen prijspakketten zonder verborgen extra's.
  • Zelfbediening online portaal dat geen voortdurende inzet vereist.
  • Echte mensen testen op echte apparaten - een veel grotere apparaat- en browserdekking dan u intern kunt bereiken en dat alles binnen een snellere doorlooptijd.
  • Volledige dekking van verkennende tests - het risico verminderen en de tevredenheid van de eindgebruiker en de conversieratio's verbeteren, waardoor de inkomsten worden verhoogd en de kosten worden verlaagd.
​ Bezoek de Digivante Direct-website

Voorbeelden van verkennende tests

Voorbeeld 1:

Een website van een thuiszorgverlener met de volgende componenten:

  • Log in
  • Diensten
  • Winkelwagen
  • Betaling
  • Bestelgeschiedenis
  • Toewijzing van technici

Een algemeen idee om te beginnen verkennend testen zal zijn om in te loggen of een dienst te boeken.

Hoe testcases dekken?

Verkennende testcases

qa het testen van interviewvragen voor ervaren

In bovenstaande Voorbeeld, het idee is om te beginnen met functionaliteit op basis van uw kennis. Naarmate u meer over de toepassing leert en observeert, kunt u uw volgende reeks testcases beheren.

Voorbeeld 2:

Ik was ooit opgenomen in een klein project waarbij een nieuw beleggingsfonds in de aanvraag werd toegevoegd. Mijn taak was om de applicatie te testen om er zeker van te zijn dat het nieuwe beleggingsfonds beschikbaar is voor gebruikers om te kopen en om te controleren of de bijbehorende waardering correct is. Ik had maar 2 dagen om mijn testen te voltooien.

Gezien de strakke deadline en de strengheid van testen, heb ik de verkennende benadering van testen gebruikt. Mijn doel was om nieuwe functies te testen en schendingen van compatibiliteitsvereisten op te sporen.

Bovenstaand doel werd mijn charter voor deze testsessie.

Tijdens deze test zijn de volgende testcases ontwikkeld:

  • Testen om er zeker van te zijn dat het nieuwe beleggingsfonds is toegevoegd aan de aanvraag.
  • Nieuwe MF is met succes gekocht.
  • Waardering van nieuwe MF is correct.
  • Probeerde een nieuwe MF te kopen voor een bestaande portefeuille.
  • Kan een nieuwe MF aan alle portfolio's worden toegevoegd?
  • Impact van nieuwe MF op een waardering van bestaande.
  • Dus in andere testgevallen werden geëvolueerd.

Ik heb tijdens mijn testen aantekeningen en rapporten opgesteld om mijn observatie met de BA en de betrokken cliënt te bespreken.

De fundamentele strategie van verkennend testen is om een ​​aanvalsplan te hebben. Begin met testen met uw idee en improviseer nieuwe testcases op basis van uw kennis en observatie.

Voorbeeld # 3:

Verkennende testen van IRCTC-website

​ Klik hier om de voorbeeldtestgevallen van Exploratory Testing van de IRCTC-website te downloaden.

Testbenadering

  • Maak gebruik van heuristieken om het testen te begeleiden.
  • Het uitvoeren van testcases en het maken van testcases gaan hand in hand.
  • Testcases blijven evolueren op basis van observatie en leren van testers.
  • Verschillende testtechnieken zoals Grenswaardeanalyse , gelijkwaardigheidstesten, enz. kunnen op ET worden toegepast.
  • Op sessie gebaseerde ET kan worden gebruikt om het meer gestructureerd en gericht te maken.
  • Testers kunnen hun ideeën vertakken, maar wijken nooit af van uw missie.
  • ET-tests gebruiken geen scripts, maar zijn afhankelijk van de intuïtie, vaardigheid en ervaring van de tester.

Voordelen

Voordelen van deze tests zijn onder meer:

  • Bevorder real-time denken en helpt bij het ontdekken van meer gebreken.
  • Bevorder gebruiksscenario's en op scenario's gebaseerde tests.
  • Minimale documentatie, maximale testen.
  • De nadruk ligt meer op leren en het verbreden van de horizon van een tester.
  • Voorkom dubbel werk.
  • Handig als u het werk van een andere tester wilt controleren.

Minpunten

De strafpunten worden hieronder vermeld:

  • Testen is afhankelijk van de ervaring, vaardigheid en kennis van de tester.
  • Tijd nodig hebben om de applicatie te leren kennen. De tester zal eerder missen als ze minder weten over de applicatie.
  • Niet geschikt voor projecten met een lange uitvoeringstijd.

Op sessie gebaseerde verkennende tests

Tijdens verkennende tests is het erg moeilijk voor testers om onder woorden te brengen hoeveel hij heeft getest en op welke basis.

Kortom, het is moeilijk om het werk en de bestede tijd te kwantificeren. Bij elk project moeten we echter metrische gegevens, schattingen en voortgangsrapporten verstrekken aan teamleiders en de managers. Zoals het gezegde luidt: 'als je het niet kunt kwantificeren, kun je het niet beheren'.

Sessie-gebaseerd testen is een tijdgebaseerde benadering om deze test uit te voeren, wat helpt bij het beheren en volgen. Het omvat een speciale testsessie met tijdsbestek zonder onderbreking door e-mail, telefoon, berichten enz.

Nadering:

Testtaken zijn onderverdeeld in sessies.

Hieronder volgen de componenten van sessie-gebaseerd testen (SBT):

  • Missie: Missie roept het doel van de sessie op en geeft op een bepaalde manier de focus voor de tester. Het bevat ook de duur van de sessietijd.
  • Handvest: Omvat de reikwijdte van het testen. Kortom, een agenda met de doelen die tijdens de sessie moeten worden voltooid.

Voorbeeld van testhandvest voor inlogfunctionaliteit van de website van thuiszorg:

Voorbeeld van testcharter voor inlogfunctionaliteit

  • Sessie: Vooraf gedefinieerde testsessie met tijdvak zonder enige onderbreking. Elke sessie kan de volgende duur hebben:
    • 'Kort' (60 min)
    • 'Normaal' (90 min)
    • 'Lang' (120 min)
  • Sessieverslag: Voeg notities en een lichtgewicht rapport toe om metrische gegevens aan de leiders en managers te verstrekken. Het geeft details over de resterende of voltooide chartersessie, de insteltijd van de sessie, het geteste scenario, het testproces, een lijst met bugs en de gevonden problemen en andere informatie voor de statistieken.
  • Sessie-overzicht: Een korte vergadering of stand-up tussen de tester en de testleider / manager om de bevindingen van de testsessie te bekijken.

Managers kunnen hands-on de volgende statistieken krijgen op basis van het sessierapport:

  • Het aantal voltooide en resterende sessies.
  • Het aantal gerapporteerde bugs.
  • Tijd besteed aan het opzetten van een sessie.
  • Tijd besteed aan testen.
  • Tijd besteed aan het analyseren van problemen of problemen.
  • Functies gedekt.

Om het bovenstaande samen te vatten:

SBT maakt verantwoording mogelijk bij verkennende testen en biedt een beter beheer van de tijd die aan testen wordt besteed. Het verhoogt ook de productiviteit en biedt een beter begrip van bugdetectie. Het is een geweldige manier om teamleiders en managers te voorzien van meetgegevens om de voortgang van het project te controleren.

Op paar gebaseerde verkennende tests

Pair Testing is een benadering waarbij twee mensen hetzelfde ding / functie van de applicatie tegelijkertijd testen door een pc te delen. Ze delen continu hun gedachten en ideeën. Tijdens deze test neemt de ene persoon de leiding over het toetsenbord, terwijl de andere testcases suggereert en noteert.

Het is altijd handig om een ​​goede communicatie tussen de partners te hebben, zodat beiden weten wat er wordt gedaan en waarom. Een paar waarin de sterkte van de testers hun zwakte wederzijds aanvult, wordt als een sterke groep beschouwd.

Een dergelijke koppeling komt zowel de partijen ten goede en elk kan iets van hun partner leren. Het is ook een goede manier om nieuwe bronnen te trainen door ze te combineren met ervaren bronnen.

Voordelen van pair-testen

  • Helpt een tester zich te concentreren op de taak die voorhanden is.
  • Moedig wederzijds vertrouwen en respect tussen partners aan.
  • Brainstormen tussen gepaarde testers leidt meestal tot meer constructieve ideeën.
  • Vermijd tunnelvisie.
  • Er is een kleinere kans dat anderen hen storen.

Verkennende testtechnieken

Tours: Het is een eenvoudige techniek waarmee een tester zijn fantasie kan gebruiken en zichzelf kan zien als een toerist die een stad verkent die hij bezoekt. Hier is een applicatie om te testen de stad en de testers zijn de toeristen. Het is erg moeilijk om de hele stad te verkennen, tenzij je veel tijd en geld in je hand hebt, dus een toerist moet een plan hebben met een bepaald doel voor ogen.

Een toerist kan de volgende tours maken:

  • Reisgids - Testen van gemarkeerde functie van de applicatie. Gebruik op gebruikers gebaseerde scenario's.
  • Ontdek de geschiedenis van de stad - Test oude functies van een applicatie.
  • Geld tour, wat betekent dat u ervoor moet zorgen dat alle kritieke functies met betrekking tot de klant of klant worden getest en met succes werken.
  • Crime spree tour - Voer ongeldige invoer in en test negatieve scenario's.
  • Tour door een steegje - Test de minst gebruikte functies van de applicatie.
  • Saaie tour - Besteed minimale tijd aan elk scherm van de applicatie, vul minimale velden in en neem de kortste weg. Dit zal helpen bij de standaardwaarde en validatietests.

Tijdens een tocht heb je altijd de keuze om eender welke route te nemen. U kunt door software navigeren en een uniek pad vinden om de functie te testen.

Hieronder staan ​​enkele tips / trucs die u in ET kunt gebruiken:

  • Verdeel de applicatie in modules en splitst de modules op in verschillende pagina's. Start uw ET vanaf de pagina's. Dit geeft de juiste dekking.
  • Maak een checklist van alle features en zet een vinkje als dat gedekt is.
  • Begin met een basisscenario en verbeter het geleidelijk om meer functies toe te voegen om het te testen.
  • Test alle invoervelden.
  • Test voor het foutbericht
  • Test alle negatieve scenario's.
  • Controleer de GUI met de standaarden.
  • Controleer de integratie van de applicatie met andere externe applicaties.
  • Controleer op complexe bedrijfslogica.
  • Probeer de applicatie ethisch te hacken.

Factoren die ET beïnvloeden zijn de volgende:

  • Het doel van het project
  • Teststrategie
  • Het testdoel van een bepaalde fase
  • Beschikbare tools en faciliteiten
  • Testers rol en vaardigheden
  • Beschikbare tijd
  • Management ondersteuning
  • Peer-ondersteuning
  • Beschikbare bronnen (studiemateriaal, testomstandigheden enz.)
  • Klanten interesseren
  • Begrijpelijkheid van het product.
  • De gebruikersinterface van de applicatie
  • De functionaliteit van de applicatie
  • Eerdere testresultaten
  • Risico's verbonden aan de applicatie
  • Eerdere gebreken
  • Recente veranderingen
  • Typen gegevens om te gebruiken voor testen
  • Type gebruiker dat het gaat gebruiken

In plaats van de testers te vragen wat ze moeten uitvoeren, laten we het aan de tester over om te beslissen wat ze willen testen en hoe ze willen testen.

Verschil tussen verkennend testen en ad-hoc testen

Verwar ET niet met Ad-hoc-test ​

  • Ad-hoc testen verwijst naar een proces van niet-gescript, ongepland en geïmproviseerd zoeken naar defecten, terwijl verkennend testen een doordachte methodologie is voor ad-hoc testen.
  • Ad-hoc testen is een hit and trial-methode om een ​​bug te vinden, terwijl ET dat niet is. In ET-benadering leert een tester over het systeem terwijl ze de tests verkennen en uiteindelijk ontwikkelen met behulp van de verworven kennis.
  • Ad-hoc testen is een ongestructureerde activiteit, terwijl ET een enigszins gestructureerde activiteit is.

Exploratory Automated Testing (EAT)

Exploratory Automated Testing is een methode die een tester helpt bij het stroomlijnen van bugrapportage en reproductie, het verzamelen van momentopnamen en bij het voorbereiden van toekomstige regressiepakketten. Het is een proces dat automatiseringstests combineert met verkennende tests.

Er zijn twee soorten EAT-benadering:

  • Passief EAT
  • Actief EAT

Passief EAT

Passieve EAT kan worden uitgevoerd door een enkele tester of ook in een paar. In deze methodologie is meestal een tool die elke afzonderlijke activiteit van een testbron (nen) vastlegt en registreert, en die op de pc van de bron wordt geïnstalleerd.

Passieve EAT is vergelijkbaar met de ET die handmatig wordt uitgevoerd, omdat er geen verandering is in de manier waarop de tests worden uitgevoerd, behalve het opstellen van het testresultaat op basis van de vastgelegde sessie. Deze testresultaten kunnen worden gebruikt voor het rapporteren en naspelen van geregistreerde acties later in de tijd.

De geïnstalleerde videotool helpt een tester bij het opnemen van testgevallen en het rapporteren van defecten.

Het heeft ook enkele andere voordelen, zoals:

  • Biedt duidelijke stappen om de bugs te reproduceren.
  • Het reproduceren van defecten is gemakkelijker, zelfs als de defectmelder niet beschikbaar is.
  • Weg met de conflicten tussen het test- en ontwikkelingsteam wanneer een periodieke bug wordt gerapporteerd.
  • Helpt bij prestatietests door de reactietijd van het systeem op het specifieke punt in de tijd te krijgen.

Hier zijn enkele andere punten waarmee u rekening moet houden vóór Passive EAT:

  • Het wordt aanbevolen om een ​​piloottest uit te voeren alvorens de tool volledig aan te passen voor Automated EAT. Dit is om ervoor te zorgen dat de tijd die nodig is voor het opnieuw ontwerpen van de testlogboeken die tijdens de testsessie zijn gemaakt, niet meer is dan het uitvoeren van tests. Als dat het geval is, moet het team een ​​gezamenlijk besluit nemen over het volgende:
    • Als er al testautomatisering nodig is voor het specifieke project.
    • Als de gebruikte tool moet worden gewijzigd.
    • Als de prestaties van de gebruikte tool kunnen worden geoptimaliseerd.
  • De tool die wordt gebruikt voor het uitvoeren van geautomatiseerde EAT moet worden geïnstalleerd op elke testbron die bij het testen is betrokken. Het is ook een goed idee om de ontwikkelaars te betrekken, wat kan worden bereikt door de ontwikkelaars VPN- of externe toegang tot testmachines te geven of door de tool in de ontwikkelomgeving te installeren.
  • Het is altijd een goed idee om het GUI-object van de applicatie in de testtool te organiseren, zodat wanneer het tijd is om de bug of een probleem te analyseren, het object herkenbaar is aan een betekenisvolle naam.
  • Het is een goede gewoonte om een ​​betekenisvolle naam te geven aan het GUI-object dat in AUT wordt gebruikt, en ze te ordenen voor later gebruik.

Laten we nu naar de tweede benadering gaan.

Actief EAT

Het is raadzaam om Active EAT uit te voeren met paartest. Bij deze benadering wordt het trefwoordgestuurde testen gebruikt in combinatie met het testen van sessies. De ene tester maakt het geautomatiseerde testscript en de tweede tester voert de testscripts uit die door de eerste tester zijn gemaakt.

Het maken van automatiseringstestscripts in deze benadering volgt een andere weg dan bij conventioneel testen. Tijdens het testen worden geautomatiseerde testscripts gemaakt en wat in de vorige tests is ontdekt, bepaalt hun ontwerp.

Aan het einde van de testsessie wordt een afsluitingsfase uitgevoerd. En het zou de volgende taken moeten hebben:

  • De betrokken testers moeten van rol wisselen, zodat de testbron die het testscript heeft gemaakt, de kans krijgt om de scripts opnieuw uit te voeren om de betrouwbaarheid en robuustheid van de gemaakte suite te bevestigen.
  • Voor elk geautomatiseerd testscript moet een korte beschrijving en enkele identificerende kenmerken worden gegeven.
  • Er moet een criterium worden gedefinieerd om te bepalen welke geautomatiseerde testscripts kunnen worden gebruikt voor regressietests.

Voordelen van EAT

  • Aan het begin van elke sessie worden reeds gemaakte geautomatiseerde testscripts uitgevoerd, waardoor de testdekking telkens wordt verbeterd.
  • Betere bugrapportage en documentatie voor reproductie van defecten.
  • EAT biedt voldoende bewijs en documentatie voor een stakeholder om de voortgang te zien.

Soorten verkennende tests

Hieronder staan ​​een paar soorten ET:

1) Freestyle EN:

Verkenning van de toepassing in ad-hocstijl.

Bij dit type ET zijn er geen regels, geen rekening met dekking, enz. Dit type testen is echter goed wanneer u snel vertrouwd moet raken met de toepassing, wanneer u het werk van de andere testers wilt verifiëren en wanneer u een defect wilt onderzoeken of een snelle rooktest wilt doen.

2) Scenario-gebaseerde ET:

Zoals de naam al doet vermoeden, is het uitgevoerde testen op scenario's gebaseerd. Het begint met scenario's van echte gebruikers, end-to-end-scenario's of testscenario's. Na de eerste tests kunnen testers variatie injecteren op basis van hun leren en observatie.

Scenario's zijn als een algemene gids voor wat u tijdens ET moet doen. Testers worden aangemoedigd om tijdens het uitvoeren van een scenario meerdere mogelijke paden te verkennen om ervoor te zorgen dat alle mogelijke paden naar functie werken. Testers moeten er ook voor zorgen dat ze zoveel mogelijk scenario's uit verschillende categorieën verzamelen.

3) Strategiegebaseerd ET:

Bekende testtechnieken zoals grenswaardeanalyse, equivalentietechniek en risicogebaseerde techniek die worden gecombineerd met verkennend testen. Voor dit type testen wordt een ervaren tester of een tester aangesteld die bekend is met de applicatie.

Agile verkennende tests

Zelfs als je niet in een agile omgeving hebt gewerkt, weet ik zeker dat je het gelezen of gehoord moet hebben vanwege de groeiende populariteit. Agile-methodologie heeft korte sprints en strakke deadlines die een team een ​​paar weken de tijd geven om de planning, schatting, ontwikkeling, codering, testen en vrijgeven te voltooien.

Exploratory testing wordt handig in zulke krappe deadlines omdat bij deze testaanpak de nadruk ligt op het snelle en bruikbare resultaat. Zodra u de vereiste heeft begrepen, kunt u beginnen met testen op basis van uw ervaring en kennis.

Als u eenmaal vertrouwd bent met de toepassingsfuncties en het gedrag, kunt u meer testcases ontwerpen om de toepassingsfunctionaliteit te valideren en ongeplande bugs te detecteren. Omdat het een freestyle-testaanpak is, moet u alles documenteren. U moet echter notities en een kort rapport bijhouden over wat u hebt getest, bugs en gevonden problemen enz.

Verdiensten van verkennend in Agile

  • Zo snel mogelijk feedback geven aan de ontwikkelaars.
  • Er wordt een grotere verscheidenheid aan defecten ontdekt.
  • Een diverse groep van een bron, zoals een ontwikkelaar, tester, BA, ontwerpers, kan ET uitvoeren, aangezien er geen scripttestcases zijn en elk een ander perspectief biedt.
  • Scouting gedaan in ET helpt bij het verkennen van nieuwe gebieden en het blootleggen van kritieke bugs.
  • In het geval van iteratieve codering van een applicatie, kan ET zich concentreren op het testen van nieuwe functies, terwijl automatisering regressie- en achterwaartse compatibiliteitstests uitvoert.
  • In het geval van een onstabiele vereiste, kan ET helpen bij het testen van nieuwe vereisten binnen een beperkte tijd.

Punten om te onthouden:

1. Vereist verschillende vaardigheden: De testers die ET uitvoeren, moeten goede luister-, lees-, denk- en rapportagevaardigheden hebben. Domeinervaring is vereist omdat er geen scripts en testcases zijn.

2. Soms is het moeilijk rapporteer een bug: In een ET-stroom kunnen we een defect tegenkomen, maar we kunnen het misschien niet reproduceren. Dit komt doordat we de teststappen niet volgen en we wellicht de exacte stappen vergeten om dat probleem te reproduceren.

3. Kan worden gedaan als recreatieactiviteit: Persoonlijk doe ik ET als ik een pauze wil in mijn normale testuitvoeringcyclus. Maar veel teams hebben ET als een aparte fase van hun testcyclus.

4. Het kan voor alle testfasen worden gedaan: We kunnen ET implementeren vóór het begin van een testfase. U kunt ET al vóór de functionele testfase uitvoeren.

5. Snelle feedback: ET vereist snelle feedback over de problemen en eventuele anomalieën.

6. Kritisch denken en diverse ideeën: Dit testen vereist kritisch denken. Testers moeten hun ideeën op een logische manier kunnen reproduceren, herzien en uitdrukken. Een tester kan haar ervaring implementeren in de verschillende technologieën en domeinen waaraan ze hebben gewerkt.

Hoe u verder kunt denken dan traditionele testgrenzen bij verkennende tests

“Ik stel uw bezorgdheid over het product zeer op prijs en maak ons ​​behulpzaam bij het begrijpen van de eindgebruiker. Het zal erg nuttig zijn. Bedankt voor het goede werk en ga zo door !!! '

Dit was de laatste e-mail van een e-mailketen met 21 e-mails van onze klant. Het was middernacht en onze productrelease is vertraagd vanwege een kritieke bug die we hebben gevonden. Je zou kunnen denken, wat is daar nieuw in? Het kan vaak gebeuren. Maar dit was echt anders, omdat de kritieke bug die we rapporteerden niet het resultaat was van een gedocumenteerd testgeval.

Na het afmaken regressietesten voor het laatst die avond speelde ik gewoon met het product. Wat betekent dat? U bent vrij om te doen wat u niet mag doen. Op basis van mijn ervaring en projectkennis had ik een aantal ideeën om het product te testen, los van onze typische testrepository, gebeld Exploratory Testing ​

De uitgevoerde verkennende tests hebben een kritieke bug gevonden die verband houdt met een probleem met het vastlopen van de server terwijl er iets onverwachts werd gedaan.

Als fan van verkennende testen vind ik het heerlijk om het product op verschillende manieren te ontdekken. Voor mij is de definitie van software:

'Het moet doen wat het moet doen, en het moet niet doen wat het niet moet doen.'

Verkennend testproces

geavanceerde sql interviewvragen en antwoorden pdf

Het beperken van testgrenzen om te controleren of producten die zouden moeten werken, werken, maakt van jou een onvolledige tester. In feite begint het leven van een tester wanneer gedocumenteerde regressietests eindigen en de resultaten worden bijgewerkt. Producten vanuit verschillende perspectieven bekijken en de eisen van eindgebruikers in verschillende scenario's begrijpen, maken een groot verschil. Laten we vandaag dus samen kijken hoe dat verschil kan worden gemaakt:

Hoe bekijk je een product vanuit verschillende perspectieven?

verkennende toetsing

# 1. Begrijp klant / eindgebruiker

Bij het testen van software draait het allemaal om het controleren van de kwaliteit van het product in termen van klanttevredenheid. Hoe kent u het standpunt van een klant? Het antwoord is simpel: u moet de klant zijn. Oké, laat me iets corrigeren. Klant zijn is niet genoeg. U moet begrijpen hoe de klant met het product wil omgaan. Geen twee klanten die dezelfde grondstoffen hebben gekocht, zullen hetzelfde recept bereiden. Ja, het product dat we ontwikkelen / leveren is een grondstof voor de bedrijven van de klant en ze hebben een andere mentaliteit bij het gebruik ervan.

Als softwaretester moeten we het doel van het product controleren en niet het object of aspect ervan.

Ik zal u enkele praktische voorbeelden uit de praktijk geven:

  • Scharen waren nooit beperkt tot alleen papier knippen. Snijden is het doel en niet het papier (object).
  • Mobiele telefoons waren nooit beperkt tot alleen bellen, maar 'kunnen bellen' is altijd het basisdoel geweest.
  • Opbergdozen worden gebruikt om op te slaan, maar de veiligheid van het opgeslagen materiaal is net zo belangrijk als opslag.

Het begrijpen van belanghebbenden en een breed scala van hun verwachtingen zou de basis moeten zijn van verkennende tests.

# 2. Een mentaliteit

Zie je bij het zoeken naar (laten we zeggen) een vacature-advertentie die jackpot en tussen de pagina's met het vetgedrukte lettertype? De meesten van ons niet (geloof me, het is waar). Omdat we onze geest hebben opgedragen om te zoeken naar wat nuttig is of om gecontroleerd te worden. Al het andere heeft geen zin, dus de geest ontzegt ons het te herkennen.

Open je geest en stel geen verwachtingen wanneer je een product gaat verkennen ​Onthoud altijd dat het niet OK is als het product doet wat het moet doen. Het is ook belangrijk dat het niet doet wat het niet hoort te doen.

Ik herinner me een klassiek voorbeeld:

In Linux wordt het ‘cat’ commando gebruikt om de inhoud van een bestand te controleren en het ‘ls’ commando is om de inhoud van de directory te controleren. Omdat ik met Linux werkte en vijf jaar bezig was met het testen van software, had ik nooit gedacht om cat te doen, omdat ik vastbesloten was; als ik dir-inhoud nodig heb, moet ik ‘ls’ gebruiken. Dat werkte, maar de keerzijde van de verwachting is dat het product zich niet mocht gedragen zoals het niet bedoeld was, verkeerd was. Een van onze klanten, die Linux niet goed kende, deed per ongeluk een kat en het systeem crashte. We hebben voor deze mentaliteit betaald.

Wees altijd bereid om fouten te maken met de software, want dat is wat de eindgebruiker gaat doen. Om de software te testen, ben je getraind, maar de eindgebruiker zal niet zo getraind zijn als jij of hij / zij zal niet zo'n technisch expert zijn als jij. Ook zal hij / zij alles met de software doen als ze in de problemen zitten.

Denk na over die scenario's en geef testfeedback. Het leven van de software en die van jou (als tester) zal rocken.

# 3. Ken de concurrenten

Heeft u tijdens het testen van een softwareapplicatie voor uw klant ooit geprobeerd om andere software met hetzelfde doel te kennen en te begrijpen? Heeft u ooit een aantal nuttige functies voorgesteld die u in het product van een concurrent heeft waargenomen? Het valt niet in onze functieomschrijving, is het typische antwoord. Maar kent u het voordeel ervan?

Hier zijn enkele praktijkvoorbeelden om u het punt te laten begrijpen:

  • Vind je de ontwerper niet leuk die niet alleen je jurk naait, maar je ook input geeft over bijpassende accessoires?
  • Vind je het pizzamerk niet leuk dat niet alleen geweldige pizza's maakt, maar het meest op tijd thuis bezorgt?
  • Vind je de fotograaf niet leuk die niet alleen goede foto's maakt, maar ook een ander soort kaders voor de fotoshoot suggereert?

Iedereen wil iets extra's hebben voor waar ze voor betalen. Onze analyse van concurrerende software kan voor ons op dezelfde manier werken. De klant hoort altijd graag waardevolle suggesties - voornamelijk vergelijkende suggesties om het product nuttiger of verkoopbaarder te maken.

Ook maakt dit soort vergelijking en analyse van dezelfde reeks producten onze analyse krachtiger en uiteindelijk creëren we een schat waar we op elk moment naar terug kunnen gaan en iets nuttigs kunnen vinden.

Gevolgtrekking

Exploratory valt niet onder een conventionele manier van testen, maar toch is het een zeer krachtige manier van testen.

Het haalt het out-of-box-denken van een tester naar voren en moedigt hen aan om praktische en real-time testcases te bedenken om een ​​defect op te sporen. Het freestyle karakter geeft het een voorsprong op de andere testtypen en kan overal worden uitgevoerd, of het nu een project is met Agile of waterval of elk ander project dat minimale documentatie vereist.

Het succes van verkennend testen hangt af van tal van immateriële zaken, zoals de vaardigheid van een tester, het vermogen om effectieve testcases te creëren, hun ervaring en de vaardigheid om hun onderbuikgevoel te volgen.

Het is noodzakelijk om te onthouden dat ET een adaptief proces is in plaats van een voorspellend proces, en het is essentieel om een ​​gezond evenwicht te bewaren tussen verkennende en gescripte of reguliere tests.

Ben jij een tester met typische verkennende testervaringen? We wachten op uw mening. Deel ze gerust in de comments hieronder.

Volgende tutorial # 2​ Hoe u rondleidingen kunt gebruiken om volledige verkennende tests te garanderen

Aanbevolen literatuur

^