Menu

Complete functionele testgids met zijn typen en voorbeelden

complete functional testing guide with its types

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Een diepgaande, uitgebreide tutorial over functioneel testen met typen, technieken en voorbeelden:

Wat is functioneel testen?

Functioneel testen is een soort black-box-test die wordt uitgevoerd om te bevestigen dat de functionaliteit van een applicatie of systeem zich gedraagt ​​zoals verwacht.

Het wordt gedaan om alle functionaliteit van een applicatie te verifiëren.

LIJST van de tutorials die in deze serie worden behandeld:

Tutorial # 1: Wat is functioneel testen (deze tutorial)
Tutorial # 2: Functionaliteitstesten Interviewvragen
Tutorial # 3: Toptools voor functionele automatisering
Tutorial # 4: Wat is niet-functioneel testen?
Tutorial # 5: Verschil tussen eenheid, functioneel en Integratie Testen
Tutorial # 6 ​ Waarom functionele en prestatietests tegelijkertijd moeten worden uitgevoerd

Gereedschap:

Tutorial # 7: Functionele testautomatisering met Ranorex Studio
Tutorial # 8: UFT Functional Tool Nieuwe functies
Tutorial # 9: Cross Browser functionele automatisering met Parrot QA Tool
Tutorial # 10: Jubula Open Source Tool-zelfstudie voor het testen van functionaliteit

functioneel testen

Wat je leert:

Inleiding tot functioneel testen

Er moet iets zijn dat definieert wat acceptabel gedrag is en wat niet.

Dit wordt gespecificeerd in een functie- of eisenspecificatie. Het is een document dat beschrijft wat een gebruiker mag doen, zodat hij kan bepalen of de applicatie of het systeem eraan voldoet. Bovendien kan dit soms ook betekenen dat de feitelijke scenario's aan de zakelijke kant moeten worden gevalideerd.

Daarom kunnen functionaliteitstests worden uitgevoerd via twee populaire technieken ​

  • Testen op basis van vereisten: Bevat alle functionele specificaties die de basis vormen voor alle uit te voeren tests.
  • Testen op basis van bedrijfsscenario's: Bevat de informatie over hoe het systeem zal worden gezien vanuit een bedrijfsprocesperspectief.

Testen en kwaliteitsborging vormen een groot deel van het SDLC-proces. Als tester moeten we op de hoogte zijn van alle soorten tests, zelfs als we er niet dagelijks bij betrokken zijn.

Omdat testen een oceaan is, is de reikwijdte ervan inderdaad zo enorm, en we hebben toegewijde testers die presteren verschillende soorten testen ​Waarschijnlijk moeten we allemaal bekend zijn met de meeste concepten, maar het kan geen kwaad om alles hier te organiseren.

Functionele testtypen

Functioneel testen kent veel categorieën en deze kunnen worden gebruikt op basis van het scenario.

De meest prominente typen worden hieronder kort besproken:

Testen van een eenheid ​

Het testen van eenheden wordt meestal uitgevoerd door een ontwikkelaar die verschillende code-eenheden schrijft die al dan niet gerelateerd kunnen zijn om een ​​bepaalde functionaliteit te bereiken. Dit houdt meestal in dat eenheidstests worden geschreven die de methoden in elke eenheid aanroepen en deze valideren wanneer de vereiste parameters zijn doorgegeven, en de geretourneerde waarde is zoals verwacht.

Codedekking is een belangrijk onderdeel van het testen van eenheden, waarbij de testgevallen moeten bestaan ​​om de onderstaande drie te dekken:

i) Lijndekking
ii) Dekking van het codepad
iii) Dekking van methoden

Sanity testen ​ Dat wordt getest om ervoor te zorgen dat alle belangrijke en vitale functionaliteiten van de applicatie / het systeem correct werken. Dit gebeurt meestal na een rooktest.

Rook testen ​ Testen die worden uitgevoerd nadat elke build is vrijgegeven om te testen om de stabiliteit van de build te garanderen. Het wordt ook wel buildverificatietesten genoemd.

Regressietests ​ Er zijn tests uitgevoerd om ervoor te zorgen dat het toevoegen van nieuwe code, verbeteringen en het verhelpen van bugs de bestaande functionaliteit niet verbreekt of instabiliteit veroorzaakt en nog steeds werkt volgens de specificaties.

