Menu

Wat is automatiseringstesten (ultieme gids om testautomatisering te starten)

what is automation testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Een complete gids om automatiseringstests op uw project te starten:

Wat is automatiseringstesten?

Automatiseringstesten is een softwaretesttechniek om de werkelijke uitkomst te testen en te vergelijken met de verwachte uitkomst. Dit kan worden bereikt door testscripts te schrijven of door een automatiseringstesttool te gebruiken. Testautomatisering wordt gebruikt om repetitieve taken en andere testtaken die moeilijk handmatig uit te voeren zijn, te automatiseren.

automatisering testen gids

beste plek om gratis anime te kijken

Wilt u de automatiseringstest op uw project starten maar worstelt u met de meest basale stappen zoals hieronder genoemd:

  • Hoe automatisering in uw project introduceren?
  • Hoe de beste en juiste automatiseringstool selecteren?
  • Hoe effectief scripts ontwikkelen?
  • Hoe testscripts uitvoeren en onderhouden?
  • En tot slot, wat zijn de best practices die u moet volgen voor succesvolle automatiseringstests?

Vandaag hebben we gepland om uw kennis te verrijken met een reeks tutorials over ' Aan de slag met automatiseringstests ​Deze serie automatiseringshandleidingen zal alle bovenstaande vragen stapsgewijs beantwoorden met eenvoudige voorbeelden.

Laten we eens kijken naar de reeks tutorials over het starten van automatisering in uw project !!

Automatisering end-to-end proces:

Zelfstudie # 1 ​ Beste gids om automatisering op uw project te starten
Tutorial # 2: Soorten geautomatiseerde tests en enkele misvattingen
Tutorial # 3: 10 stappen om automatisering in uw project te introduceren
Tutorial # 4: De A tot Z-gids over het selecteren van de beste automatiseringstool
Tutorial # 5: Scriptontwikkeling en automatiseringsframeworks
Tutorial # 6: Uitvoering en rapportage van automatisering
Tutorial # 7: Best practices en strategieën voor testautomatisering

Automatiseringstips:

Tutorial # 8: 10 tips die u moet lezen voordat u uw testwerk gaat automatiseren
Tutorial # 9: Hoe verschilt de testplanning voor handmatige en automatiseringsprojecten
Tutorial # 10: Wanneer kiezen voor automatisering?
Tutorial # 11: Uitdagingen voor automatiseringstests
Tutorial # 12: Gids voor het implementeren van Proof of Concept (POC) in automatisering
Tutorial # 13: Hoe u de juiste testcases selecteert voor automatisering
Tutorial # 14: Hoe handmatige testcases te vertalen naar automatiseringsscripts

Automatisering Carrière:

Tutorial # 15: Tips om een ​​betere automatiseringstester te worden
Tutorial # 16: Testautomatisering - Is het een gespecialiseerde carrière? Kunnen normale testers ook automatiseren?

Populaire automatiseringstools:

Tutorial # 17: Selenium Tutorials 31+ Beste gratis Selenium Training Tutorials
Tutorial # 18: QTP-zelfstudies
Tutorial # 19: SoapUI Web Services-testtool
Tutorial # 20: HP LoadRunner voor prestatietests

Automatiseringsraamwerken:

Tutorial # 21: Waarom hebben we raamwerk voor automatisering nodig?
Tutorial # 22: Meest populaire automatiseringsframeworks

Automatisering in Agile:

Tutorial # 23: Hoe u efficiënte automatisering implementeert in de agile wereld

Andere automatiseringstools:

Tutorial # 24: Beste automatiseringstesttools
Tutorial # 25: Sikuli GUI-automatiseringstool
Tutorial # 26: PowerShell: automatisering van de gebruikersinterface van desktoptoepassingen met PowerShell
Tutorial # 27: Catalon Automation Recorder (Selenium IDE-alternatief)
Tutorial # 28: Geb Tool: Browserautomatisering met Geb Tool
Tutorial # 29: AutoIt: omgaan met Windows Pop-up met AutoIt
Tutorial # 30: Komkommer: automatisering met behulp van komkommerhulpmiddel en selenium
Tutorial # 31: Gradenboogtesttool voor end-to-end testen van AngularJS-applicaties

Testen van mobiele automatisering:

Tutorial # 32: Appium Studio Hands-on zelfstudie
Tutorial # 33: Appium Tutorial voor beginners
Tutorial # 34: Selendroid-zelfstudie: Android Mobile Automation Framework
Tutorial # 35: Ranorex-zelfstudie: een krachtige desktop-, web- en mobiele testtool

Domeinspecifieke automatiseringsvoorbeelden:

Tutorial # 36: Automatisering van JAVA / J2EE-applicaties

Interviewvoorbereiding voor automatiseringstaken:

Tutorial # 37: Interviewvragen voor automatiseringstesten
Tutorial # 38: Selenium sollicitatievragen

Laten we eens kijken naar de eerste tutorial uit de serie 'The Ultimate Guide to Automation Testing' !!

Wat je leert:

Wat is automatiseringstesten?

Als software iets kan doen, waarom kan software dan geen software testen?

Klinkt deze uitspraak logisch voor u?

Zo ja, dan gefeliciteerd, u denkt nu aan testautomatisering, wat het middelpunt is dat we gaan bespreken in deze reeks informatieve tutorials.

Stelt u zich eens voor dat u de eerste dag op uw werk als SQA bent. U krijgt een aanvraag te zien die moet worden getest. Het is een ERP-applicatie met honderden formulieren en duizenden rapporten. U begint uw verkennende toets door een formulier te openen dat ongeveer 50 verschillende velden bevat.

U probeert willekeurige gegevens in dit formulier in te voeren, wat ongeveer 20 minuten duurde. Vervolgens druk je op verzenden. Wolla !! Er wordt een foutbericht weergegeven dat eruitziet als een niet-verwerkte uitzondering. Je wordt erg blij. U noteert met trots de stappen en meldt de bug in uw bugmanagementsysteem. Veel moeite, je voelt je echt zelfverzekerd en energiek. Je gaat door met testen tot de dag ten einde loopt en nog wat bugs ontdekt. “Geweldige eerste dag”, dacht je.

Nu komt de volgende dag, de ontwikkelaar heeft het probleem opgelost en brengt een nieuwe versie van de build uit. Je test hetzelfde formulier met dezelfde stappen en je hebt ontdekt dat de bug is opgelost. U markeert het vast. Grote moeite. U heeft bijgedragen aan de kwaliteit van het product door die bug te identificeren en naarmate deze bug is verholpen, wordt de kwaliteit verbeterd.

Nu komt de derde dag, een ontwikkelaar heeft weer een nieuwere versie uitgebracht. Nu moet u dat formulier opnieuw testen om er zeker van te zijn dat er geen regressieprobleem wordt gevonden. Dezelfde 20 minuten. Nu voel je je een beetje verveeld.

Stel je nu eens voor dat er vanaf nu 1 maand nieuwere versies worden uitgebracht en bij elke release moet je deze lange vorm testen plus 100 andere vormen zoals deze, om er zeker van te zijn dat er geen regressie is.

Nu voel je je boos. Je voelt je moe ​Je begint stappen over te slaan. U vult ongeveer 50% van het totale aantal velden in. Je nauwkeurigheid is niet hetzelfde, je energie is niet hetzelfde en zeker, je stappen zijn niet hetzelfde.

En op een dag meldt de klant dezelfde bug in dezelfde vorm. Je voelt je zielig. Je voelt je nu onzeker. Je denkt dat je niet competent genoeg bent. Managers twijfelen aan uw bekwaamheid.

Ik heb nieuws voor je; dit is het verhaal van 90% van de handmatige testers die er zijn. Jij bent niet anders.

Regressieproblemen zijn de meest pijnlijke problemen. We zijn mensen. En we kunnen niet elke dag hetzelfde doen met dezelfde energie, snelheid en nauwkeurigheid. Dit is wat machines doen. Dit is waar automatisering voor nodig is, om dezelfde stappen met dezelfde snelheid, nauwkeurigheid en energie te herhalen als de eerste keer.

Ik hoop dat je begrijpt wat ik bedoel !!

automatisering testen van een vriend

Wanneer een dergelijke situatie zich voordoet, moet u uw testcase automatiseren. Testautomatisering is uw vriend ​Het zal u helpen om u te concentreren op nieuwe functionaliteit terwijl u voor de regressies zorgt. Met automatisering kunt u dat formulier in minder dan 3 minuten invullen.

