Hallo lezers, welkom! Dit artikel maakt deel uit van de Z to A Pulse: Report spotlight, waarin we onze gedachten publiceren over de bevindingen van gerenommeerde namen zoals: World Quality Report, Gartner, McKinsey, Forrester etc.. We analyseren hun bevindingen en trends met de hulp van onze engineering leaders en delen vervolgens de inzichten om u te helpen engineering excellence te bereiken. Abonneer u door op de knop hierboven te klikken om de volgende edities te lezen.

In het onderwerp…

De afgelopen jaren hebben we een verschuiving gezien in de manier waarop software wordt gebouwd, verfijnd en geleverd aan de gebruikers. Met de komst van DevOps bevinden engineeringteams zich nu in de voorhoede van een nieuw tijdperk, een tijdperk dat wordt gekenmerkt door een niet-aflatende drang naar automatisering en de naadloze stroom van code door continue integratie- en leveringspijplijnen (CI/CD).

We staan op een kruispunt waar continu testen niet alleen een best practice is; het is een belangrijke schakel om ervoor te zorgen dat je software niet alleen op tijd is, maar ook van onwrikbare kwaliteit.

Ga met me mee op deze spannende reis terwijl we het concept van DevOps en het belang van continu testen in de moderne softwarelevering van vandaag verkennen.

Hoi! Ik ben Keerthi V, marketingstrateeg bij Zuci Systems.

Maak kennis met onze experts:

  1. Saraswathi Jayaraman
  2. Pratapsinha Suryawanshi

Saraswathi en Pratap hebben meer dan 50.000 uur besteed aan het helpen van engineeringteams om uitzonderlijke gebruikerservaringen te realiseren binnen de dynamische context van CI/CD.

Dit is wat ze te vertellen hebben over het onderwerp.

Keerthi: Kort over de rol van continu testen in DevOps

Pratap: Het traditionele testen van software in een watervalontwikkelingsmethodologie staat bekend als een langzaam, kostbaar proces dat releases vertraagt en tegelijkertijd twijfelachtige bedrijfswaarde oplevert. Nu software de sleutel wordt tot het creëren van een concurrentievoordeel in alle markten, genieten bedrijven niet langer de luxe om te kiezen tussen ‘snelheid’ of ‘kwaliteit’ bij het leveren van software. Beide zijn cruciaal.

Nu, met de volwassenheid en acceptatie van agile en DevOps initiatieven in de bedrijven, helpt de Continuous Testing strategie bedrijven om het testen te versnellen en te prioriteren om te voldoen aan de behoeften van de snelle Agile en DevOps initiatieven. Deze nieuwe strategie helpt bedrijven slimmer te testen, zodat testen snel inzicht geven in wat het belangrijkst is voor het bedrijf.

Continu testen implementeren:

De DevOps-pijplijn is een reeks stappen die het softwareontwikkelingsproces automatiseren, van code commit tot productievrijgave. Continu testen moet worden geïntegreerd in elke fase van de pijplijn, van unit testen tot acceptatietesten.

Een belangrijke technische activiteit is het bouwen en onderhouden van een set geautomatiseerde testsuites, waaronder:

Unit Tests: Deze tests richten zich op het valideren van de functionaliteit van een enkele methode, klasse of functie in isolatie. Hun belangrijkste doel is om ontwikkelaars het vertrouwen te geven dat hun code werkt zoals bedoeld. Om ervoor te zorgen dat code testbaar is, en tests onderhoudbaar blijven, is het raadzaam om unit tests te schrijven voordat je de eigenlijke code schrijft, een methode die vaak Test-Driven Development (TDD) wordt genoemd.

Acceptatietesten: Deze tests werken op een hoger niveau en evalueren een draaiende applicatie of service. Meestal interageren ze met het geteste systeem (vaak door afhankelijkheden te vervangen door test-dubbels) om te verifiëren dat bredere functionaliteit werkt zoals verwacht en dat er geen regressiefouten zijn geïntroduceerd. Acceptatietests dienen om verschillende aspecten te valideren, zoals het voldoen aan de zakelijke acceptatiecriteria voor een user story of het garanderen van de juistheid van een API. Het is een best practice om deze tests op te nemen als integraal onderdeel van het ontwikkelproces. Sterker nog, het wordt aanbevolen dat werk pas als “ontwikkeling voltooid” wordt beschouwd als geautomatiseerde acceptatietests met succes zijn doorstaan.