Regressietests hoeven niet zo uitgebreid te zijn als de daadwerkelijke functionele tests, maar moeten juist de hoeveelheid dekking garanderen om te certificeren dat de functionaliteit stabiel is.

Integratietests ​ Wanneer het systeem vertrouwt op meerdere functionele modules die afzonderlijk perfect kunnen werken, maar coherent moeten werken wanneer ze samen worden geknuppeld om een ​​end-to-end-scenario te bereiken, wordt validatie van dergelijke scenario's integratietesten genoemd.

Beta / bruikbaarheidstests ​ Het product wordt blootgesteld aan de daadwerkelijke klant in een productie zoals een omgeving en zij testen het product. Het comfort van de gebruiker wordt hiervan afgeleid en de feedback wordt opgevangen. Dit is vergelijkbaar met het testen van gebruikersacceptatie.

Laten we dit in een eenvoudig stroomschema weergeven:

Functionele testcategorieën

Functioneel systeem testen:

Systeem testen is een test die wordt uitgevoerd op een compleet systeem om te controleren of het werkt zoals verwacht zodra alle modules of componenten zijn geïntegreerd.

End-to-end testen wordt uitgevoerd om de functionaliteit van het product te verifiëren. Deze test wordt alleen uitgevoerd als de systeemintegratietest is voltooid, inclusief zowel de functionele als de niet-functionele vereisten.

​ Verschil tussen eenheids-, functionele en integratietesten

Werkwijze

Dit testproces bestaat uit drie hoofdstappen:

Stappen van functioneel testproces

Aanpak, technieken en voorbeelden

Functionele of gedragstests genereren een output op basis van de gegeven inputs en bepalen of het systeem correct functioneert volgens de specificaties.

Daarom ziet de afbeelding eruit zoals hieronder:

Functioneel testproces

In- / uitstapcriteria

Toelatingscriteria:

  • Het Requirement Specification-document is gedefinieerd en goedgekeurd.
  • Er zijn testcases opgesteld.
  • Er zijn testgegevens gemaakt.
  • De omgeving om te testen is klaar, alle tools die nodig zijn zijn beschikbaar en klaar.
  • Volledige of gedeeltelijke applicatie is ontwikkeld en unit getest en is klaar om te testen.

Exit Criteria:

  • De uitvoering van alle functionele testgevallen is afgerond.
  • Er zijn geen kritieke of P1, P2-bugs open.
  • Gemelde bugs zijn erkend.

Betrokken stappen

De verschillende stappen die bij deze test zijn betrokken, worden hieronder vermeld:

  • De allereerste stap is het bepalen van de functionaliteit van het product dat moet worden getest en omvat het testen van de belangrijkste functionaliteiten, foutcondities en berichten, bruikbaarheidstesten, d.w.z. of het product gebruiksvriendelijk is of niet, enz.
  • De volgende stap is het maken van de invoergegevens voor de te testen functionaliteit volgens de specificatie van de vereisten.
  • Later, op basis van de specificatie van de vereisten, wordt de output bepaald voor de te testen functionaliteit.
  • Voorbereide testcases worden uitgevoerd.
  • De werkelijke output, d.w.z. de output na het uitvoeren van de testcase en de verwachte output (bepaald op basis van specificatie van de vereisten), worden vergeleken om te bepalen of de functionaliteit werkt zoals verwacht of niet.

Nadering

Er kunnen verschillende soorten scenario's worden bedacht en geschreven in de vorm van 'testcases'. Als QA-mensen weten we allemaal hoe het skelet van een testcase eruitziet.

Het bestaat meestal uit vier delen:

  • Test samenvatting
  • Eerste vereisten
  • Teststappen en
  • Verwachte resultaten.

Elke soort test proberen te schrijven is niet alleen onmogelijk, maar ook tijdrovend en duur.

Meestal willen we het maximale aantal bugs ontdekken zonder ontsnappingen met bestaande tests. Daarom moet de QA optimalisatietechnieken gebruiken en strategieën bedenken hoe ze het testen zouden benaderen.

Laten we dit uitleggen met een voorbeeld.

Voorbeelden van gebruiksvoorbeelden van functionele tests:

Neem een ​​online HRMS-portaal waar de medewerker inlogt met zijn gebruikersaccount en wachtwoord. Op de inlogpagina zijn er twee tekstvelden voor de gebruikersnaam en het wachtwoord en twee knoppen: Inloggen en Annuleren. Succesvol inloggen brengt de gebruiker naar de startpagina van HRMS en annuleren annuleert de login.

Specificaties zijn zoals hieronder weergegeven:

# 1) Het gebruikers-ID-veld duurt minimaal 6 karakters, maximaal 10 karakters, cijfers (0-9), letters (a-z, A-z), speciale karakters (alleen onderstrepingsteken, punt, koppelteken toegestaan) en mag niet leeg worden gelaten. Gebruikers-ID moet beginnen met een teken of cijfer en mag geen speciale tekens bevatten.

#twee) Wachtwoordveld duurt minimaal 6 tekens, maximaal 8 tekens, cijfers (0-9), letters (a-z, A-Z), speciale tekens (alles) en mag niet leeg zijn.

Voorbeeld use case - HRMS Online Portal

De basisbenadering voor het testen van dit scenario kan in twee brede categorieën worden ingedeeld:

  1. Positieve testen en
  2. Negatief testen

Uiteraard heeft elk van deze categorieën zijn onderafdeling van tests die zullen worden uitgevoerd.

Positieve testen zijn happy path-tests die worden uitgevoerd om ervoor te zorgen dat het product voldoet - tenminste aan de basisvereisten die essentieel zijn voor het gebruik door de klant.

Negatieve scenario's zorg ervoor dat het product zich correct gedraagt, zelfs wanneer het is blootgesteld aan onverwachte gegevens.

Voorgesteld lezen => Wat is negatief testen en hoe u negatieve testcases schrijft

Laat me nu proberen de testtechnieken te structureren met behulp van een stroomschema hieronder. We gaan in op de details van elk van deze tests.

Functionele testtechnieken

Functionele testtechnieken

# 1) Op eindgebruikers gebaseerde / systeemtests

Het te testen systeem kan vele componenten hebben die, wanneer ze aan elkaar zijn gekoppeld, het gebruikersscenario bereiken.

In de Voorbeeld zou een klantscenario taken omvatten zoals het laden van een HRMS-applicatie, het invoeren van de juiste inloggegevens, naar de startpagina gaan, bepaalde acties uitvoeren en uitloggen bij het systeem. Deze specifieke stroom moet zonder fouten werken voor een standaard bedrijfsscenario.

beste pc-reiniger voor Windows 7 gratis download

Enkele voorbeelden worden hieronder gegeven:

Sl nrOverzichtVoorwaardeTestgevalVerwachte resultaten.
1.Een volledig bevoorrechte gebruiker kan accountwijzigingen aanbrengen1) Gebruikersaccount moet bestaan
2) De gebruiker moet de vereiste rechten hebben		1) Gebruiker voert het gebruikersnaam en wachtwoord in
2) Gebruiker ziet bewerkingsrechten om het account zelf te wijzigen
3) Gebruiker wijzigt accountinformatie en slaat op.
4) Gebruiker logt uit.		1) De gebruiker is ingelogd op de startpagina
2) Het bewerkingsscherm wordt aan de gebruiker gepresenteerd.

3) Accountgegevens worden opgeslagen
4) De gebruiker wordt teruggebracht naar de inlogpagina
twee.Een andere geldige gebruiker zonder volledige rechten1) Gebruikersaccount moet bestaan
2) De gebruiker moet de minimale rechten hebben		1) Gebruiker voert het gebruikersnaam en wachtwoord in
2) Gebruiker ziet bewerkingsrechten om alleen bepaalde velden te wijzigen.
3) Gebruiker wijzigt alleen die velden en slaat op.
4) Gebruiker logt uit.		1) De gebruiker is ingelogd op de startpagina
2) Het bewerkingsscherm wordt alleen voor bepaalde velden aan de gebruiker getoond. De accountvelden zijn grijs.
3) Gewijzigde velden worden opgeslagen
4) De gebruiker wordt teruggebracht naar de inlogpagina

Dit is een eenvoudig voorbeeld van hoe testcases worden geschreven voor situaties. Het bovenstaande formaat is ook van toepassing op alle onderstaande tests. Omwille van een sterke conceptuele basis heb ik alleen enkele eenvoudige tests hierboven en hieronder uitgevoerd.

# 2) Gelijkwaardigheidstests