Het script vult alle velden en vertelt u het resultaat samen met schermafbeeldingen. In het geval van een storing, kan het de locatie bepalen waar de testcase is mislukt, zodat u deze gemakkelijk kunt reproduceren.

Automatisering - een kosteneffectieve methode voor regressietesten

Automatiseringskosten zijn in eerste instantie echt hoger. Het omvat de kosten van de tool, vervolgens de kosten van het hulpmiddel voor automatiseringstests en zijn / haar training.

Maar als de scripts klaar zijn, kunnen ze honderden keren herhaaldelijk met dezelfde nauwkeurigheid en vrij snel worden uitgevoerd. Dit scheelt vele uren handmatig testen. Dus de kosten dalen geleidelijk, en uiteindelijk wordt het een kosteneffectieve methode voor Regressietesten ​

Scenario's die automatisering vereisen

Het bovenstaande scenario is niet het enige geval waarin u automatiseringstests nodig heeft. Er zijn verschillende situaties die niet handmatig kunnen worden getest.

Bijvoorbeeld ​

  1. Twee afbeeldingen pixel voor pixel vergelijken.
  2. Twee spreadsheets met duizenden rijen en kolommen vergelijken.
  3. Het testen van een applicatie onder de belasting van 100.000 gebruikers.
  4. Prestatiebenchmarks.
  5. Het testen van de applicatie op verschillende browsers en op verschillende besturingssystemen parallel.

Deze situaties vereisen en moeten worden getest met tools.

Dus, wanneer automatiseren?

Dit is een tijdperk van agile methodologie in SDLC, waar de ontwikkeling en het testen bijna parallel gaan en het erg moeilijk is om te beslissen wanneer te automatiseren.

Overweeg de volgende situaties voordat u in automatisering stapt

  • Het product bevindt zich misschien in de primitieve stadia, wanneer het product niet eens een gebruikersinterface heeft, in deze stadia moeten we een duidelijke gedachte hebben over wat we willen automatiseren. De volgende punten moeten in gedachten worden gehouden.
    • Tests mogen niet achterhaald zijn.
    • Naarmate het product evolueert, moet het gemakkelijk zijn om de scripts te kiezen en eraan toe te voegen.
    • Het is erg belangrijk om niet te laten meeslepen en ervoor te zorgen dat de scripts gemakkelijk te debuggen zijn.
  • Probeer UI-automatisering niet in de allereerste stadia, aangezien UI onderhevig is aan frequente wijzigingen, waardoor scripts mislukken. Kies zoveel mogelijk voor automatisering op API-niveau / niet-UI-niveau totdat het product stabiliseert. API-automatisering is eenvoudig op te lossen en te debuggen.

Hoe u de beste automatiseringsgevallen kiest:

Automatisering is een integraal onderdeel van een testcyclus en het is erg belangrijk om te beslissen wat we willen bereiken met automatisering voordat we besluiten te automatiseren.

De voordelen die automatisering lijkt te bieden, zijn erg aantrekkelijk, maar tegelijkertijd kan een slecht georganiseerde automatiseringssuite het hele spel bederven. Testers kunnen uiteindelijk de scripts debuggen en repareren, wat resulteert in verlies van testtijd.

Efficiënte testautomatisering

Deze serie legt u uit hoe een automatiseringssuite efficiënt genoeg kan worden gemaakt om de juiste testcases op te pikken en de juiste resultaten te behalen met de automatiseringsscripts die we hebben.

Ook heb ik de antwoorden op vragen behandeld als Wanneer automatiseren, Wat automatiseren, Wat niet automatiseren en Hoe automatisering strategiseren.

Juiste tests voor automatisering

De beste manier om dit probleem aan te pakken, is door snel een 'Automation Strategie' te bedenken die bij ons product past.

Het idee is om de testgevallen zo te groeperen dat elke groep ons een ander soort resultaat geeft. De onderstaande afbeelding laat zien hoe we onze vergelijkbare testcases kunnen groeperen, afhankelijk van het product / de oplossing die we testen.

Testcases groeperen

Laten we nu diep duiken en begrijpen wat elke groep ons kan helpen bereiken:

# 1) Maak een testsuite van alle basisfunctionaliteit Positieve testen ​Deze suite moet worden geautomatiseerd en wanneer deze suite wordt uitgevoerd tegen een willekeurige build, worden de resultaten onmiddellijk weergegeven. Elk script dat in deze suite faalt, leidt tot een S1- of S2-defect, en die build-specifieke kan worden gediskwalificeerd. We hebben hier dus veel tijd bespaard.

