Sinds het ontstaan in de jaren ’90 heeft testautomatisering tieners, twintigers en twintigers gekend. Van opname- en afspeelmethodologie tot kunstmatige intelligentie en automatisering op basis van machine learning, de evolutie ervan is fascinerend vanwege het constante debat over de effectiviteit ervan.

Ondanks het bestaan of het nut ervan, blijven een aantal concepten rond dit onderwerp voor sommigen van ons een raadsel. Bijvoorbeeld,

• Succes met testautomatisering
• Testautomatisering: Een ongrijpbaar doel
• Projecten lopen achter op schema ondanks automatisering
• De rol van automatisering in toekomstige tests

Dit zijn raadsels uit eigen ervaringen, maar het klinkt wel bekend en redelijk consistent. Er kunnen er nog meer zijn, sommige hebben oplossingen en sommige moeten nog worden opgelost.

…wat me bij het onderwerp brengt

Nu in de ogen van Sujatha…

Duidelijkheid en een duidelijke strategie krijgen over wat je wilt bereiken met testautomatisering

Proberen om tests te automatiseren terwijl de rest van het proces in de levenscyclus van softwarelevering (SDLC) legacy blijft, is het snelste recept voor een ramp met automatisering. Het upgraden van de rest van de SDLC-fase vult goed aan wanneer je tests gaat automatiseren.

Veel bedrijven moedigen bijvoorbeeld het automatiseren van unit/integratietests niet aan, of volgen geen testbare aanpak bij het bouwen van een product. Ze willen testen op UI-niveau door middel van automatisering. Voor hen betekent automatisering alleen functioneel of UI-niveau.

Deze praktijken hebben de neiging om een voorspelbaar pad van chaos te volgen.

Even lijkt de motor op schema te liggen. Maar als puntje bij paaltje komt, gebeurt er wel degelijk iets. Uiteindelijk lopen ze achter op schema.

De gebruikelijke remedie voor deze uitdaging is slechts één ding — doorbreek het typische monolithische proces van alles automatiseren en categoriseer het in delen Unit, Integratie, API en UI.

Zoals Software Testing News het stelde,

De grootste brok is dat 70% van de geschreven tests unit tests zouden moeten zijn, die voornamelijk worden geschreven door ontwikkelaars om hun eigen code te testen en bugs in een vroeg stadium op te vangen voordat ze bij QA-teams terechtkomen. Deze tests zijn cruciaal omdat ze een fundamentele testdekking bieden die het aantal grote bugs vermindert die later in de testcyclus worden gevonden.

Als we omhoog klimmen in de piramide, moet de volgende 20% worden toegewezen aan integratietests, die meestal worden geschreven als systemen worden geïntegreerd met andere afhankelijke systemen en systemen van derden, waarbij mock services en geautomatiseerde gevirtualiseerde omgevingen kunnen worden gebruikt om de dekking volledig in te vullen waar unit tests mogelijk worden gemist.

Als we de top van de piramide bereiken, moet de laatste 10% zich voornamelijk richten op functionele UI-tests. Deze tests zijn broos omdat elke UI betovering gemakkelijk testpakketten kan breken. Daarom zouden ze idealiter moeten worden geautomatiseerd op bouwpijplijnen, waardoor onderhoudbaarheid en verdere verkennende testinspanningen mogelijk zijn naarmate iteratieve builds vorderen. Door middel van het testpiramidemodel kunnen teams kosten en tijd besparen in hun testcyclus, door de testdekking aan de onderkant van de piramide te vergroten en bugs te elimineren die aan het licht komen naarmate we verder omhoog gaan naar de bedrijfsgerichte UI-testlagen.

State of Test Automation 2022 rapporteert – 30% van de organisaties geeft prioriteit aan de verschuiving van handmatig naar geautomatiseerd testen in 2022.

Hieruit blijkt dat de overstap naar geautomatiseerd testen voor sommige bedrijven nog steeds een droom is.

Sujatha somt een aantal belangrijke factoren op waarmee je rekening moet houden als je overstapt op geautomatiseerd testen:

• Ondersteuning van het ecosysteem door een testbaar product te bouwen

Ervoor zorgen dat er een testbaar product wordt gebouwd. Met testbaar bedoel ik – het hebben van unieke en leesbare UI-elementen, het hebben van een unieke ID voor alle componenten (waardoor het niet nodig is om X path scripts te schrijven), waardoor de identifiers direct zijn en het proces van automatiseren op UI-niveau eenvoudiger wordt, zelfs als de stijl en het ontwerp op een later moment verandert.

• Begrijpen dat functionele testautomatisering handmatige regressietests aanvult en niet vervangt

Met automatisering verbeter je alleen de efficiëntie van handmatige regressietests door deze te automatiseren. Bekijk geautomatiseerde regressietests niet op zichzelf

• Toolsets en processen die je kiest moeten passen bij het release- en testproces van je product

Gebruik dockers in plaats van virtuele machines. Het vermindert de onderhoudsinspanning en geeft je controle over je exacte vereisten.
Komend naar het proces, als je huidige opstelling er ongeveer zo uitziet: Ad-hoc build pass – Smoke test – verplaatsen naar productie.
Dan zal het integreren van geautomatiseerde tests in dit proces een moeilijke en zinloze taak zijn.
Een gestructureerd proces zoals een sprint, waarin elke activiteit vooraf is gedefinieerd, geeft testers genoeg tijd om een automatiseringssuite op te zetten, uit te voeren, testrapporten te analyseren en te onderhouden.