In Equivalentiepartitionering worden de testgegevens gescheiden in verschillende partities die equivalentiegegevensklassen worden genoemd. Gegevens in elke partitie moeten zich op dezelfde manier gedragen, daarom hoeft er maar één voorwaarde te worden getest. Evenzo, als een voorwaarde in een partitie niet werkt, zal geen van de andere werken.

Bijvoorbeeld , in het bovenstaande scenario kan het gebruikers-ID-veld maximaal 10 tekens bevatten, dus het invoeren van gegevens> 10 zou op dezelfde manier moeten werken.

# 3) Grenswaardetests

Grenstests impliceren datalimieten voor de toepassing en valideren hoe deze zich gedraagt.

Daarom, als de invoer buiten de grenswaarden wordt geleverd, wordt dit als een negatieve test beschouwd. Dus een minimum van 6 karakters voor de gebruiker bepaalt de grens. Tests geschreven met gebruikers-ID<6 characters are boundary analysis tests.

# 4) Op beslissingen gebaseerde tests

Op beslissingen gebaseerde tests zijn gecentreerd rond de ideologie van de mogelijke uitkomsten van het systeem wanneer aan een bepaalde voorwaarde wordt voldaan.

In het bovenstaande scenario kunnen de volgende beslissingsgebaseerde tests direct worden afgeleid:

  1. Als de verkeerde inloggegevens zijn ingevoerd, moet dit de gebruiker aangeven en de aanmeldingspagina opnieuw laden.
  2. Als de gebruiker de juiste inloggegevens invoert, moet de gebruiker naar de volgende gebruikersinterface gaan.
  3. Als de gebruiker de juiste inloggegevens invoert, maar de aanmelding wil annuleren, mag de gebruiker niet naar de volgende gebruikersinterface gaan en de aanmeldingspagina opnieuw laden.

# 5) Alternatieve flowtests

Alternatieve padtests worden uitgevoerd om alle mogelijke manieren te valideren die bestaan, behalve de hoofdstroom om een ​​functie uit te voeren.

# 6) Ad-hoc-tests

Wanneer de meeste bugs worden ontdekt via de bovenstaande technieken, ad-hoc tests zijn een uitstekende manier om eventuele discrepanties aan het licht te brengen die niet eerder zijn waargenomen. Deze worden uitgevoerd met de mentaliteit om het systeem te doorbreken en te kijken of het gracieus reageert.

Bijvoorbeeld zou een voorbeeldtestcase zijn:

  • Een gebruiker is aangemeld, maar de admin verwijdert het gebruikersaccount terwijl hij enkele bewerkingen uitvoert. Het zou interessant zijn om te zien hoe de applicatie dit gracieus aanpakt.

Functioneel versus niet-functioneel testen:

Niet-functionele tests focus op de kwaliteit van de applicatie / het systeem als geheel. Daarom probeert het af te leiden hoe goed het systeem presteert volgens de eisen van de klant, in tegenstelling tot de functie die het vervult.

​ Lees hier het exacte verschil

Functionele testautomatisering

Kunnen we functionele tests automatiseren?

Met automatisering kan handmatige inspanning worden verminderd, kan tijd worden bespaard, kunnen bugs worden vermeden en kan de efficiëntie worden verhoogd.

Het is echter niet mogelijk om alles te automatiseren. Dit testen kan worden geautomatiseerd, maar de gebruiker moet voor testcases uitwerken om de automatisering uit te voeren. Het is belangrijk om de juiste testcases te vinden die moeten worden geautomatiseerd, samen met een geschikte tool.

Het automatiseren van functionele cases kan nadelen hebben, zoals als het aantal testcases veel meer is en keer op keer terugloopt (wat moet worden gedaan), dan kan de ontwikkelaar een probleem tegenkomen bij het doorvoeren van wijzigingen in de code.

Tijdens het uitvoeren van een defect-ontsnappingsanalyse lijkt de prominente en blijvende oorzaak van ontsnappingen vaak een gebrek aan testdekking in een bepaalde functie te hebben.

Nogmaals, er zijn verschillende oorzaken voor, zoals een gebrek aan omgevingen, gebrek aan testers, te veel functies die worden geleverd, minder tijd om alle testaspecten te dekken en soms gewoon over het hoofd te zien.