Als extra stap kunnen we deze geautomatiseerde testsuite toevoegen als onderdeel van BVT (Build-verificatietests) en de QA-automatiseringsscripts controleren in het productopbouwproces. Dus wanneer de build klaar is, kunnen testers de automatiseringstestresultaten controleren en beslissen of de build al dan niet geschikt is voor installatie en verder testproces.

Hiermee worden duidelijk de doelstellingen van automatisering bereikt, namelijk:

  • Verlaag de testinspanning.
  • Vind bugs in eerdere stadia.

#twee) Vervolgens hebben we een groep Einde om tests te beëindigen ​

Bij grote oplossingen is het testen van een end-to-end-functionaliteit de sleutel, vooral tijdens de kritieke fasen van het project. We zouden een paar automatiseringsscripts moeten hebben die ook betrekking hebben op de end-to-end oplossingstests. Wanneer deze suite wordt uitgevoerd, moet het resultaat aangeven of het product als geheel werkt zoals verwacht of niet.

De Automation-testsuite moet worden aangegeven als een van de integratiestukken is verbroken. Deze suite hoeft niet elke kleine functie / functionaliteit van de oplossing te dekken, maar moet de werking van het product als geheel dekken. Elke keer dat we een alfa- of bètaversie of andere tussenliggende releases hebben, zijn dergelijke scripts handig en geven ze de klant enig vertrouwen.

Laten we voor een beter begrip aannemen dat we een online winkelportaal , als onderdeel van de end-to-end-tests zouden we alleen de belangrijkste stappen moeten behandelen.

Zoals hieronder aangegeven:

  • Gebruiker login.
  • Blader en selecteer items.
  • Betalingsoptie - dit omvat de front-end-tests.
  • Beheer van back-endorders (omvat het communiceren met meerdere geïntegreerde partners, het controleren van de voorraad, het e-mailen van de gebruiker, enz.) - dit zal helpen bij het testen van de integratie van individuele stukken en ook bij de crux van het product.

Dus wanneer een dergelijk script wordt uitgevoerd, geeft dit het vertrouwen dat de oplossing als geheel goed werkt.!

b-boom versus b + boom

# 3) De derde set is de Op functie / functionaliteit gebaseerde tests ​

Voor voorbeeld We hebben mogelijk de functionaliteit om te bladeren en een bestand te selecteren, dus wanneer we dit automatiseren, kunnen we gevallen automatiseren om de selectie van verschillende soorten bestanden, bestandsgroottes enz. Op te nemen, zodat het testen van functies wordt uitgevoerd. Als er wijzigingen / toevoegingen aan die functionaliteit zijn, kan deze suite dienen als een regressiesuite.

# 4) De volgende op de lijst zou zijn UI-gebaseerde tests. We kunnen een andere suite hebben die puur UI-gebaseerde functionaliteiten test, zoals paginering, tekenbeperking voor tekstvakken, kalenderknop, vervolgkeuzemenu's, grafieken, afbeeldingen en veel van dergelijke alleen op de gebruikersinterface gerichte functies. Het falen van deze scripts is meestal niet erg kritiek, tenzij de gebruikersinterface volledig offline is of bepaalde pagina's niet verschijnen zoals verwacht!

# 5) We kunnen nog een andere reeks tests hebben die eenvoudig maar zeer bewerkelijk is om handmatig uit te voeren. Vervelende maar eenvoudige tests zijn de ideale kandidaten voor automatisering, bijvoorbeeld het invoeren van gegevens van 1000 klanten in de database heeft een eenvoudige functionaliteit, maar het is buitengewoon vervelend om handmatig uit te voeren; dergelijke tests moeten worden geautomatiseerd. Zo niet, dan worden ze meestal genegeerd en niet getest.

Wat moet je NIET automatiseren?

Hieronder staan ​​enkele tests die niet geautomatiseerd mogen worden.

# 1) Negatieve tests / Failover-tests

We moeten niet proberen te automatiseren negatieve of failover-tests , wat betreft deze tests moeten de testers analytisch denken en negatieve tests zijn niet echt eenvoudig om een ​​geslaagd of niet-geslaagd resultaat te geven dat ons kan helpen.