Onderstaande afbeelding toont de soorten geautomatiseerde en handmatige tests die moeten worden uitgevoerd.

Als je een fout tegenkomt in een acceptatietest of tijdens verkennende tests, is een proactieve aanpak om je tests uit te breiden met een unit test. Deze extra eenheidstest dient als een kritisch vangnet dat ervoor zorgt dat dezelfde fout sneller, in een eerder stadium en met lagere kosten in toekomstige testcycli wordt gedetecteerd.

Deze aanpak komt overeen met Mike Cohn’s concept van de ideale testautomatiseringspiramide, zoals geïllustreerd in onderstaand diagram.

Je bent misschien geïnteresseerd in:

Testautomatisering Enigma: Zuci View

Het continu uitvoeren van tests als onderdeel van een pijplijn draagt bij aan snelle feedback voor ontwikkelaars, een korte doorlooptijd van check-in tot release en een lage foutmarge in productieomgevingen. Ontwikkelaars hebben het grootste deel van hun werk gevalideerd in een kwestie van minuten, in plaats van dagen of weken, zodat ze bugs zo snel mogelijk kunnen oplossen.

Het volgende diagram toont een voorbeeld van een eenvoudige lineaire deployment pijplijn. In dit voorbeeld betekent groen dat er geen problemen zijn gevonden en rood dat er een of meer problemen zijn ontdekt.

Het continu uitvoeren van tests als onderdeel van een pijplijn draagt bij aan snelle feedback voor ontwikkelaars, een korte doorlooptijd van check-in tot release en een lage foutmarge in productieomgevingen. Ontwikkelaars hebben het grootste deel van hun werk gevalideerd in een kwestie van minuten, in plaats van dagen of weken, zodat ze bugs zo snel mogelijk kunnen oplossen.

Het volgende diagram toont een voorbeeld van een eenvoudige lineaire deployment pijplijn. In dit voorbeeld betekent groen dat er geen problemen zijn gevonden en rood dat er een of meer problemen zijn ontdekt.

Manieren om geautomatiseerd testen te meten:

Je kunt de resultaten van geautomatiseerd testen in je omgeving meten door het volgende te doen:

Keerthi: Zou je je gedachten over elk van de onderstaande modellen willen delen? Dit zijn modellen om continu testen mogelijk te maken.

Pratap:

Continu testen wordt veel gebruikt en is effectief in de volgende ontwikkelingsmodellen

  1. Agile: Continu testen is een integraal onderdeel van Agile, waarbij het product in kleine stappen wordt opgebouwd met regelmatige feedback en tests. Continu testen helpt het productontwikkelingsteam bij het sneller en beter bouwen van het product, met minder fouten.
  1. DevOps: Continu testen wordt automatisch uitgevoerd tijdens de levenscyclus van softwareontwikkeling (SDLC). Continu testen gaat hand in hand met continue integratie om automatisch alle nieuwe code te valideren die in de applicatie wordt geïntegreerd.
  1. CTDD: Continue testgestuurde ontwikkeling (CTDD) biedt de voordelen van testgestuurde ontwikkeling en maakt het mogelijk om tests automatisch uit te voeren, waardoor testers continu feedback krijgen over of hun code werkt.

Keerthi: Deel je gedachten over het onderstaande.

In het verslag over doorlopende tests in 2020 staat dat

Testomgevingen zijn een van de grootste belemmeringen voor continu testen en Agile levering: 36% van de respondenten gaf aan meer dan 50% van hun tijd te besteden aan het beheren ervan.

Uit het onderzoek blijkt ook dat de mogelijkheid om omgevingen dynamisch op te zetten essentieel zal zijn, waarbij individuele componenten naar behoefte kunnen worden gewijzigd en gecombineerd. Infrastructuur zoals code practices (IaC), containerisatie, cloud provisioning en servicevirtualisatie zullen daarbij een belangrijke rol spelen.