Hoewel toegewijde testteams gedetailleerde tests kunnen uitvoeren tijdens elke sprint of elke testcyclus, zullen defecten altijd bestaan ​​en zullen er altijd defecten zijn die kunnen worden gemist. Dit is een van de fundamentele behoeften om testautomatisering te hebben, waardoor de efficiëntie van het algehele testproces en de dekking van testcases aanzienlijk zijn verbeterd.

Hoewel geautomatiseerd testen nooit handmatige tests kan vervangen, zal het hebben van een ideale mix van beide essentieel blijken te zijn om de gewenste kwaliteit in softwareprojecten te hebben.

Overwegingen bij automatisering:

# 1) Selecteer de juiste automatiseringstool ​ Er zijn verschillende tools op de markt, het kiezen van een automatiseringstool is een hele opgave! U kunt echter een lijst met vereisten maken, op basis waarvan u kunt selecteren welke automatiseringstool u wilt gebruiken.

Enkele belangrijke aspecten om aan te denken zijn:

  • Selecteer een tool die gemakkelijk te gebruiken is door alle QA-leden van het team, als ze nog niet over de vereiste vaardigheden beschikken.
  • De tool kan in verschillende omgevingen worden gebruikt. Voor Voorbeeld : Kunnen de scripts op het ene OS-platform worden gemaakt en op een ander worden uitgevoerd? Heeft u CLI-automatisering, UI-automatisering, automatisering van mobiele applicaties of alles nodig?
  • De tool moet alle functies hebben die u nodig heeft. Voor Voorbeeld : Als sommige testers niet goed thuis zijn in een scripttaal, moet de tool een opname- en afspeelfunctie hebben en vervolgens de conversie van het opgenomen script naar de gewenste scripttaal ondersteunen. Evenzo, als u de tool ook nodig hebt om geautomatiseerde build-tests, specifieke rapportage en logboekregistratie te ondersteunen, dan moet het dat ook kunnen.
  • De tool moet de herbruikbaarheid van testcases kunnen ondersteunen in het geval van UI-wijzigingen.

Automatiseringstools : Er zijn nogal wat tools beschikbaar voor functionele automatisering. Selenium is waarschijnlijk een populaire favoriet, maar er zijn ook enkele andere open-sourcehulpmiddelen zoals Sahi, Watir, Robotium, AutoIt, enz.

Er zijn verschillende testautomatiseringstools op de markt beschikbaar. Maar het kiezen van de juiste tool is erg belangrijk voor de organisatie. Het kan afhangen van de behoefte, het gebruiksgemak en de kosten spelen hier een grote rol.

Hieronder staan ​​enkele van de beste functionele testtools:

  • Selenium
  • QTP
  • Junit
  • Loadrunner
  • ZEEP
  • TestComplete

​ Bekijk deze volledige lijst met functionele automatiseringstools

#twee) Kies de juiste testcases om te automatiseren ​ Als u het beste uit automatisering wilt halen, is het van vitaal belang om slim te zijn in het soort tests dat u kiest om te automatiseren. Als er tests zijn die enige instellingen en configuraties vereisen tijdens het uitvoeren van de test, kunt u deze het beste niet-geautomatiseerd laten.

Daarom kunt u tests automatiseren die:

  • Moet herhaaldelijk worden uitgevoerd.
  • Ren met verschillende soorten gegevens.
  • Sommige P1, P2-testcases kosten veel moeite en tijd.
  • Tests die foutgevoelig zijn.
  • Set tests die moeten worden uitgevoerd in verschillende omgevingen, browsers, enz.

# 3) Toegewijd automatiseringsteam : Dit wordt in de meeste organisaties waarschijnlijk over het hoofd gezien en automatisering wordt opgelegd aan alle leden van het QA-team.

Elk teamlid heeft verschillende ervaringsniveaus, vaardigheden, interesses, bandbreedte om automatisering te ondersteunen, enz. Sommige individuen zijn mogelijk beter bekwaam in het uitvoeren van handmatige tests, terwijl anderen wellicht scripting- en automatiseringstools kennen.

In situaties als deze is het een goede gewoonte om een ​​analyse te maken van alle teamleden en een aantal leden alleen te laten automatiseren.

Automatiseringsactiviteiten vereisen tijd, moeite, kennis en een toegewijd team dat zal helpen om de vereiste resultaten te behalen in plaats van alle teamleden te overladen met zowel handmatige als automatiseringstests.

