Is DevOps een testmethode?

Traditionele ontwikkelaars zien DevOps vaak als een testmethode. Dit is ook ingegeven door het DevOps Laminiscaat waarin opvalt dat Test vóór Code wordt uitgevoerd. Bovendien ligt er binnen een sterke nadruk op continue integratie en continue levering (CI/CD), wat nauw verbonden is met uitgebreide en geautomatiseerde testprocessen. Echter, DevOps is in werkelijkheid een bredere cultuur en methodologie die veel verder gaat dan alleen testen.

Waarom veel mensen denken dat DevOps een testmethode is?

Hier zijn enkele redenen waarom DevOps vaak als testmethode wordt gezien:

1. Focus op CI/CD: Continue Integratie (CI): Dit houdt in dat codewijzigingen regelmatig worden geïntegreerd in een gedeelde repository, daarna gevolgd door geautomatiseerde builds en tests. Het doel is om snel fouten te identificeren en op te lossen.
2. Automatisering van Testen: DevOps legt een sterke nadruk op het automatiseren van tests om snel feedback te krijgen over de kwaliteit van de code. Geautomatiseerde tests zorgen ervoor dat elke wijziging in de code direct wordt gevalideerd. Dit omvat unittests, integratietests, systeemtests, en regressietests.
3. Kwaliteitsborging: Een belangrijk doel van DevOps is om de kwaliteit van software te waarborgen door middel van continue en grondige tests. Dit wordt vaak als een centraal aspect van de DevOps-praktijken gezien.

Waarom zie ik in het Lemniscaat eerst testen en daarna programmeren?

In DevOps-processen wordt er veel nadruk gelegd op testen voor het programmeren (Test-Driven Development, TDD). Hier zijn enkele redenen waarom we deze testaanpak hanteren:

1. Kwaliteit Verhogen

Door eerst tests te schrijven, dwingt men zichzelf na te denken over de gewenste functionaliteit en de criteria waaraan de code moet voldoen. Dit zorgt voor duidelijkere specificaties en helpt bovendien om fouten vroegtijdig op te sporen.

2. Feedback Loop Verkorten

De testmethode biedt directe feedback over de werking van de code. Wanneer tests zijn opgesteld voordat de code wordt geschreven, kan elke wijziging snel worden gevalideerd, waardoor ontwikkelaars onmiddellijk weten of ze aan de eisen voldoen of niet.

3. Vertrouwen en Veiligheid

Door eerst tests te schrijven, creëren ontwikkelaars een veiligheidsnet. Dit maakt het veiliger om later wijzigingen aan te brengen in de code, omdat de tests kunnen bevestigen dat bestaande functionaliteit niet wordt aangetast.

4. Betere Structuur

De testmethode kan helpen om de code beter gestructureerd en modulair te houden. Omdat ontwikkelaars moeten nadenken over hoe hun code te testen, worden ze aangemoedigd om losse, herbruikbare en goed gedefinieerde modules te maken.

5. Documentatie

Tests dienen als een vorm van documentatie die duidelijk maakt wat de code zou moeten doen. Dit is ook bijzonder nuttig voor nieuwe teamleden die de code moeten begrijpen en aanpassen.

6. Snellere Debugging

Wanneer er iets misgaat, helpen de tests bij het isoleren van het probleem. Omdat er tests zijn voor specifieke functionaliteiten, kan men snel vaststellen waar de bug zich bevindt.

7. Consistentie in de Werkwijze

Test-driven development dwingt tot een systematische aanpak, wat vervolgens leidt tot consistentere en beter doordachte code.

8. Klantenvereisten Valideren

Door eerst tests te schrijven, kunnen ontwikkelaars en klanten overeenstemming bereiken over de vereisten en hoe succes eruitziet. Dit helpt misverstanden en verkeerde interpretaties te voorkomen.

Door deze voordelen is het in de DevOps-praktijk gebruikelijk om eerst te testen en daarna te programmeren, wat bijdraagt aan een efficiënter en betrouwbaarder ontwikkelproces.

Hoe kunnen we testen voordat we een programma hebben?

Testen voordat je een programma hebt, wordt dus mogelijk gemaakt door een strategie genaamd Test-Driven Development (TDD). In TDD schrijf je eerst tests voor de functionaliteit die je wilt implementeren voordat je de daadwerkelijke code schrijft. Hier is hoe dat in zijn werk gaat:

