Ad-hoc testen: How to Find Defects Without a Formal Testing Process

De term ad hoc impliceert het ontbreken van structuur of iets dat niet methodisch is. Wanneer je het hebt over ad-hoctesten, betekent dit dat het een vorm van black box-testen of gedragstesten zijn die worden uitgevoerd zonder dat er sprake is van een formeel proces.

Het formele proces houdt hier in dat er documentatie aanwezig is, zoals documenten met eisen, testplannen, testgevallen en een goede testplanning met betrekking tot het tijdschema en de volgorde van de uitgevoerde tests. Ook alle tijdens het testen uitgevoerde handelingen worden doorgaans niet gedocumenteerd.

Dit wordt voornamelijk gedaan met het doel gebreken of fouten aan het licht te brengen die niet kunnen worden vastgelegd via traditionele of formele processen die tijdens de testcyclus worden gevolgd.

Zoals reeds is 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 dit doen zonder een bepaalde use case in gedachten met het doel het systeem te breken.

Hierbij is het zeker nog duidelijker dat een dergelijke intuïtieve of creatieve testmethodologie vereist dat de tester uiterst bekwaam, capabel en met een diepgaande know-how van het systeem. Ad-hoc testen zorgen ervoor dat de uitgevoerde testen volledig zijn en zijn bijzonder nuttig bij het bepalen van de effectiviteit van de test bucket.

Aanbevolen lectuur => Exploratory Testing – How to Think Beyond Traditional Testing Boundaries?

Let’s Start With An Ad-hoc Testing Example

Hier volgt een voorbeeld van hoe we dit testen kunnen uitvoeren als het gaat om UI Wizard.

Let’s say you need to create a plan or a template for some kind of task to be performed using this UI wizard.

Let’s say you need to create a plan or a template for some kind of task to be performed using this UI wizard.

De wizard bestaat uit een reeks vensters waarin de gebruiker gegevens kan invoeren, zoals naam, beschrijving, enz.

Zo lang de wizard duurt, moeten gebruikersgegevens worden ingevoerd, waardoor de UI-wizard een pop-upvenster opent waarin de bijbehorende gegevens worden toegevoegd om de wizard te voltooien en te implementeren/activeren.

Om dit te testen doet de tester zijn gewone testen zoals:

• Voltooi de wizard met succes met alle geldige gegevens en creër het plan.
• Blokkeer de wizard halverwege.
• Een gemaakt plan via de wizard bewerken.
• Het gemaakte plan verwijderen en zien dat er geen residu van is.
• Een negatieve waarde in de wizard invoeren en zien dat de juiste foutmeldingen worden gezien.

Nu, voor het bovenstaande voorbeeld zijn hier enkele testgevallen voor ad-hoc tests die kunnen worden uitgevoerd om zo veel mogelijk defecten aan het licht te brengen:

• Tijdens het proberen om negatieve gegevens toe te voegen, voeg bepaalde speciale tekens die niet beperkt zijn om te zien of ze goed worden behandeld. Bijvoorbeeld, soms wizards niet beperken {of [ accolades, maar in bepaalde situaties, dit kan conflicteren met code op basis van de taal waarin het is geschreven, en zeer onbetrouwbaar gedrag veroorzaken.
• Een andere test is specifiek met betrekking tot pop-ups. Een gebruiker kan de pop-up laten starten en dan proberen de backspace toets op het toetsenbord in te drukken. Vele malen heb ik waargenomen dat door dit te doen, de wizard op de achtergrond volledig verdwijnt en de volledige gebruikersgegevens die waren ingevoerd tot het punt waarop de pop-up werd gestart, verloren gaan!

Karakteristieken van Ad-hoc testen:

Als u de scenario’s hierboven noteert, ziet u een aantal zeer duidelijke kenmerken van dit type testen.

Deze zijn:

• Ze zijn altijd in lijn met het testdoel. Het zijn echter bepaalde drastische 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 testen vindt bugs die proberen om de mazen van het testproces te markeren.
• Ook kijkend naar de bovenstaande twee tests, zou de natuurlijke reactie op het zijn dat – dit soort test kan slechts een keer worden uitgevoerd als het is niet haalbaar voor een re-test, tenzij er een defect geassocieerd.

Wanneer doen we ad-hoc testen?

Een vraag van een miljoen dollar inderdaad!

De meeste testteams worden altijd belast met te veel functies om te testen binnen een beperkte tijdspanne. In die beperkte tijdspanne zijn er veel testactiviteiten die zijn afgeleid van het formele proces en die ook moeten worden afgerond. In dergelijke situaties vinden ad-hoc testen maar mondjesmaat hun weg in het testen.

Maar uit mijn ervaring blijkt dat één ronde ad-hoc testen wonderen kan doen voor de productkwaliteit en veel ontwerpvragen kan oproepen.

Omdat ad-hoc testen meer een “wild-child” test techniek is die niet gestructureerd hoeft te zijn, is de algemene aanbeveling dat het moet worden uitgevoerd nadat de uitvoering van de huidige test bucket is gedaan. Een ander gezichtspunt is dat dit zou kunnen worden gedaan wanneer gedetailleerd testen niet kan worden uitgevoerd vanwege tijdgebrek.

In mijn visie zou ik zeggen dat ad-hoc testen bijna op elk moment kunnen worden gedaan – in het begin, naar het midden en naar het einde! Het vindt gewoon zijn plaats op een bepaald moment. Echter, wanneer ad-hoc testen moeten worden uitgevoerd om maximale waarde naar boven te halen, kan het beste worden beoordeeld door een ervaren tester die diepgaande kennis heeft over het systeem dat wordt getest.

Wanneer niet uitvoeren?

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

Terwijl we hebben vastgesteld hoe effectief en vruchtbaar ad-hoc testen kunnen zijn, moeten we als bekwame en capabele tester ook bepalen wanneer we niet in dit type testen moeten investeren. Hoewel het aan het oordeel van de tester is, volgen hier enkele aanbevelingen/voorbeelden wanneer het misschien niet nodig is.

• Vermijd dit testen wanneer er een testgeval 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/testen wanneer het is verholpen. Vandaar dat het hier niet van toepassing is.
• Er kunnen zich ook bepaalde scenario’s voordoen waarbij klanten of opdrachtgevers worden uitgenodigd om de beta-versie van de software te testen. In dergelijke gevallen moet dit testen niet worden uitgevoerd.
• Een ander scenario is wanneer er een zeer eenvoudige UI-scherm dat wordt toegevoegd. Traditionele positieve en negatieve testen moeten hier volstaan om maximale defecten naar boven te halen.

Types Of Ad-hoc Testing

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

#1) Buddy Testing

Bij deze vorm van testen worden een testlid en een ontwikkellid gekozen om aan dezelfde module te werken. Net nadat de ontwikkelaar klaar is met de unit testen, gaan de tester en ontwikkelaar bij elkaar zitten en werken aan de module. Deze manier van testen maakt het mogelijk om de functie in een breder perspectief te zien voor beide partijen.

De ontwikkelaar zal een perspectief krijgen van alle verschillende testen die de tester uitvoert en de tester zal een perspectief krijgen van hoe het inherente ontwerp is, wat hem zal helpen te voorkomen dat hij ongeldige scenario’s ontwerpt, waardoor ongeldige defecten worden voorkomen. Het zal de een helpen te denken als de ander.

#2) Pair Testing

In deze testvorm werken twee testers samen aan een module met dezelfde testopstelling die tussen hen wordt gedeeld. 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 werk van het testen delen en noodzakelijke documentatie van alle observaties maken.

#3) Aap Testen

Dit testen wordt hoofdzakelijk uitgevoerd op het niveau van unit testen. De tester parseert gegevens of tests op een volledig willekeurige manier om ervoor te zorgen dat het systeem in staat is om eventuele crashes te weerstaan. Dit testen kan verder worden ingedeeld in twee categorieën:

Ad-hoc testen Voordelen

Het testen geeft de tester veel macht om zo creatief te zijn als nodig is.

Dit verhoogt de testkwaliteit en de efficiency zoals hieronder:

• Het grootste voordeel dat opvalt is dat een tester het aantal defecten kan vinden dan bij traditioneel testen vanwege de diverse innovatieve methoden die zij kunnen toepassen om de software te testen.
• Deze vorm van testen kan overal in de SDLC worden toegepast; het is niet alleen beperkt tot het testteam. De ontwikkelaars kunnen ook het uitvoeren van deze testen, die hen zou helpen code beter en ook voorspellen welke problemen zich kunnen voordoen.
• Het kan worden gekoppeld aan een andere testen om de beste resultaten die soms kan de tijd die nodig is voor de reguliere testen in te korten te krijgen. Dit zou betere kwaliteit testgevallen om toelaten te worden gegenereerd en betere kwaliteit van het product op the whole.
• Het mandateert geen documentatie worden gedaan die de extra last op de tester voorkomt. 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.

Ad-hoc testen Nadelen

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

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

• Gevolgd op het eerste punt, zou dit ook resulteren in het niet in staat zijn om defecten te recreëren in de volgende pogingen als om informatie wordt gevraagd.
• Een andere zeer belangrijke vraag die dit aan het licht brengt is de verantwoordingsplicht van de inspanning. Aangezien dit niet is gepland / gestructureerd, is er geen manier om de tijd en moeite geïnvesteerd in dit soort testen te verantwoorden.
• Ad-hoc testen moet alleen worden uitgevoerd door een zeer goed geïnformeerde en bekwame tester in het team, omdat het vereist pro-actief te zijn en intuïtie in termen van het voorzien van potentiële defect ridden gebieden.

Best Practices To Make This Testing More Effective

We hebben uitvoerig de sterke en zwakke punten besproken die aan dit testen zijn verbonden.

In principe moet ad-hoc testen zijn plaats in de SDLC vinden, maar als het niet op de juiste manier wordt benaderd, kan het kostbaar blijken te zijn en een verspilling van kostbare testtijd. Dus hieronder zijn een paar tips om ad-hoc testen effectief te maken:

#1) Identificeer Defect vatbare gebieden:

Wanneer u een goede greep op het testen van een bepaald stuk software, zult u het erover eens dat er bepaalde functies die meer vatbaar zijn voor fouten dan de anderen.

Het aantal defecten in een bepaalde functie is zal u laten zien dat het gevoelig is en je moet juist dat gebied te kiezen om ad-hoc testen uit te voeren. Dit blijkt een zeer tijdsefficiënte manier te zijn om een aantal ernstige defecten bloot te leggen.

#2) Expertise opbouwen:

Ongetwijfeld is een tester met meer ervaring intuïtiever en kan hij beter raden waar de fouten zouden kunnen zitten, 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 over het systeem dat wordt getest.

Ja, ervaren testers hebben een streepje voor omdat hun in de loop der jaren opgebouwde vaardigheden van pas komen, maar de nieuwe testers moeten dit gebruiken als een platform om zoveel mogelijk kennis op te doen om betere ad-hoc scenario’s te ontwerpen.

#3) Maak testcategorieën:

Als je je eenmaal bewust bent van de lijst met te testen features, trek dan een paar minuten uit om te beslissen hoe je die features zou categoriseren en testen. Bijvoorbeeld, moet u besluiten om functies die het meest zichtbaar en meest gebruikt door de gebruiker voor iets anders te testen, zoals deze lijken te zijn van cruciaal belang voor het succes van de software.

Dan kun je ze categoriseren functionaliteit / prioriteit wijs en test ze segment voor segment.

Een ander voorbeeld waar dit is bijzonder belangrijk is, is als er integratie tussen componenten of modules. In deze gevallen kunnen er veel afwijkingen optreden. Het gebruik van categorisatie zou helpen om dit soort testen ten minste een of twee keer aan te raken.

#4) Heb een ruw plan:

Ja, ja dit punt kan je een beetje verwarren omdat we ad-hoc testen beschreven als testen die geen planning of documentatie zouden moeten hebben. Het idee hier is om vast te houden aan de essentie van ad-hoc testen, maar toch, hebben een aantal ruwe aanwijzingen genoteerd over hoe u van plan bent om te testen.

Een heel eenvoudig voorbeeld is dat soms je gewoon niet in staat zijn om alle tests die u van plan bent uit te voeren onthouden. Dus noteren ze zou ervoor zorgen dat u niet missen op iets.

#5) Tools:

Laten we een voorbeeld waarmee zeer vaak geconfronteerd door ons allemaal. Vaak is het testen van de functionaliteit op zich succesvol en wordt er geen afwijking in het gedrag gerapporteerd. Echter, de logs achter de schermen kunnen enkele uitzonderingen rapporteren die door de testers kunnen worden gemist omdat ze het testdoel op geen enkele manier belemmeren.

Deze kunnen zelfs zeer ernstig zijn. Daarom is het erg belangrijk voor ons om te leren en tools die zullen helpen pinpoint dit onmiddellijk.

#6) Document voor meer defecten:

Opnieuw, ik begrijp dat dit kan sommige wenkbrauwen weer te verhogen. Documentatie hoeft niet gedetailleerd te zijn, maar gewoon een kleine notitie voor je eigen referentie van alle verschillende scenario’s die aan bod komen, afwijking in stappen die betrokken zijn en noteer die defecten voor de specifieke categorie van testfuncties.

Dit zal je helpen om de algehele testbak ook te verbeteren waarbij je zou kunnen beslissen hoe je bestaande testgevallen kunt improviseren of meer kunt toevoegen indien nodig.

Conclusie

We hebben in detail gesproken over ad-hoc testtechnieken- zijn sterke en zwakke punten, situaties waarin het wel en niet gunstig zou zijn.

Dit is een testtechniek die garandeert dat de creativiteit van een tester maximaal wordt benut en bevredigd. In mijn hele test carrière, krijg ik de grootste voldoening van ad-hoc testen als er geen limiet aan het zijn innovatief en je alleen maar eindigen meer kennis.

Having gezegd dat, het belangrijkste ding om terug te nemen van alle bovenstaande informatie zou zijn om te bepalen hoe om te tikken in ad hoc testen sterke punten en maken het een toegevoegde waarde aan het totale testproces en de kwaliteit van het product.

Over de auteur: Dit is een gastartikel van Sneha Nadig. Zij is werkzaam als Test lead met meer dan 7 jaar ervaring in handmatige en automatisering testprojecten.

Doet u ad-hoc testen op uw project? Wat zijn uw suggesties om ad-hoc testen succesvol te maken?