# 4) Gegevensgestuurde tests: Geautomatiseerde testcases waarvoor meerdere sets gegevens nodig zijn, moeten goed worden geschreven, zodat ze herbruikbaar zijn. De gegevens kunnen worden geschreven in bronnen zoals tekst- of eigenschappenbestand, XML-bestanden, of kunnen worden gelezen uit een database.

Wat de gegevensbron ook is, het creëren van goed gestructureerde automatiseringsgegevens maakt het raamwerk gemakkelijker te onderhouden en zorgt ervoor dat de bestaande testscripts optimaal worden benut.

# 5) UI-wijzigingen mogen tests niet breken: De testcases die u maakt met de geselecteerde tool, moeten de mogelijke UI-wijzigingen aankunnen. In eerdere versies van selenium werd bijvoorbeeld een locatie gebruikt om de pagina-elementen te identificeren.

Als de gebruikersinterface dus veranderde, werden die elementen niet langer op die locaties gevonden en zullen ze op hun beurt leiden tot het massaal mislukken van tests.

Daarom is het belangrijk om van tevoren de tekortkomingen van de tool te begrijpen en de testcases zo te schrijven dat er slechts minimale wijzigingen nodig zijn in het geval van UI-wijzigingen.

# 6) Regelmatig testen: Als u eenmaal een standaardautomatiseringstestbucket klaar heeft staan, kunt u deze bak vaker uitvoeren. Dit heeft een tweerichtingsvoordeel: het ene is dat u het automatiseringsraamwerk kunt verbeteren en robuuster kunt maken en het tweede is dat u tijdens het proces meer bugs zult oplopen.

Voordelen

Hieronder worden de verschillende voordelen van functioneel testen opgesomd:

  • Deze test reproduceert of is een replica van wat het daadwerkelijke systeem is, d.w.z. het is een replica van wat het product is in de live-omgeving. Het testen is gericht op de specificaties volgens het gebruik door de klant, d.w.z. systeemspecificaties, besturingssysteem, browsers, enz.
  • Het werkt niet op enige if en buts of veronderstellingen over de structuur van het systeem.
  • Deze testen zorgen ervoor dat we een kwalitatief hoogstaand product afleveren dat voldoet aan de klantwens en zorgt ervoor dat de klant tevreden is met het eindresultaat.
  • Het zorgt ervoor dat een foutvrij product wordt geleverd met alle functionaliteiten die werken volgens de eisen van de klant.
  • Op risico gebaseerde tests worden uitgevoerd om de kans op elk soort risico in het product te verkleinen.

Beperkingen

Deze tests worden uitgevoerd om ervoor te zorgen dat het product werkt zoals verwacht en dat de volledige vereiste is geïmplementeerd en dat het product precies voldoet aan de vereisten van de klant.

Het houdt echter geen rekening met de andere factoren, zoals de prestatie van het product, d.w.z. reactievermogen, doorlooptijd, enz., Die belangrijk zijn en zeer noodzakelijk zijn om deel uit te maken van het testen voordat het product wordt vrijgegeven.

Nadelen

  • Er zijn veel kansen om redundante tests uit te voeren.
  • Logische fouten kunnen in het product worden gemist.
  • Deze test is gebaseerd op de vereiste, als in het geval de vereiste niet volledig of ingewikkeld of niet duidelijk is, het uitvoeren van deze tests in een dergelijk scenario moeilijk wordt en ook tijdrovend kan zijn.

Daarom zijn beide soorten tests in principe nodig voor een kwaliteitsproduct.

Gevolgtrekking

In deze tutorial is alles wat je moet weten over functioneel testen uitgebreid besproken, vanaf de basis.

Functioneel testen is een van de belangrijke testprocessen, aangezien het de functionaliteit van een product verifieert dat het meest vereist en zelfs het belangrijkste aspect van elk product of elke toepassing is.

Over de auteur: Sanjay Zalavadia - als de VP van Client Service voor Zefier , brengt meer dan 15 jaar leiderschapservaring in IT en technische ondersteuningsdiensten met zich mee.

Ik hoop dat enkele van de technieken die we hebben voorgesteld, van pas zullen komen voor alle lezers. Laat ons je mening weten in de reacties hieronder.

Voorgesteld lezen => Tutorial voor het testen van functies

Aanbevolen literatuur

^