Menu

Hoe u efficiënte testautomatisering implementeert in de agile wereld

  • Hoofd
  • Agile Testen
  • Hoe u efficiënte testautomatisering implementeert in de agile wereld

how implement efficient test automation agile world

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Automatisering in Agile is erg cruciaal.

Denk eens aan de vele functies die in elke Sprint worden toegevoegd en geleverd. Er moet een manier zijn om ervoor te zorgen dat de nieuw toegevoegde functie geen invloed heeft op de bestaande functionaliteit.

Vanwege de lage Sprint-duur is het praktisch onmogelijk om de hele reeks uit te voeren elke keer dat het product wordt verhoogd aan het einde van de Sprint. Het hebben van een geautomatiseerd testpak zou hier zeker een grotere rol spelen.

Het introduceren en volwassen worden in automatisering zou echter zeker enige tijd vergen. Een eerste investering doen in het plannen en ontwerpen van de automatiseringsactiviteit zou op de lange termijn zeker vruchten afwerpen.

In dit derde deel van de geavanceerde Agile Testing-serie probeer ik een paar punten te noemen die ik kan overwegen op basis van mijn ervaring, terwijl je automatisering in je project brengt.

Lees ook deel 1 en deel 2 eerst om het onderwerp beter te begrijpen.

Wat je leert:

Wat te automatiseren in Agile?

Telkens wanneer we van plan zijn automatisering in onze projecten te introduceren, stemmen de meesten van ons onmiddellijk of de 'Smoke Tests-reeks' of de 'regressietest-reeks' de beste is. kandidaat voor automatisering ​Natuurlijk zijn ze dat, maar als we denken aan de automatiseringstestpiramide, kunnen we concluderen dat het slechts de bovenste laag van de piramide is waar we het over hebben.

Afgezien van bovenstaande laag hebben we nog steeds de servicelaag en de eenheidslaag die belangrijker zijn.

beste anime-sites om nagesynchroniseerde anime te bekijken

Welke tests, anders dan rooktesten en regressietests, kunnen goede kandidaten zijn voor automatisering?

# 1) Builds en implementaties

In traditionele omgevingen hebben we vooraf gedefinieerde builds die wekelijks, tweewekelijks of soms zelfs maandelijks kunnen zijn. Een van de redenen is dat deze implementaties tijd kosten. Het probleem met deze aanpak is dat we moeten wachten op de vooraf gedefinieerde datums om de bugs te verhelpen of om de nieuwe functies geïmplementeerd te krijgen, dus er is een vertraging.

De tweede reden was: tegen de tijd dat testers klaar zijn met testen en met bugs en defecten komen, zijn de programmeurs overgegaan op verschillende implementatiestukken en hebben ze minder interesse in het oplossen van de bugs van de oudere applicatie. Deze aanpak vertraagt ​​ook de tijd voor het beschikbaar maken van de functie in productie.

Gebouwen en implementaties zijn de entiteiten die repetitief en soms saai zijn. Het kan ook uren duren om een ​​build te implementeren, wat het testen en uiteindelijk de feedback vertraagt. Omdat het een repetitieve taak is, worden implementaties een goede kandidaat voor automatisering.

Lees ook​ Het beheerproces voor release en implementatie

ik heb geen standaardgateway

Enkele voordelen van geautomatiseerde build-implementatie zijn:

  • Geen kans op implementatiefouten (menselijke fouten zoals het kopiëren van het verkeerde bestand of het kopiëren van een bestand naar de verkeerde locatie kunnen worden vermeden)
  • Bug / functies zijn beschikbaar om te testen zodra ze zijn opgelost
  • Testers krijgen meer tijd om te testen
  • De functie is klaar om in minder tijd naar productie te worden verplaatst
  • Snelle feedback

# 2) Unit tests / Component testen

Ik heb het al gehad over het belang van het automatiseren van de eenheidslaag door de TDD-benadering in mijn laatste tutorial ​

Dit vormt de onderste laag van de piramide, daarom moet de fundering en elke fundering keihard zijn. Het ontwikkelingsteam moet samenwerken en samenwerken om het grootste deel van de test in deze laag onder te brengen.

# 3) API- / webservicetests