Stappen in Test-Driven Development (TDD)

1 Schrijf een Faaltest (Red):
Doel: Definieer een test voor een specifieke functionaliteit die je wilt toevoegen.
Details: Deze test zal natuurlijk falen omdat de functionaliteit nog niet bestaat.
Voorbeeld: Stel dat je een functie wilt schrijven die de som van twee getallen teruggeeft. Je begint met het schrijven van een test die controleert of sum(2, 3) gelijk is aan 5.

python
def test_sum():
    assert sum(2, 3) == 5

2 Schrijf de Minimale Code om de Test te Laten Slagen (Green):
Doel: Schrijf net genoeg code om de test te laten slagen.
Details: De focus ligt op het implementeren van de functionaliteit op de meest eenvoudige en directe manier.
Voorbeeld: Implementeer de sum functie zodat de test slaagt.

python
def sum(a, b):
    return a + b

3 Refactor de Code (Refactor):
Doel: Verbeter de code zonder dat de functionaliteit verandert.
Details: Optimaliseer de code, verbeter leesbaarheid, en verwijder duplicaten, terwijl je ervoor zorgt dat alle tests blijven slagen.
Voorbeeld: Controleer of er manieren zijn om de sum functie efficiënter of duidelijker te maken, zonder de werking te veranderen.

Voordelen van deze testmethode

1. Duidelijke Specificaties: De tests vormen een duidelijke specificatie van wat de code moet doen.
2. Onmiddellijke Feedback: Je weet direct of je wijzigingen de gewenste functionaliteit bieden.
3. Iteratieve Verbetering: Elke cyclus van falen, slagen en refactoren leidt tot stapsgewijze verbeteringen in de code.

Praktisch voorbeeld van deze testmethode

Laten we een voorbeeld uitwerken waarin we een functie willen implementeren die controleert of een getal even is:

1 Schrijf een Faaltest:

python
def test_is_even():
    assert is_even(4) == True
    assert is_even(3) == False

Deze test controleert of de is_even functie correct werkt voor zowel even als oneven getallen.

2 Schrijf de Minimale Code:

python
def is_even(n):
    return n % 2 == 0

Dit zorgt ervoor dat de tests slagen.

3 Refactor de Code:

In dit geval is de implementatie al behoorlijk efficiënt en duidelijk, dus er is mogelijk geen refactoring nodig.

Hoewel het tegenintuïtief lijkt, helpt het schrijven van tests voordat we de daadwerkelijke code implementeren om beter na te denken over de gewenste functionaliteit en robuustere, beter geteste software te ontwikkelen. Het proces van TDD zorgt ervoor dat we continu testbare en werkende code hebben, wat leidt tot hogere codekwaliteit en betrouwbaarheid.

Na oplevering checken of het programma echt werk

Na de oplevering van een programma is het inderdaad cruciaal om te controleren of het programma echt werkt. Dit bereiken we door verschillende niveaus en soorten testen uit te voeren. Test-Driven Development (TDD) is een belangrijk onderdeel van dit proces, maar het is slechts een deel van de totale testmethode. Hier is een overzicht van de teststappen die typisch worden gevolgd, zowel vóór als na de oplevering:

1. Unit Testing

• Wat: Testen van individuele functies.
• Wanneer: Tijdens het ontwikkelingsproces, vooral bij het gebruik van TDD.
• Doel: Zekerstellen dat elke afzonderlijke eenheid code correct werkt.

2. Integration Testing

• Wat: Testen van het samenspel tussen verschillende modules of componenten.
• Wanneer: Nadat de individuele units zijn getest en geïntegreerd.
• Doel: Verifiëren dat de gecombineerde onderdelen samenwerken zoals bedoeld.

3. System Testing

• Wat: Testen van het volledige systeem als een geheel.
• Wanneer: Nadat alle onderdelen zijn geïntegreerd.
• Doel: Zorgen dat het hele systeem voldoet aan de vereisten.

4. Acceptance Testing

• Wat: Testen door de eindgebruiker of klant om te verifiëren dat het systeem voldoet aan hun verwachtingen en eisen.
• Wanneer: Voor de uiteindelijke oplevering aan de klant.
• Doel: Formele goedkeuring verkrijgen van de klant.

