Shift-left testen verkennen
Testen in levenscyclusbeheer van toepassingen is essentieel om de kwaliteit van code te maximaliseren en het operationele risico te minimaliseren dat gepaard gaat met het implementeren en bijwerken van software. De term shift-left in deze context geeft het idee om testactiviteiten zo vroeg mogelijk in de ontwikkelingsfase te verplaatsen. De organisatie in ons voorbeeldscenario moet overwegen om deze benadering op te nemen in de DevOps-strategie om de huidige beveiligings- en stabiliteitsproblemen te minimaliseren. In deze les bekijkt u verschillende soorten tests die op deze manier kunnen worden geïmplementeerd en onderzoekt u vervolgens de implementatiemethoden.
Welke tests moeten deel uitmaken van shift-left testen?
Softwareontwikkeling omvat een breed scala aan testtypen, maar die van een bijzonder belang voor ons zijn:
Eenheidstests: Deze tests zijn gericht op de kleinste testbare onderdelen van een toepassingscode, zoals afzonderlijke functies of methoden. Het doel is om te bepalen of elke code-eenheid de beoogde bewerking kan uitvoeren in isolatie van de rest van de codebasis en externe afhankelijkheden. Dergelijke tests moeten volledig geautomatiseerd, snel (binnen 30 seconden voltooid) zijn en volledige codedekking bieden (wat in principe betekent dat alle eenheidstests gezamenlijk de volledige codebasis moeten testen). Eenheidstests zijn geschikt voor de shift-left benadering. U wordt aangeraden deze zo vroeg mogelijk toe te passen op alle code in de ontwikkelingscyclus, bij voorkeur aan het begin van de programmeerfase.
Rooktesten: Deze tests zijn bedoeld om de kernfunctionaliteit van een toepassing in een testomgeving te beoordelen. Hoewel ze de daadwerkelijke toepassing testen (in plaats van de afzonderlijke, geïsoleerde onderdelen, zoals eenheidstests doen), is het hun doel om te bepalen of de build of implementatie van de toepassing voldoende stabiel is om uitgebreidere tests te rechtvaardigen. Ze controleren de interoperabiliteit tussen apps echter niet. Net als bij eenheidstests moeten ze volledig geautomatiseerd en relatief snel zijn (gebruikersinteractie kan worden gesimuleerd met behulp van hulpprogramma's voor browserautomatisering en frameworks voor gebruikersinterfaceautomatisering). De term rooktest is bedoeld om het idee over te brengen dat rook een belangrijk probleem (brand) aangeeft dat zo snel mogelijk moet worden opgelost. Rooktesten moeten ook vroeg in de ontwikkelingscyclus worden geïmplementeerd, bij voorkeur zodra een versie van de software die de kernfunctionaliteit biedt beschikbaar is. Dit geldt zowel voor de build- als de implementatiefase van de toepassing.
Integratietests: Deze tests valideren de interactie tussen verschillende toepassingsonderdelen. In tegenstelling tot eenheidstests kunnen ze een aanzienlijke hoeveelheid tijd in beslag nemen. De verlengde duur van deze tests wordt vaak gebruikt als argument voor het uitvoeren ervan vroeg in de levenscyclus van softwareontwikkeling. Over het algemeen moet u integratietests overwegen in scenario's waarvoor eenheids- of rooktests niet geschikt zijn. De aanbeveling is echter om ze op regelmatige intervallen te plannen. Deze aanpak biedt een redelijk compromis tussen een mogelijke vertraging bij het detecteren van integratieproblemen en een extra wachttijd die nodig is om ze te voltooien.
Acceptatietests: Deze tests bepalen of een softwareproduct voldoet aan de bedrijfsvereisten en gereed is voor een levering aan de consumenten. Acceptatietests zijn niet geschikt voor de shift-left-strategie, maar het is mogelijk om enkele van de elementen vroeg in de levenscyclus van softwareontwikkeling op te nemen. Acceptatiecriteria en gebruikersverhalen, die essentiële onderdelen van acceptatietests zijn, moeten bijvoorbeeld vroeg in het ontwikkelingsproces worden geïntroduceerd. Dit vereenvoudigt de samenwerking tussen ontwikkelteams, producteigenaren en belanghebbenden van projecten. Daarnaast moeten softwaregebruikers en project belanghebbenden betrokken zijn bij de eerdere testfasen om hun feedback te delen. Dit kan betrekking hebben op het gebruik van methoden zoals alfa- of bètatests, bruikbaarheidstests of vroege releases, vóór de formele acceptatietests.