Webservices zijn het medium waarin twee applicaties de gegevens of informatie in termen van vraag en antwoord uitwisselen, zonder zich te bekommeren om de onderliggende architectuur of de technologie. In eenvoudigere bewoordingen: een verzoek indienen en het antwoord valideren is wat we normaal doen bij het testen van webservices.

Testen van de webservices omvat het schrijven van programma's om die webservicemethoden aan te roepen en het valideren van de waarde (n) die het retourneert. We kunnen de services zelfs testen op verschillende permutaties en combinaties. Zorg dat alle testgegevens in het Excel-blad staan ​​en uw programma kan de gegevens lezen en de testbare service bellen door de testgegevens als parameter door te geven en de resultaten te valideren.

Deze specifieke test maakt deel uit van de middelste laag van de piramide. De meeste functionele testen kunnen in deze laag worden geduwd. Het oplossen van defecten die zich in deze laag voordoen, wordt gemakkelijk op te lossen en ze worden niet uitgesteld totdat de gebruikersinterface beschikbaar is.

# 4) Testen achter de GUI

Het automatiseren van het testen achter de GUI is relatief eenvoudiger dan het automatiseren van de eigenlijke GUI. Een ander voordeel is dat ongeacht de UI-wijzigingen de functionaliteit intact blijft. Zelfs als een deel van het UI-element wordt gewijzigd, verandert de functionaliteit van de functie niet. Deze techniek richt zich voornamelijk op de bedrijfslogica en regels.

De testcases worden meestal in tabelvorm of in een spreadsheet geschreven en er worden fixtures / codefragmenten geschreven die de invoer van deze tabellen accepteren en de resultaten retourneren. De resultaten worden onmiddellijk gegenereerd en bieden een geweldig platform voor de niet-technische belanghebbenden om deze tests uit te voeren en de verwachte resultaten te krijgen. Een van de tools die worden gebruikt om deze techniek te bereiken, is Fitness ​

# 5) Niet-functionele testen

Dit niet-functionele testtechniek omvat in feite de belasting-, prestatie- en stresstests. Er zijn diverse tools op de markt die kunnen worden gebruikt om deze tests te automatiseren.

# 6) Gegevensvergelijkingen

Bij veel van onze tests moeten we gegevensbestanden vergelijken, inclusief tekstbestanden, CSV- of Excel-bestanden

  • Deze bestanden kunnen worden vergeleken met basislijnen voor gegevensvalidatie
  • Vergelijkingen kunnen van dezelfde gegevens zijn, maar van een ander formaat. Dit gebeurt in feite wanneer we twee dezelfde bestanden hebben gegenereerd vanuit twee verschillende bronnen

Deze vergelijkingen kunnen repetitief zijn en daarom geautomatiseerd.

# 7) Zoeken

Het zoeken naar een specifieke entiteit uit een grote hoeveelheid bestanden kan ook vervelend zijn en God helpt ons als dat een zich herhalende taak is. Een voorbeeld is het doorzoeken van logbestanden. Als dit ook een vervelende en repetitieve taak is, dan moeten we overwegen om het te automatiseren.

# 8) Herhaalde taken

Elke taak die begint met interactie met eindgebruikers of het schrijven van verhalen om deze te ontwikkelen, als deze repetitief is, moet in automatisering worden overwogen. We moeten begrijpen dat automatisering niet betekent dat er een geavanceerde tool / technologie bij betrokken moet zijn. Het kan een eenvoudige VB-macro zijn of een Java-programma met een Javascript om het doel op te lossen.

Waar te beginnen?

Er zijn geen bulletpoints of een stapsgewijze handleiding die aangeeft waar de automatisering moet worden gestart. Om automatisering voor het team te starten, moet je brainstormen en diepgaande gedachten toepassen op welke aspecten je wilt automatiseren, of wat is het uiteindelijke doel van de automatisering?

U kunt beginnen met:

  • Identificatie van de repetitieve taken,
  • Identificatie van de pijngebieden van de applicatie
  • Identificatie van de testuitdagingen

Als je geen automatisering hebt in het tourproject / team, dan kun je waarschijnlijk gaan voor een meerlagige aanpak waarbij de unit-tests eerst gericht kunnen worden om te automatiseren. Dit zou u de hoogste ROI opleveren.