5. Regression Testing

• Wat: Testen om te verzekeren dat nieuwe codewijzigingen geen bestaande functionaliteit breken.
• Wanneer: Na elke codewijziging, vooral bij bugfixes en nieuwe features.
• Doel: Continu waarborgen dat het systeem stabiel blijft.

6. Performance Testing

• Wat: Testen van de snelheid, schaalbaarheid en stabiliteit van het systeem onder belasting.
• Wanneer: Voor en na de oplevering, vooral bij systemen met hoge prestatie-eisen.
• Doel: Zekerstellen dat het systeem presteert binnen acceptabele limieten.

7. Security Testing

• Wat: Testen op beveiligingskwetsbaarheden.
• Wanneer: Doorlopend tijdens en na de ontwikkeling.
• Doel: Zorgen dat het systeem veilig is tegen aanvallen.

8. User Acceptance Testing (UAT)

• Wat: Eindgebruikers testen het systeem in een omgeving die de productie nabootst.
• Wanneer: Voor de productie-oplevering.
• Doel: Bevestigen dat het systeem klaar is voor productiegebruik.

9. Post-Deployment Testing

• Wat: Testen in de productieomgeving na de oplevering.
• Wanneer: Na de implementatie in de productie.
• Doel: Zekerstellen dat het systeem correct werkt in de live-omgeving en dat er geen problemen zijn ontstaan tijdens de implementatie.

Samenvatting oplevering testen

Na de oplevering moeten de volgende stappen worden genomen om te bevestigen dat het programma echt werkt:

• Uitvoeren van acceptatietests: Verifiëren dat het systeem voldoet aan de specificaties en eisen.
• Regressietesten: Controleren dat nieuwe wijzigingen geen bestaande functionaliteit breken.
• Gebruikersacceptatietesten (UAT): Laten testen door eindgebruikers om ervoor te zorgen dat het systeem voldoet aan hun verwachtingen.
• Post-deploymenttesten: Controle in de productieomgeving om te bevestigen dat alles naar behoren werkt.

Door deze uitgebreide testaanpak staat vast dat het programma niet alleen technisch correct is, maar ook voldoet aan de eisen en verwachtingen van de eindgebruikers en stabiel functioneert in de productieomgeving.

Waarom DevOps meer is dan alleen een testmethode

1. Cultuur en Samenwerking: DevOps is in de kern een cultuur die samenwerking en communicatie tussen ontwikkelings- en operationele teams bevordert. Het gaat om het doorbreken van de traditionele silo’s tussen deze teams om efficiënter en effectiever software te ontwikkelen, leveren en onderhouden.
2. Automatisering van het Hele Softwareproces: Naast het automatiseren van tests, automatiseert DevOps ook de build-, release- en deploymentprocessen. Dit omvat tools voor infrastructuur als code, configuratiebeheer, monitoring en meer.
3. Snellere Levering van Software: DevOps streeft naar snellere en frequentere leveringen van software door de processen te stroomlijnen en te automatiseren. Dit resulteert in snellere feedbackcycli, waardoor teams sneller kunnen reageren op veranderingen en problemen.
4. Continu Verbetering: DevOps is een iteratief proces van continue verbetering. Het omvat het continu monitoren van prestaties en het verzamelen van feedback om de processen en de software voortdurend te verbeteren.
5. Infrastructuurbeheer: DevOps omvat ook het beheer en de automatisering van infrastructuur. Door gebruik te maken van infrastructuur als code (IaC) kunnen teams snel en betrouwbaar omgevingen opzetten en beheren.
6. Security (DevSecOps): Veiligheid is een integraal onderdeel van DevOps-praktijken, met een verschuiving naar DevSecOps waarbij we beveiliging integreren in elke fase van de ontwikkelings- en operationele processen.

Conclusie DevOps als testmethode

Hoewel testen een cruciaal en zichtbaar onderdeel is van DevOps, is het slechts één aspect van een bredere methodologie die de hele levenscyclus van softwareontwikkeling en -levering omvat. DevOps richt zich op samenwerking, automatisering, continue verbetering, infrastructuurbeheer, en integratie van beveiliging, wat het een uitgebreide ontwikkelings- en operationele benadering maakt.

Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn.