Menu

Ad-hoc testen: hoe u defecten kunt vinden zonder een formeel testproces

ad hoc testing how find defects without formal testing process

Probeer Ons Instrument Voor Het Oplossen Van Problemen

De term ad-hoc duidt op het gebrek aan structuur of iets dat niet methodisch is. Als je erover praat ad-hoc testen , het betekent dat het een vorm is van een zwarte doos of gedragstesten die worden uitgevoerd zonder een formeel proces.

Het formele proces hier betekent dat u beschikt over documentatie zoals vereiste documenten, testplannen, testgevallen en een goede testplanning in termen van het schema en de volgorde van uitgevoerde tests. Ook worden acties die tijdens het testen worden uitgevoerd, doorgaans niet gedocumenteerd.

Ad-hoc testen

Dit wordt voornamelijk gedaan met het doel defecten of gebreken te ontdekken die niet kunnen worden opgevangen via traditionele of formele processen die tijdens de testcyclus worden gevolgd.

Zoals reeds begrepen, ligt de essentie van dit testen in het ontbreken van een formele of gestructureerde manier van testen. Wanneer dergelijke willekeurige testtechnieken worden uitgevoerd, is het duidelijk dat de testers doen dit zonder enige specifieke use case in gedachten met als doel het systeem te kraken.

Daarom is het zeker nog duidelijker dat een dergelijke intuïtieve of creatieve testmethode vereist de tester moet buitengewoon bekwaam en bekwaam zijn en een grondige kennis van het systeem hebben. Ad-hoc testen zorgen ervoor dat de uitgevoerde testen compleet zijn en zijn vooral erg handig bij het bepalen van de effectiviteit van de testemmer.

Aanbevolen lectuur​ Exploratory Testing - Hoe denk je verder dan traditionele testgrenzen?

Wat je leert:

Laten we beginnen met een ad-hoc testvoorbeeld

Hier is een voorbeeld van hoe we deze test kunnen uitvoeren als het gaat om UI Wizard.

Stel dat u een plan of sjabloon moet maken om een ​​bepaalde taak uit te voeren met deze UI-wizard. De wizard is een reeks deelvensters met gebruikersinvoer zoals naam, beschrijving, enz.

Naarmate de wizard vordert: stel dat in een van de panelen gebruikersgegevens moeten worden ingevoerd, waarbij de UI-wizard een contextpop-upvenster opent dat de bijbehorende gegevens toevoegt om de wizard te voltooien en de wizard te implementeren / activeren.

Om deze tester te testen doet hij zijn reguliere testen zoals:

Qtp interviewvragen en antwoorden voor 4 jaar ervaring
  • Voltooi de wizard met succes met alle geldige gegevens en maak het plan.
  • Annuleer de wizard halverwege.
  • Bewerk een gemaakt plan met de wizard.
  • Verwijder het gemaakte plan en zorg ervoor dat er geen residu van is.
  • Voer een negatieve waarde in de wizard in en kijk of de juiste foutmeldingen worden weergegeven.