Tegelijkertijd kunnen testers gaan werken aan een rooktestpak en vervolgens aan de regressie. Zodra het team de vaardigheden heeft verworven en zich op zijn gemak voelt, gaat u geleidelijk over op het automatiseren van de andere repetitieve taken.

Spring niet direct in het kopen van een nieuwe tool zonder uw behoeften te evalueren. Zoals ik al eerder zei, kan een eenvoudig programma of een macro het doel van het automatiseren van sommige repetitieve taken oplossen. Dus voordat u besluit een gereedschap te kopen, doe de POC en evalueer of die tool effectief zou zijn om te gebruiken.

Neem deze documenten door waar ik meer details heb gegeven over hoe u de juiste testcases voor automatisering kunt selecteren en wat inzichten over het schatten van automatiseringsinspanningen in de volgende artikelen handmatige tot automatisering testproces uitdagingen en testschatting van seleniumautomatiseringsproject.

Zodra de reikwijdte van automatisering en tool is afgerond, is de volgende stap om het raamwerk te ontwerpen.

Onthoud dat in Agile het raamwerk is geëvolueerd. Richt u NIET eerst op het ontwerpen van het volledige raamwerk en voer het vervolgens uit. Ontwerp en implementeer voor de MVP (Minimum Viable Product) en verbeter vervolgens het bestaande raamwerk om meer functies op te nemen. U moet ook goede coderings- en ontwikkelingspraktijken toepassen als u wilt dat uw automatiseringssuite robuust is.

SQL database interviewvragen en antwoorden

Enkele praktische tips

  • Richt u niet op 100% automatisering in één keer. Begin klein. Onthoud dat het een evoluerend proces is
  • Volg dezelfde Agile-praktijken die u volgt voor elke softwareontwikkeling. Automatisering vereist ook een goede planning en ontwerp. U wilt uw technische schulden niet verhogen als u automatiseert
  • Creëer uw achterstand in testautomatisering. Deze achterstand kan variëren van het implementeren van een nieuwe functie tot het verbeteren van een bestaande functie. Geef verhaalpunten aan uw geïdentificeerde items en wijs deze dienovereenkomstig toe. Breng deze backlog-items naar uw Sprint en volg deze met een Kanban-bord
  • Schrijf de acceptatiecriteria voor uw automatiseringsverhalen. Deze acceptatiecriteria kunnen zijn:
    • Integratie van de testsuite met CI
    • Het pak overbrengen naar een gecentraliseerde locatie
    • Stuur de resultaten via e-mail
    • Verstrekking van het verzenden van de foutenlogboekbestanden wanneer de test mislukt
    • Alle andere criteria….
  • Besteed niet te veel tijd aan het evalueren van een nieuwe tool. U kunt een geprioriteerde checklist maken van wat u allemaal wilt van de nieuwe tool en een tijdlijn bepalen om deze te evalueren. Als u uw resultaten niet binnen de gestelde tijd ziet, gaat u verder met de volgende
  • Maak een weloverwogen beslissing over wat u wilt automatiseren. Niet elk stukje automatisering is effectief en levert een positieve ROI op. Automatiseer niet alleen om automatisering
  • Maak gebruik van de juiste ontwikkelomgeving. Bewaar de code niet bij uw lokale. Zorg voor een repository om uw code te bewaren en maak er een gewoonte van om uw code aan het eind van de dag te controleren
  • Probeer op een vergelijkbare manier uw geautomatiseerde tests uit te voeren vanaf een centrale locatie. Maak het persoon onafhankelijk. Het zou moeten zijn dat iedereen van het team de scripts vanaf hun computer kan activeren en dat de resultaten via e-mail worden verkregen

Wat zijn Agile-principes die kunnen worden toegepast op automatisering?