Negatieve tests vereisen veel handmatige tussenkomst om een ​​echt scenario voor noodherstel te simuleren. Om een ​​voorbeeld te geven, testen we functies zoals de betrouwbaarheid van webservices - om het hier te generaliseren, zou het belangrijkste doel van dergelijke tests zijn om opzettelijke fouten te veroorzaken en te zien hoe goed het product erin slaagt betrouwbaar te zijn.

Het simuleren van de bovenstaande fouten is niet eenvoudig, het kan het injecteren van wat stubs zijn of het gebruik van wat gereedschap tussendoor en automatisering is hier niet de beste manier om te gaan.

interviewvragen over rust en soap webservices

# 2) Ad hoc tests

Deze tests zijn misschien niet altijd echt relevant voor een product en dit kan zelfs iets zijn waar de tester aan zou kunnen denken in die fase van projectinitiatie, en ook de inspanning om een ​​ad-hoc test te automatiseren moet worden gevalideerd tegen het kritieke punt van de functie die de tests aanraken.

Bijvoorbeeld Een tester die een functie test die zich bezighoudt met compressie / codering van gegevens, heeft mogelijk intensieve ad-hoctests uitgevoerd met de verscheidenheid aan gegevens, bestandstypen, bestandsgroottes, corrupte gegevens, een combinatie van gegevens, met behulp van verschillende algoritmen, over verschillende platforms enz.

Wanneer we plannen automatisering we willen misschien prioriteiten stellen en niet alle ad-hoctests voor die functie alleen volledig automatiseren, en uiteindelijk wat tijd overhouden om de andere belangrijke functies te automatiseren.

# 3) Tests met uitgebreide voorinstellingen

Er zijn tests die een aantal enorme voorwaarden vereisen.

Bijvoorbeeld​ Mogelijk hebben we een product dat voor sommige functies kan worden geïntegreerd met software van derden, aangezien het product kan worden geïntegreerd met elk berichtenwachtrijsysteem dat op een systeem moet worden geïnstalleerd, wachtrijen moeten worden ingesteld, wachtrijen moeten worden aangemaakt, enz.

De 3rdpartijsoftware kan van alles zijn en de installatie kan complex van aard zijn en als dergelijke scripts worden geautomatiseerd, zullen deze voor altijd afhankelijk zijn van de functie / configuratie van die software van derden.

Voorwaarde zijn onder meer:

Op dit moment zien de dingen er misschien eenvoudig en schoon uit, aangezien beide instellingen aan de zijkant worden uitgevoerd en alles in orde is. We hebben bij talloze gelegenheden gezien dat wanneer een project de onderhoudsfase ingaat, het project wordt verplaatst naar een ander team, en ze eindigen met het debuggen van dergelijke scripts waarbij de eigenlijke test heel eenvoudig is, maar het script mislukt vanwege een 3rdpartijsoftwareprobleem.

Het bovenstaande is slechts een voorbeeld, houd in het algemeen tests in de gaten die moeizame voorinstellingen hebben voor een eenvoudige test die volgt.

Eenvoudig voorbeeld van testautomatisering

Wanneer u software test (op internet of desktop), gebruikt u normaal gesproken een muis en toetsenbord om uw stappen uit te voeren. Automatiseringstool bootst dezelfde stappen na door scripting of een programmeertaal te gebruiken.

Bijvoorbeeld , als u een rekenmachine test en het testgeval is dat u twee getallen moet optellen en het resultaat moet zien. Het script voert dezelfde stappen uit door gebruik te maken van uw muis en toetsenbord.

Het voorbeeld wordt hieronder getoond.

Handmatige testcase Stappen:

  1. Start Calculator
  2. Druk op 2
  3. Druk op +
  4. Druk op 3
  5. Druk op =
  6. Het scherm zou 5 moeten weergeven.
  7. Sluit Calculator.

Automatiseringsscript:

​

Het bovenstaande script is slechts een kopie van uw handmatige stappen. Het script is gemakkelijk te maken en ook gemakkelijk te begrijpen.

Wat zijn beweringen?

De voorlaatste regel van het script heeft wat meer uitleg nodig.