• Afleren om elke testcase altijd uit te voeren

Je applicatie is enorm uitgebreid en je hoeft niet elke keer een enorme, geautomatiseerde suite uit te voeren. Het identificeren van rapporten en het testen van beïnvloede gebieden is meer dan genoeg. Het is van fundamenteel belang dat je testautomatiseringsraamwerk zo is ontworpen dat — testgevallen kunnen worden opgesplitst en je op elk moment alleen de noodzakelijke testgevallen kunt uitvoeren.

Testautomatisering is deterministisch. Bekende invoer = voorspelbare uitvoer.

Als je tests probeert te automatiseren die dynamisch zijn, waarbij inputs en outputs steeds variëren, stop dan en stel jezelf de vraag: Is dit nodig? Wil ik echt meer complexiteit toevoegen aan de bestaande applicatie?

Houd rekening met het complexiteitsniveau van je testautomatiseringsaanpak.

Geautomatiseerde tests zijn sneller. Je moet ook erkennen dat automatisering niet van toepassing is op nieuwe functionele tests.

Je moet nieuwere functionaliteiten handmatig testen en kijken of het mislukt.

Projecten die achterlopen op schema gebeuren wanneer unit tests niet worden geautomatiseerd en testers uiteindelijk 80% van de bugs handmatig vinden in de QA-fase, die idealiter al veel eerder hadden moeten worden opgepakt toen u het component ontwikkelde.

Dus als de tijd van testers wordt besteed aan het vinden van deze bugs, krijgt de werkelijke tijd die nodig is voor automatisering op API- en bedrijfsniveau een klap, waardoor er een stapel achterstand ontstaat voor opeenvolgende sprints.

Klinkt logisch, toch?

Als iemand die uit de eerste hand ervaring heeft met het luisteren naar klanten die hun pijnpunten opnoemen, zoals:

• Enorme achterstand in testcases
• Code bevriest niet
• Niet genoeg testdekking
• Achter het releaseschema, enz.

Sujatha’s team heeft een belangrijke rol gespeeld bij het opzetten van kwaliteitspoorten en het stroomlijnen van veel van hun STLC-activiteiten, waardoor deze kwaliteitsproblemen zijn opgelost.

Snelle tip: Moedig tests met shift-links aan en maak gebruik van SDET’s (Software Development Engineers in Test) om afhankelijkheid te verminderen en continuous delivery mogelijk te maken.

Automatiseringstools zoals Cypress, Protractor en Jasmine maken de toekomst door testers en ontwikkelaars te laten samenwerken. Dit is een welkome stap om SDETS mogelijk te maken en de muren tussen teams te laten vervagen.

Maar om echt wendbaar te zijn, moet je automatisering verder gaan dan UI-testgevallen en goed passen bij taken zoals — het automatiseren van implementaties en database-upgrades.

In de toekomst zullen er verschillende vaardigheden nodig zijn voor hyperautomatisering, maar er is een kruisbestuiving in vaardigheden. Bij Zuci geloven we zelfs dat Testautomatisering en RPA elkaar overlappen en niet totaal verschillend zijn.

Daarnaast zijn er tegenwoordig veel AI/ML-gebaseerde tools met zelfherstellende mogelijkheden en low-code/no-code-gebaseerde testtools. Als je je bewust bent van je bestaande testopstelling en wat je wilt bereiken met behulp van deze tools, kom je een heel eind in je automatiseringstraject.

Tot slot,

Bij Zuci geloven we dat automatisering een geweldig idee is. Pas de 80/20-regel toe om er een goede investering van te maken.

80% van de effecten komt voort uit 20% van de oorzaken en 80% van de resultaten komt voort uit 20% van de inspanningen.

Vind die 80 en 20 voor je testautomatisering. 100% automatisering is een mythe. Als je het doel van 100% automatisering nastreeft, zul je merken dat je weinig of geen vooruitgang boekt en dat alle inspanningen tot stof vergaan.

Automatisering identificeert geen bugs. Automatisering kan niet denken als een eindgebruiker. Het zorgt er alleen voor dat wat eerder goed werkte nog steeds goed werkt. Of beter nog, het helpt voorkomen dat er regressieproblemen opduiken.

Automatisering doet niet wat testers vroeger deden, tenzij je de meeste dingen die een tester echt doet negeert. Geautomatiseerd testen is nuttig om het bereik van het werk van de tester uit te breiden, niet om het te vervangen.- James Bach

Testers moeten de applicatie handmatig verkennen en controleren of deze faalt en wat de achterliggende reden is om dit te verhelpen.

Zoals James Bach het verwoordde,

Als testen een middel is om de kwaliteit van de software te begrijpen, dan is automatisering slechts een middel tot een middel.

Vraag voor jou:

Wat vind jij van de onderwerpen die in deze editie van Z to A Pulse aan bod komen?

Laat ons je opmerkingen of suggesties hieronder weten. Schrijf u in om toekomstige edities te ontvangen met de meest opwindende onderwerpen op het gebied van engineering excellence.

Bedankt voor het lezen!

Lees meer als je geïnteresseerd bent:

1. Testautomatisering slangenolie, door James Bach
2. De aanpak van het ’testpiramidemodel’ gebruiken