Enkele zeer simpele tips:

  • Houd het simpel. Doe wat nodig is. Ik heb veel gevallen gezien waarin we implementatie met suikercoating leveren, wat de automatisering onnodig ingewikkeld maakt. Laten we de dingen vermijden die niet nodig zijn
  • Eenvoudige dingen doen, betekent niet de gemakkelijkste dingen doen. Dit betekent dat u babystapjes moet nemen om uw automatiseringsdoelen te bereiken. U kunt een eenvoudige functie gebruiken om te automatiseren, maar het kan gebeuren dat de implementatie van automatisering complex blijkt te zijn
  • Pas de hele teambenadering toe ​Ik geloof dat iedereen een tester is in een agile team. Laten we de automatiseringstaak niet beperken tot alleen de testers of alleen de ontwikkelaars. Elk van de disciplines moet in elkaars schoenen stappen om automatisering voor het project te realiseren. Deze aanpak zou ook effectief zijn om de technische problemen op te lossen die met de implementatie gepaard gaan
  • Het framework is ontwikkeld in Agile ​Probeer niet te veel functies aan te bieden die de automatisering onnodig ingewikkeld kunnen maken
  • Neem de tijd om het goed te doen. Neem de tijd om het goed te ontwerpen om de technische schulden te vermijden
  • Krijg regelmatig feedback
  • Pas de juiste coderingsnormen en praktijk toe. Het ontwerp moet eenvoudig zijn, de OOPS-concepten toepassen en proberen de tests onafhankelijk van elkaar te houden. Overweeg factoren zoals 'onderhoudbaarheid' van het testpak

Zie ik uitdagingen bij het automatiseren in Agile?

Automatisering in de Agile-wereld komt met zijn eigen uitdagingen ​

  • We moeten heel goed plannen. Om de juiste testsuite, tool, framework en aanpak te bepalen, is een goede strategie nodig. We moeten echter onthouden om NIET te veel te plannen. Houd rekening met de MVP (Minimal Viable Product)
  • Compromissen met de kwaliteit van de code omdat we snel willen leveren: we moeten niet vergeten dat technische schulden ook goed standhouden in automatisering
  • Teams volgen meestal niet de 'Whole-Team-Approach' en laten de volledige verantwoordelijkheid voor het coderen en onderhouden van de geautomatiseerde suite over aan de testers, wat de verantwoordelijkheid van de testers vergroot.
  • Het automatiseren van de functionele tests is moeilijker dan het automatiseren van de gebruikersinterface

Van al deze uitdagingen is de meest kritische uitdaging het verbeteren van de vaardigheden van testers.

Het automatiseren en onderhouden van de automatisering voor een team is bijna als een programmeer (ontwikkel) activiteit die de programmeurs (ontwikkelaars) doen. Niet alleen de implementatie, maar ook de integratie van het geautomatiseerde pak met CI is belangrijk en vereist dat testers nieuwe vaardigheden leren en toepassen en nieuwe tools en technologieën leren.

Enkele Open Source Tools die in Agile passen

  • Selenium WebDriver - Voor gebruikersinterface
  • Selenium Grid - Voor parallelle uitvoering
  • Komkommer - voor BDD
  • JMeter - Voor prestatietests
  • ZEEP - Voor webservices
  • WireMock - Testen van webservices wanneer de webservice niet beschikbaar is.
  • Tijdperken - voor mobiel

Ik wil besluiten met de bekende Agile-testkwadranten:

Agile testkwadranten

Kwadrant 1 is de eenheid en de componententest die kan worden geautomatiseerd met de TDD-benadering.

Kwadrant 2 vertelt over het testen van functionaliteit, waar we de BDD-benadering kunnen toepassen.

Kwadrant 3 is het enige kwadrant dat handmatig kan worden getest.

Kwadrant 4 spreekt in feite over het testen dat met sommige tools kan worden bereikt. Deze verzorgt de Load testen, Stress testen, Volume testen en Security testen.

Gevolgtrekking

Naast de rooktesten en regressietesten is er veel reikwijdte van automatisering. Daarom moeten we ons losmaken van het concept om automatisering alleen te beperken tot dit soort testen, wat op zijn beurt betekent dat de vaardigheid van een tester in Agile meer vereist dan alleen het vinden van bugs en defecten.

Testers moeten beter samenwerken en hun programmeer- / automatiseringsvaardigheden aanscherpen. Als steeds meer tests worden geautomatiseerd, zouden de testers meer tijd krijgen om zich bezig te houden met meer geavanceerde en uitdagende taken.

Over de auteur: Dit artikel is geschreven door STH-teamlid Shilpa. Ze werkt al meer dan 10 jaar op het gebied van softwaretests in domeinen als internetreclame, investeringsbankieren en telecom.

Deel uw opmerkingen en gedachten hieronder.

Aanbevolen literatuur

^