Assert.AreEqual ('5', txtResult.DisplayText, 'Calculator geeft 5 niet weer);

In elk testgeval hebben we aan het einde een verwacht of voorspeld resultaat. In het bovenstaande script hebben we de verwachting dat '5' op het scherm moet worden weergegeven. Het werkelijke resultaat is het resultaat dat op het scherm wordt weergegeven. In elk testgeval vergelijken we de verwachte uitkomst met de werkelijke uitkomst.

Hetzelfde geldt ook voor automatiseringstests. Het enige verschil hier is dat wanneer we die vergelijking doen in testautomatisering, het in elke tool iets anders wordt genoemd.

Sommige tools noemen het ' Bewering ', Sommigen noemen het als' controlepunt ”En sommigen noemen het' validatie '. Maar eigenlijk is dit slechts een vergelijking. Als deze vergelijking mislukt, voor Bijv. een scherm toont 15 in plaats van 5, dan mislukt deze bewering / checkpoint / validatie en wordt uw testcase gemarkeerd als mislukt.

Als een testcase mislukt vanwege een bewering, dan betekent dat dat je een bug hebt gedetecteerd door middel van testautomatisering. U moet het rapporteren aan uw bugbeheersysteem, net zoals u normaal doet bij handmatige tests.

In het bovenstaande script hebben we een bewering uitgevoerd in de voorlaatste regel. 5 is het verwachte resultaat, txtResult ​ DisplayText is het werkelijke resultaat en als ze niet gelijk zijn, krijgen we een bericht te zien dat 'Calculator toont geen 5'.

Gevolgtrekking

Vaak komen testers projectdeadlines en mandaten tegen om alle cases te automatiseren om testschattingen te verbeteren.

Er zijn enkele algemene 'verkeerde' percepties over automatisering.

Zij zijn:

  • We kunnen elke testcase automatiseren.
  • Het automatiseren van tests zal de testtijd enorm verkorten.
  • Er worden geen bugs geïntroduceerd als automatiseringsscripts soepel lopen.

We moeten duidelijk zijn dat automatisering de testtijd alleen voor bepaalde soorten tests kan verkorten. Het automatiseren van alle tests zonder plan of volgorde zal leiden tot enorme scripts die zwaar onderhoud vergen, vaak mislukken en ook veel handmatige tussenkomst vereisen. Ook kunnen automatiseringsscripts in voortdurend evoluerende producten verouderd raken en moeten ze voortdurend worden gecontroleerd.

Het groeperen en automatiseren van de juiste kandidaten bespaart veel tijd en biedt alle voordelen van automatisering.

Deze uitstekende tutorial kan worden samengevat in slechts 7 punten.

Automatiseringstesten:

  • Is het testen dat programmatisch wordt gedaan.
  • Gebruikt de tool om de uitvoering van tests te controleren.
  • Vergelijkt verwachte uitkomsten met de werkelijke uitkomsten (beweringen).
  • Kan enkele repetitieve maar noodzakelijke taken automatiseren ( Bijv. Uw regressietestgevallen).
  • Kan sommige taken automatiseren die moeilijk handmatig uit te voeren zijn (Bijv.Testscenario's laden).
  • Scripts kunnen snel en herhaaldelijk worden uitgevoerd.
  • Is kostenbesparend op de lange termijn.

Hier wordt automatisering in eenvoudige bewoordingen uitgelegd, maar dat betekent niet dat het altijd eenvoudig te doen is. Er zijn uitdagingen, risico's en vele andere obstakels die ermee gepaard gaan. Er zijn talloze manieren waarop testautomatisering fout kan gaan, maar als alles goed gaat, zijn de voordelen van testautomatisering echt enorm.

Aankomende in deze serie:

In onze komende tutorials zullen we verschillende aspecten bespreken die verband houden met automatisering.

Waaronder:

  1. Soorten geautomatiseerde tests en enkele misvattingen.
  2. Hoe u automatisering in uw organisatie kunt introduceren en veelvoorkomende valkuilen kunt vermijden bij het uitvoeren van testautomatisering.
  3. Het gereedschapsselectieproces en vergelijking van verschillende automatiseringstools.
  4. Script Development and Automation Frameworks met voorbeelden.
  5. Uitvoering en rapportage van testautomatisering.
  6. Best practices en strategieën voor testautomatisering.

Wilt u meer weten over elk concept van Automation Testing? Kijk uit en blijf op de hoogte van onze lijst met aankomende tutorials in deze serie en voel je vrij om je mening te geven in de comments hieronder.

VOLGENDE Tutorial # 2

Aanbevolen literatuur

^