Nu, voor het bovenstaande voorbeeld hier zijn enkele testcases voor ad-hoc tests dat zou kunnen worden uitgevoerd om zoveel mogelijk defecten te ontdekken:

  • Terwijl u probeert om negatieve gegevens toe te voegen, voegt u bepaalde speciale tekens toe die niet beperkt zijn om te zien of ze correct worden verwerkt. Bijvoorbeeld, soms beperken wizards {of (accolades niet, maar in bepaalde situaties kan dit conflicteren met code op basis van de taal waarin deze is geschreven, en zeer onbetrouwbaar gedrag veroorzaken.
  • Een andere test is specifiek met betrekking tot pop-ups. Een gebruiker kan ervoor zorgen dat de pop-up wordt gestart en vervolgens proberen op de backspace-knop op het toetsenbord te drukken. Ik heb vaak opgemerkt dat hierdoor de achtergrondwizard volledig verdwijnt en alle gebruikersgegevens die zijn ingevoerd tot het punt waarop de pop-up werd geopend, verloren gaan!

Kenmerken van ad-hoc testen:

Als u de bovenstaande scenario's opmerkt, ziet u iets heel verschillende kenmerken van dit type testen.

Zij zijn:

  • Ze zijn altijd in lijn met het testdoel. Het zijn echter bepaalde ingrijpende tests die worden uitgevoerd met de bedoeling het systeem te breken.
  • De tester moet volledige kennis en bewustzijn hebben van het systeem dat wordt getest. Het resultaat van deze test vindt bugs die proberen de mazen in het testproces aan het licht te brengen.
  • Als we ook naar de bovenstaande twee tests kijken, zou de natuurlijke reactie daarop zijn dat - dit soort test kan slechts één keer worden uitgevoerd, omdat het niet haalbaar is voor een nieuwe test, tenzij er een defect is.

Wanneer voeren we ad-hoctests uit?

Een vraag van een miljoen dollar inderdaad!

De meeste testteams worden altijd belast met te veel functies om binnen een beperkte tijdlijn te testen. In die beperkte tijdspanne zijn er veel testactiviteiten die zijn afgeleid van het formele proces dat ook moet worden voltooid. In dergelijke situaties is het ad-hoc testen om de weg naar het testen te vinden klein.

Echter, uit mijn ervaring kan een ronde van ad-hoc testen wonderen doen voor de productkwaliteit en veel ontwerpvragen oproepen.

Aangezien ad-hoc testen meer een 'wild-child'-testtechniek is die niet gestructureerd hoeft te worden, is de algemene aanbeveling dat deze moet worden uitgevoerd nadat de uitvoering van de huidige testbucket is voltooid. Een ander standpunt is dat dit kan worden gedaan wanneer gedetailleerde tests niet kunnen worden uitgevoerd vanwege minder tijd.

Naar mijn mening zou ik dat zeggen ad-hoc testen kunnen bijna altijd worden gedaan - in het begin, in het midden en tegen het einde! Het vindt gewoon op elk moment zijn plaats. Wanneer echter ad-hoc testen moeten worden uitgevoerd om maximale waarde naar voren te brengen, kan dit het beste worden beoordeeld door een ervaren tester die diepgaande kennis heeft van het systeem dat wordt getest.

Wanneer niet uitvoeren?

Als de vorige vraag een miljoen dollar waard was, zou dit een miljard waard moeten zijn!

Hoewel we hebben vastgesteld hoe effectief en vruchtbaar ad-hoc-testen kunnen zijn, moeten we als bekwame en capabele tester ook ontcijferen wanneer we niet in dit soort testen moeten investeren. Hoewel het ter beoordeling van de tester is, hier zijn enkele aanbevelingen / voorbeelden wanneer het misschien niet nodig is.

  • Vermijd dit testen als er een testcase is waarvoor een defect bestaat. In een dergelijke situatie is het nodig om het faalpunt van de testcase te documenteren en vervolgens het defect te verifiëren / opnieuw te testen wanneer het is verholpen. Daarom is het hier niet van toepassing.
  • Er kunnen ook bepaalde scenario's zijn waarvoor klanten of klanten kunnen worden uitgenodigd test de bètaversie van de software ​In dergelijke gevallen mag deze test niet worden uitgevoerd.
  • Een ander scenario is wanneer er een heel eenvoudig UI-scherm wordt toegevoegd. Traditionele positieve en negatieve testen zouden hier voldoende moeten zijn om maximale defecten naar voren te brengen.

Soorten ad-hoc-tests

Ad-hoc testen kunnen hieronder in drie categorieën worden onderverdeeld:

# 1) Buddy-testen

Bij deze vorm van testen zal er een testlid en een ontwikkelingslid worden gekozen om aan dezelfde module te werken. Net na de ontwikkelaar voltooit het testen van de eenheid , de tester en ontwikkelaar zitten bij elkaar en werk aan de module. Met dit soort testen kan de functie voor beide partijen in een breder bereik worden bekeken.

De ontwikkelaar krijgt een perspectief van alle verschillende tests die de tester uitvoert en de tester krijgt een perspectief van hoe het inherente ontwerp is, wat hem zal helpen om ongeldige scenario's te ontwerpen en zo ongeldige defecten te voorkomen. Het zal de een helpen om te denken zoals de ander.

# 2) Koppeltest

Bij deze test werken twee testers samen aan een module met dezelfde testopstelling die ze delen. Het idee achter deze vorm van testen om de twee testers te laten brainstormen over ideeën en methoden om een ​​aantal defecten te hebben. Beiden kunnen het testwerk delen en de nodige documentatie maken van alle gemaakte observaties.

# 3) Apen testen

Deze testen worden voornamelijk uitgevoerd op het niveau van unit testing. De tester parseert gegevens of tests op een volledig willekeurige manier om ervoor te zorgen dat het systeem bestand is tegen crashes. Deze tests kunnen verder worden ingedeeld in twee categorieën:

sql server scenario gebaseerde interviewvragen

Voordelen van ad-hoc testen

Het testen garandeert de tester met veel kracht om zo creatief te zijn als nodig is.

Dit verhoogt de testkwaliteit en efficiëntie zoals hieronder:

  • Het grootste voordeel dat opvalt, is dat een tester het aantal defecten kan vinden dan bij traditioneel testen vanwege de verschillende innovatieve methoden die ze kunnen toepassen om de software te testen.
  • Deze vorm van testen kan overal in de SDLC worden toegepast; het is niet alleen voorbehouden aan het testteam. De ontwikkelaars kunnen deze tests ook uitvoeren, waardoor ze beter kunnen coderen en ook kunnen voorspellen welke problemen zich kunnen voordoen.
  • Het kan worden gecombineerd met een andere test om de beste resultaten te krijgen, waardoor de tijd die nodig is voor de reguliere tests soms kan worden verkort. Dit zou het mogelijk maken om testcases van betere kwaliteit te genereren en een betere kwaliteit van het product als geheel.
  • Het vereist geen documentatie die moet worden gedaan om de extra belasting van de tester te voorkomen. Een tester kan zich concentreren op het daadwerkelijk begrijpen van de onderliggende architectuur.
  • In gevallen waarin er niet veel tijd beschikbaar is om te testen, kan dit zeer waardevol blijken te zijn in termen van testdekking en kwaliteit.

Nadelen van ad-hoc testen

Ad-hoc testen heeft ook een aantal nadelen. Laten we eens kijken naar enkele van de nadelen die worden uitgesproken:

Omdat het niet erg georganiseerd is en er geen verplichte documentatie is, is het meest voor de hand liggende probleem dat de tester alle details van de ad-hoc-scenario's in het geheugen moet onthouden en onthouden. Dit kan zelfs nog uitdagender zijn, vooral in scenario's waarin er veel interactie is tussen verschillende componenten.

  • Gevolgd vanaf het eerste punt, zou dit er ook toe leiden dat bij de volgende pogingen, indien om informatie wordt gevraagd, geen defecten opnieuw kunnen worden gecreëerd.
  • Een andere zeer belangrijke vraag die hierdoor aan het licht komt, is de verantwoording van de inspanning. Aangezien dit niet gepland / gestructureerd is, is er geen manier om rekening te houden met de tijd en moeite die in dit soort testen is geïnvesteerd.
  • Ad-hoc testen mogen alleen worden uitgevoerd door een zeer goed geïnformeerde en bekwame tester in het team, omdat het proactief en intuïtief moet zijn in termen van het voorzien van mogelijke defecte gebieden.

Praktische tips om deze tests effectiever te maken

We hebben de sterke en zwakke punten van deze tests uitvoerig besproken.

Idealiter zouden ad-hoc-tests hun plaats in de SDLC moeten vinden, maar als ze niet op de juiste manier worden benaderd, kan het duur blijken te zijn en een verspilling van waardevolle testtijd. Hieronder vindt u enkele tips om ad-hoc testen effectief te maken:

# 1) Identificeer defecte gebieden:

Als u het testen van een bepaald stuk software goed onder de knie hebt, gaat u ermee akkoord dat er bepaalde functies zijn die vatbaarder zijn voor fouten dan de andere. Als het systeem nieuw voor je is, ga je gang en controleer je de functies tegen / s-defecten die tegen hen zijn geopend.

Het aantal defecten in een bepaald kenmerk laat zien dat het gevoelig is en dat u precies dat gebied moet kiezen om ad-hoc tests uit te voeren. Dit blijkt een zeer tijdbesparende manier te zijn om enkele ernstige defecten bloot te leggen.

# 2) Expertise opbouwen:

Een tester met meer ervaring is ongetwijfeld intuïtiever en kan raden waar de fouten kunnen zijn, in vergelijking met iemand die niet veel ervaring heeft. Ik zou zeggen, ervaren of niet, het is aan het individu om de sprong te wagen en expertise op te bouwen op het systeem dat wordt getest.

Ja, ervaren testers hebben een voorsprong omdat hun door de jaren opgebouwde vaardigheden van pas komen, maar de nieuwe testers zouden dit moeten gebruiken als een platform om zoveel mogelijk kennis op te doen om betere ad-hoc scenario's te ontwerpen.

# 3) Maak testcategorieën:

Als u eenmaal op de hoogte bent van de lijst met te testen functies, reserveer dan een paar minuten om te beslissen hoe u die functies zou categoriseren en testen. Bijvoorbeeld, u moet besluiten om de functies te testen die het meest zichtbaar zijn en het meest worden gebruikt door de gebruiker, aangezien deze essentieel lijken voor het succes van de software.

Vervolgens zou je ze qua functionaliteit / prioriteit kunnen categoriseren en ze segment voor segment kunnen testen.

Een ander voorbeeld waarbij dit bijzonder belangrijk is, is of er integratie is tussen componenten of modules. In deze gevallen kunnen er veel afwijkingen optreden. Het gebruik van categorisering zou helpen om dit soort test minstens een of twee keer aan te raken.

# 4) Heb een globaal plan:

Ja, ja, dit punt kan u een beetje verwarren, aangezien we ad-hoc testen beschreven als testen waarvoor geen planning of documentatie zou moeten zijn. Het idee hier is om vast te houden aan de essentie van ad-hoc testen, maar toch een paar grove aanwijzingen op te schrijven over hoe u van plan bent te testen.

Een heel eenvoudig voorbeeld is dat u zich soms niet alle tests kunt herinneren die u van plan bent uit te voeren. Dus als u ze opschrijft, weet u zeker dat u niets mist.

# 5) Gereedschap:

Laten we een voorbeeld nemen dat we allemaal vaak tegenkomen. Als u observeert, is het testen van de functionaliteit op zichzelf vaak succesvol zonder dat er een discrepantie wordt gemeld in het gedrag. De logboeken achter de schermen kunnen echter enkele uitzonderingen melden die door de testers kunnen worden gemist, omdat dit het testdoel op geen enkele manier belemmert.

Deze kunnen zelfs erg ernstig zijn. Daarom is het erg belangrijk voor ons om te leren en tools te gebruiken waarmee we dit onmiddellijk kunnen vaststellen.

# 6) Document voor meer defecten:

Nogmaals, ik begrijp dat dit weer wat wenkbrauwen kan doen fronsen. De documentatie hoeft niet gedetailleerd te zijn, maar slechts een kleine notitie voor uw eigen referentie van alle verschillende behandelde scenario's, afwijkingen in de betrokken stappen en registreer die defecten voor de specifieke categorie van testkenmerken.

Dit zal u ook helpen de algehele testemmer te verbeteren, waarbij u kunt beslissen hoe u bestaande testcases kunt improviseren of indien nodig meer kunt toevoegen.

Gevolgtrekking

We hebben uitvoerig gesproken over ad-hoc testtechnieken: de sterke en zwakke punten en situaties waarin deze wel en niet voordelig zouden zijn.

Dit is een testtechniek die ervoor zorgt dat de creativiteit van de tester maximaal wordt benut en bevredigd. In mijn hele testcarrière Haal ik de grootste voldoening uit ad-hoc testen, aangezien er geen limiet is aan innoveren en u uiteindelijk alleen maar meer kennis krijgt.

Dat gezegd hebbende, het belangrijkste om terug te nemen van alle bovenstaande informatie zou zijn om bepalen hoe u ad-hoc-teststerktes aanboort en waarde toevoegt aan het algehele testproces en de productkwaliteit.

Over de auteur: Dit is een gastartikel van Sneha Nadig. Ze werkt als een testleider met meer dan 7 jaar ervaring in handmatige en automatiseringstestprojecten.

Voer je ad-hoc testen uit op je project? Wat zijn uw suggesties om ad-hoc-tests succesvol te maken?

Aanbevolen literatuur

^