Saraswathi:

De evolutie van het gebruik van cloudinfrastructuur is interessant.

In de begindagen was het eenvoudig – een enkele virtuele machine die toegankelijk was via SSH. Maar toen kwam de tweede golf met containers en provisioning tools zoals Dockers. Toen werd Infrastructuur dynamischer.

Vandaag de dag heeft de moderne cloudinfrastructuur lagen van complexiteit toegevoegd. Het gaat niet meer alleen om containers; het gaat om serverless computing en een reeks beheerde services, allemaal verweven in applicatiearchitecturen.

Daar komt Infrastructure as Code (IaC) om de hoek kijken. Met IaC kunnen we de gewenste toestand van onze infrastructuur definiëren, waardoor deze flexibeler wordt en zich beter kan aanpassen.

Bovendien is IaC een katalysator voor de DevOps-cultuur. Het verwijdert de grenzen tussen ontwikkeling en uitvoering en bevordert een sterkere samenwerking. Ik denk dat we de komende jaren een toename zullen zien in het gebruik van IaC, waarbij veel DevOps-teams het als standaardpraktijk zullen beschouwen.

Een typische IaC ziet er als volgt uit:

  • Ontwikkelaars beginnen met het definiëren en schrijven van de infrastructuurcode.
  • De code wordt vervolgens vastgelegd in een versiebeheersysteem, vaak met behulp van platforms zoals GitHub.
  • Het ondergaat pull requests en peer reviews om uiteindelijk te eindigen in een release branch.
  • Vervolgens neemt de IaC-tool de controle over en orkestreert de implementatie van de infrastructuur in de cloud of on-premise omgevingen.

Het is net als het coderen van je infrastructuur, waarbij je ervoor zorgt dat alles, van servers tot netwerken, consistent en nauwkeurig wordt ingesteld. Dit betekent dat u uw omgevingen in enkele minuten kunt repliceren en geen uren meer kwijt bent aan handmatige configuraties.

Containerisatie — pakketjes van applicaties samen met hun afhankelijkheden, waardoor ze draagbaar worden. Teams kunnen dezelfde container draaien op de ontwikkellaptop, staging server en productieomgeving, waardoor er minder kans is op omgevingsspecifieke bugs.

Net als het belang van het direct beschikbaar hebben van testgegevens, spelen virtuele services een cruciale rol in effectief testomgevingbeheer en de shift-linkse benadering om continu testen te bereiken. Servicevirtualisatie bootst het gedrag van externe systemen na, zelfs als ze niet beschikbaar zijn. Hierdoor blijft het testen doorgaan, zelfs wanneer externe afhankelijkheden niet beschikbaar zijn voor onderhoud of andere redenen. Het voordeel van deze aanpak is dat elk team toegang heeft tot elke service op een gevirtualiseerde basis en ermee kan testen. Het is snel, het is nauwkeurig en het reageert alsof het echt is, wat betekent dat teams parallel kunnen testen.

Competentie in deze praktijken helpt bij het opzetten en beheren van testomgevingen. Het bespaart tijd en laat teams zich concentreren op wat echt belangrijk is: sneller software van hoge kwaliteit leveren. Het gaat om het optimaliseren van het proces en het omarmen van wendbaarheid, waar continu testen om draait.

Onderzoek en evaluatie van DevOps (DORA) over het implementeren van flexibele infrastructuur:

Keerthi: Het rapport State of DevOps vertelt dat

Continue levering en versiebeheer versterken elkaars vermogen om hoge prestatieniveaus van softwarelevering te bevorderen.

Bovendien hebben de teams die zich richten op de volgende praktijken vaak meer geavanceerde DevOps-processen.

Losjes gekoppelde architectuur- de mate waarin teams grootschalige wijzigingen kunnen aanbrengen in het ontwerp van hun systeem zonder afhankelijk te zijn van andere teams om wijzigingen in hun systemen aan te brengen.

Versiebeheer – hoe wijzigingen in applicatiecode, systeemconfiguratie, applicatieconfiguratie, etc. worden beheerd.

Continue integratie – hoe vaak takken worden geïntegreerd in de basislijn.

Continue levering – mogelijkheden gericht op het veilig, duurzaam en efficiënt in productie nemen van wijzigingen.

Samen met continu testen bevorderen deze praktijken de prestaties van software die groter zijn dan de som van de delen.

Kunt u kort uw gedachten over deze praktijken delen?

Saraswathi:

Veel organisaties investeren veel tijd en moeite in de adoptie van technologie, maar hebben moeite om de gewenste resultaten te behalen als gevolg van beperkingen in de architectuur.

In een nauw gekoppelde architectuur kunnen zelfs kleine aanpassingen wijdverspreide, onderling verbonden storingen veroorzaken. Dit vereist constante coördinatie tussen verschillende teams binnen het systeem, waarbij vaak ingewikkelde en bureaucratische veranderingsmanagementprocedures moeten worden doorlopen.

Aan de andere kant, als de architectuur van het systeem ontworpen is om teams in staat te stellen zelfstandig systemen te testen, in te zetten en aan te passen zonder afhankelijk te zijn van andere teams, wordt communicatie minimaal. In essentie zijn zowel de architectuur als de teams losjes gekoppeld.

Succesvolle continue integratie ligt in het hebben van: Geautomatiseerd bouwproces dat pakketten met versieherhaling maakt voor implementatie, waarbij het proces dagelijks wordt uitgevoerd.

Geautomatiseerde testsuites: Begin met betrouwbare unit- en acceptatietests, breid de dekking uit voor nieuwe functies en zorg voor dagelijkse feedback aan ontwikkelaars.

CI/CD is zowel continue integratie als continue levering gecombineerd. Om ervoor te zorgen dat uw softwarereleases betrouwbaar en veilig zijn, is het cruciaal dat iedereen die bij het proces betrokken is, niet alleen de ontwikkelaars, nauw samenwerkt. En je team moet openstaan voor nieuwe manieren om dingen te doen en nieuwe vaardigheden te verwerven.

Belangrijkste opmerkingen:

Strategieën om continu testen te implementeren in DevOps:

  • Automatisering omarmen: Bouw je strategie op testautomatisering voor sneller en consistenter testen.
  • Shift-links testen: Begin vroeg in de ontwikkeling met testen om problemen eerder op te sporen. Nieuwe automatiseringsmethodologieën zullen zich blijven ontwikkelen in shift-links, waaronder modelgebaseerd testen, BDD, TDD en in-sprint beveiligingstesten.
  • Gegevensbeheer: Zorg voor uitgebreid beheer van testgegevens voor effectief testen.
  • Servicevirtualisatie: Simuleer niet-beschikbare componenten voor grondiger testen.
  • Continue bewaking: Houd testresultaten en defecten nauwlettend in de gaten voor realtime feedback.
  • Parallelle uitvoering: Voer meerdere tests tegelijk uit om tijd te besparen.
  • CI/CD-integratie: Integreer testen in uw CI/CD-pijplijnen voor naadloze automatisering.
  • Beheer van testomgevingen: Efficiënt testomgevingen beheren om vertragingen te voorkomen. De mogelijkheid om omgevingen dynamisch op te starten is essentieel. Daarom zullen infrastructuren zoals code practices, containerisatie en virtualisatie een belangrijke rol spelen.
  • Samenwerking en communicatie: Stimuleer teamwerk om problemen sneller op te lossen.
  • Voortdurende verbetering: Verfijn je strategie regelmatig voor voortdurend succes.

Vraag voor jou:

Hoever ben jij met continu testen?

  • Beginner
  • Intermediair
  • Expert

Bedankt voor het lezen! We kijken er naar uit om in onze toekomstige edities dieper in te gaan op de inzichten uit het World Quality Report.

Als je onze inhoud leuk vindt, laat ons dan je steun zien door – je hier in te schrijven voor onze driemaandelijkse nieuwsbrief, Sound bytes. en door dit artikel met je team te delen. Uw steun betekent de wereld voor ons!