Levenscyclus van softwaretesten: fasen, hulpmiddelen & beste praktijken

De zes fasen zijn:

1. Analyse van vereisten
2. Testplanning
3. Ontwikkeling van testgevallen
4. Configuratie van de testomgeving
5. Testuitvoering
6. Testafsluiting

Je kunt deze zes fasen gebruiken voor het testen van een nieuwe functie, een volledige release of een hotfix. Dezelfde gestructureerde aanpak is elke keer van toepassing.

Waarom de STLC belangrijk is: 5 belangrijkste voordelen

De STLC is belangrijk omdat deze helpt defecten eerder op te sporen, wat rechtstreeks van invloed is op de kosten. Een algemene vuistregel is dat bugs exponentieel duurder zijn om in productie te herstellen dan tijdens het testen.

Dit biedt een duidelijke STLC je team:

• Vroege detectie van defecten: Door vereisten te beoordelen voordat je een testcase schrijft, komen onduidelijkheden aan het licht voordat ze dure bugs worden.
• Voorspelbare testdekking: Een vastgelegd proces zorgt ervoor dat er niets tussen sprints of overdrachtsmomenten door de mazen van het net glipt.
• Gestandaardiseerde documentatie: Elke fase levert artefacten op (bijv. testplannen, testgevallen en defectlogboeken) die een audittrail creëren en naleving ondersteunen.
• Duidelijke verantwoordelijkheid: Wanneer elke fase vastgelegde rollen en eindcriteria heeft, wordt het gemakkelijker om de voortgang te meten en knelpunten te identificeren.
• Lagere totale kosten: Gestructureerd testen vermindert herstelwerk, ongeplande hotfixes en de operationele gevolgen van defecten in productie.

Ik heb gemerkt dat teams die formele STLC-fasen overslaan geen tijd besparen. Ze besteden die tijd later aan incidentrespons en noodpatches.

Levenscyclus van softwaretesten versus levenscyclus van softwareontwikkeling

De SDLC omvat het volledige proces voor softwarelevering, van vereisten via ontwerp, ontwikkeling, testen, implementatie en onderhoud. De STLC maakt deel uit van de SDLC en omvat alleen testactiviteiten.

Gebruik deze tabel om de twee te vergelijken:

Dimensie	SDLC	STLC
Bereik	Volledige softwarelevering	Alleen testactiviteiten
Focus	Software bouwen en leveren	Kwaliteit verifiëren en defecten opsporen
Primair team	Ontwikkelaars, productmanagers, architecten	QA-testengineers, testleiders, testmanagers
Op te leveren resultaten	Werkende software, architectuurdocumentatie, releaseversies	Testplannen, testgevallen, defectrapporten, testrapporten
Doel	Het product opleveren	Valideren dat het product aan de vereisten voldoet

Rollen en verantwoordelijkheden binnen de STLC

Elke STLC-fase is afhankelijk van specifieke mensen die specifiek werk uitvoeren. Dit is wie waarvoor verantwoordelijk is:

• Testmanager: Bepaalt de algehele teststrategie, beheert budgetten en planningen en rapporteert de kwaliteitsstatus aan belanghebbenden. Is eigenaar van het testplan.
• Testleider: Coördineert de dagelijkse testactiviteiten, wijst werk toe aan het team en bewaakt de voortgang ten opzichte van de exitcriteria.
• QA-engineer: Schrijft en voert testgevallen uit, registreert defecten en voert regressietests uit. De ruggengraat van de uitvoeringsfase.
• Automatiseringsengineer: Ontwerpt en onderhoudt geautomatiseerde testscripts. Is eigenaar van het automatiseringsraamwerk en de CI/CD-integratie.
• Bedrijfsanalist: Ondersteunt de analyse van vereisten door acceptatiecriteria te verduidelijken en onduidelijkheden in gebruikersverhalen op te lossen.
• Ontwikkelaar: Verhelpt gemelde defecten en neemt deel aan unit-tests. Bij shift-left-testen worden ontwikkelaars eerder betrokken bij het ontwerpen van tests.

In kleinere teams vervult één persoon vaak meerdere rollen. Een QA-engineer kan ook de automatisering verzorgen en de testleider kan tevens als testmanager optreden. Dat is prima; zorg er wel voor dat elke verantwoordelijkheid expliciet wordt toegewezen in plaats van als vanzelfsprekend te worden beschouwd.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

De 6 fasen van de levenscyclus van softwaretesten

1. Analyse van vereisten

De analyse van vereisten is het punt waarop het testen begint, voordat er ook maar één testgeval is geschreven. Je team beoordeelt functionele en niet-functionele vereisten om te begrijpen wat het systeem moet doen en om alles te identificeren wat onduidelijk of niet testbaar is.

Belangrijke activiteiten in deze fase:

• Vereisten beoordelen: Analyseer documenten met bedrijfsvereisten, gebruikersverhalen en acceptatiecriteria.
• Testbare vereisten identificeren: Markeer alles waaraan een meetbaar, verifieerbaar resultaat ontbreekt.
• De testscope bepalen: Bepaal wat in deze cyclus wel en niet wordt getest.
• Risico's vroeg signaleren: Breng vereisten aan het licht die dubbelzinnig, tegenstrijdig of technisch risicovol zijn.
• Openstaande vragen documenteren: Stuur onopgeloste onduidelijkheden naar de bedrijfsanalist of producteigenaar om ze te laten oplossen.

Het belangrijkste op te leveren resultaat hier is een traceerbaarheidsmatrix voor vereisten (RTM). Deze koppelt elke vereiste aan de testgevallen waarmee deze wordt geverifieerd.

Startcriteria: Goedgekeurde documenten met vereisten zijn beschikbaar.
Eindcriteria: Alle testbare vereisten zijn geïdentificeerd; de RTM is opgesteld; onduidelijkheden zijn geregistreerd en ter oplossing doorgestuurd.

2. Testplanning

Testplanning bepaalt hoe het testen wordt uitgevoerd. De testleider of testmanager stelt het testplan op. Dit document legt de scope, aanpak, middelen, planning en het risicoregister voor de testinspanning vast.

Een gedegen testplan omvat:

• Testdoelstellingen: Wat je verifieert en waarom.
• Testtypen: Functioneel testen, regressietesten, prestatietesten, beveiligingstesten enzovoort (afhankelijk van wat van toepassing is op de release).
• Middelenplan: Wie wat doet en wanneer.
• Planning: Mijlpalen, testvensters en overdrachtsdata.
• Risico en beperking: Wat het testen kan blokkeren en de noodmaatregel voor elk risico.
• Start- en eindcriteria: De voorwaarden die elke fase sturen.
• Hulpmiddelen: Hulpmiddelen voor testbeheer, automatisering en defectregistratie die het team zal gebruiken.

Beschouw het testplan als een levend document. In agile teams wordt het elke sprint bijgewerkt in plaats van één keer geschreven en daarna vergeten.

Startcriteria: Vereisten zijn geanalyseerd; RTM is beschikbaar.
Eindcriteria: Het testplan is door belanghebbenden beoordeeld en goedgekeurd.

3. Ontwikkeling van testgevallen

Bij de ontwikkeling van testgevallen schrijven, beoordelen en leggen QA-engineers de daadwerkelijke tests vast. Elk testgeval wordt gekoppeld aan een specifieke vereiste in de RTM. Samen moeten ze de volledige scope dekken die in het testplan is afgesproken.

Elk testgeval moet het volgende bevatten:

• Testcase-ID en naam
• Precondities: De toestand waarin het systeem zich vóór de uitvoering moet bevinden.
• Teststappen: Genummerde, duidelijke en herhaalbare acties.
• Verwacht resultaat: De exacte uitvoer of het exacte gedrag dat u valideert.
• Werkelijk resultaat: Wordt tijdens de uitvoering ingevuld.
• Geslaagd/mislukt-status

Deze fase levert ook testgegevens op. Dit zijn de daadwerkelijke invoergegevens die uw team tijdens de uitvoering gebruikt. Het is belangrijk om testgegevens correct in te richten, want slechte testgegevens leiden tot misleidende resultaten.

Toelatingscriteria: Goedgekeurd testplan; definitieve RTM.
Uittredingscriteria: Testgevallen beoordeeld en goedgekeurd; testgegevens voorbereid en gevalideerd.

4. Testomgeving instellen

De testomgeving is de infrastructuur waarop uw team tests uitvoert. Deze omvat servers, databases, besturingssystemen, browsers, netwerkconfiguraties en alle integraties waarvan de applicatie afhankelijk is.

Deze fase heeft twee doelen: de omgeving gereedmaken en controleren of deze stabiel is voordat de uitvoering begint.

Veelvoorkomende activiteiten zijn:

• Infrastructuur inrichten: Servers, containers of cloudomgevingen instellen die de productieomgeving nabootsen.
• De build installeren: De build die wordt getest in de omgeving implementeren.
• Smoke-test van de omgeving uitvoeren: Een snelle controle uitvoeren om te bevestigen dat de inrichting werkt voordat de volledige testuitvoering begint.
• Gegevens instellen: De omgeving vullen met testgegevens.

Problemen met de omgeving zijn een van de meest voorkomende oorzaken van testvertragingen. Ik zou het uitvoeren van een smoke-test van de omgeving als een harde toegangspoort beschouwen voordat de uitvoering begint. Als de omgeving niet stabiel is, zijn uw testresultaten niet betekenisvol.

Toelatingscriteria: Testgevallen definitief; omgevingsspecificaties gedefinieerd.
Uittredingscriteria: Omgeving stabiel; smoke-test geslaagd.

5. Testuitvoering

Bij de testuitvoering voert uw team de testgevallen uit en legt het de resultaten vast. Voor elk testgeval dat mislukt, registreert de QA-engineer een defect en wijst dit toe aan het ontwikkelingsteam voor herstel.

De uitvoeringscyclus verloopt doorgaans als volgt:

1. Voer testgevallen uit op de build.
2. Leg de resultaten geslaagd/mislukt vast in uw testbeheertool.
3. Rapporteer defecten met stappen om ze te reproduceren, de ernst en ondersteunend bewijs.
4. Het ontwikkelingsteam onderzoekt en herstelt het defect.
5. QA test herstelde defecten opnieuw.
6. Voer regressietests uit om te bevestigen dat oplossingen bestaande functionaliteit niet hebben beschadigd.
7. Herhaal dit totdat aan de uittredingscriteria is voldaan.

Het bijhouden van de defectstatus is net zo belangrijk als het bijhouden van de voortgang van de uitvoering. Een achterstand van onopgeloste defecten met een hoge ernst geeft aan dat de release niet gereed is, zelfs als het uitvoeringspercentage hoog lijkt.

Toelatingscriteria: Omgeving stabiel; testgevallen goedgekeurd; build geïmplementeerd.
Uittredingscriteria: Alle geplande testgevallen uitgevoerd; defecten boven de overeengekomen ernst opgelost en opnieuw getest; aan de metrische uittredingscriteria voldaan.

6. Testafsluiting

Met de testafsluiting wordt de testcyclus afgerond en worden de artefacten opgeleverd die uw team nodig heeft voor overdracht, naleving en verbetering. Onder tijdsdruk wordt deze stap vaak afgeraffeld of overgeslagen, en dat is een vergissing.

Belangrijke activiteiten:

• Uittredingscriteria evalueren: Bevestigen dat aan alle uittredingsvoorwaarden uit het testplan is voldaan.
• Het testrapport schrijven: Resultaten, defectmetingen, bereikte dekking en resterende risico's documenteren.
• Testmiddelen archiveren: Testgevallen, testgegevens en defectlogboeken opslaan in een gedeelde opslagplaats voor toekomstig gebruik.
• Een retrospectieve uitvoeren: Vaststellen wat goed werkte, wat niet werkte en wat in de volgende cyclus moet worden verbeterd.

Het testrapport is hier het belangrijkste opleveringsdocument. Belanghebbenden gebruiken het om te beslissen of een release wel of niet doorgaat. Schrijf het duidelijk en zorg ervoor dat het openstaande risico's behandelt, niet alleen slagingspercentages.

Toelatingscriteria: Testuitvoering voltooid; defecten opgelost of uitgesteld met gedocumenteerde onderbouwing.
Uittredingscriteria: Testrapport goedgekeurd; testartefacten gearchiveerd.

Essentiële tools voor elke STLC-fase

Hier zijn mijn keuzes voor de beste tools voor de softwaretestlevenscyclus:

Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.

1. 1. QA.tech — Het beste voor door AI aangestuurd end-to-endtesten
2. 2. Kualitee — Het beste voor beheer van testgevallen + foutopvolging
3. 3. Testpad — Ideaal voor checklistgebaseerd testbeheer
4. 4. BugHerd — Het beste voor visuele bugopsporing
5. 5. BugBug — Ideaal voor browsertests
6. 6. Testiny — Ideaal voor Jira-gebruikers
7. 7. TestGrid — Het beste voor parallelle testuitvoering
8. 8. Appsurify TestBrain — Het beste voor risicogebaseerd testen
9. 9. QA Wolf — Het beste voor teamsamenwerking
10. 10. Tricentis Testim — Het beste voor schaalbare automatisering

Veelvoorkomende STLC-uitdagingen en hoe je deze overwint

Hier zijn de meest voorkomende obstakels en hoe je deze kunt aanpakken:

• Onduidelijke vereisten: Onduidelijke acceptatiecriteria leiden tot tests die het verkeerde valideren. Los dit op tijdens de vereistenanalyse. Wacht niet tot de uitvoering om te ontdekken dat een vereiste niet testbaar is.
• Instabiele omgeving: Een onbetrouwbare testomgeving verspilt cycli en vermindert het vertrouwen in de resultaten. Investeer in een omgeving als code met Docker of Kubernetes, zodat je op verzoek consistente, reproduceerbare omgevingen kunt opstarten.
• Onbetrouwbare geautomatiseerde tests: Sommige fouten in geautomatiseerde tests worden veroorzaakt door onbetrouwbare tests en niet door daadwerkelijke defecten. Controleer je automatiseringssuite regelmatig en herschrijf tests die inconsistent falen.
• Krappe deadlines: Wanneer de planningsdruk toeneemt, beperken teams het testen (meestal regressietesten). Pas risicogestuurd testen toe om gebieden met een grote impact te prioriteren in plaats van blindelings te schrappen.
• Afzonderlijke teams: Wanneer ontwikkelaars en QA in afzonderlijke banen werken, verloopt het sorteren van defecten trager. Stel gedeelde kanalen, een vaste sorteerfrequentie en overeengekomen definities van ernst vast voordat de uitvoering begint.
• Druk om het rendement van automatisering aan te tonen: Automatisering vereist een investering vooraf en doorlopend onderhoud. Begin met stabiele, veelgebruikte testgevallen (bijv. aanmeldingsprocessen, API-contracten en afrekenpaden) voordat je uitbreidt naar randgevallen.

STLC in Agile en DevOps: naar links verschuiven en continu testen

De zes STLC-fasen zijn nog steeds van toepassing in Agile en DevOps, maar ze worden korter en herhaald. In plaats van één lange cyclus per release voert je team bij elke sprint een kortere versie uit.

• Testen naar links verschuiven: Dit betekent dat testen eerder in de ontwikkeling plaatsvindt. Testers beoordelen gebruikersverhalen tijdens de sprintplanning, testgevallen bestaan voordat de code wordt geschreven en ontwikkelaars schrijven unittests naast functies. Hoe eerder je een defect vindt, hoe goedkoper het is om het op te lossen.
• Continu testen: Hierbij worden geautomatiseerde tests geïntegreerd in de CI/CD-pijplijn. Elke commit start een testrun en de pijplijn stopt snel wanneer een regressie optreedt. Ontwikkelaars krijgen direct feedback zonder op een speciaal testvenster te hoeven wachten.

Pas de volgende werkwijzen toe om de STLC aan Agile en DevOps aan te passen:

• Integreer QA in sprintceremonies: Testers moeten deelnemen aan de sprintplanning om acceptatiecriteria te beoordelen en problemen met testbaarheid te signaleren voordat de ontwikkeling begint.
• Automatiseer regressietests naast functies: Bouw geen regressiesuite na de release. Bouw deze terwijl elke functie wordt uitgebracht.
• Gebruik functievlaggen: Implementeer code achter een vlag en test deze vervolgens in productie voordat je de code voor gebruikers inschakelt.
• Behandel omgevingen als code: Gebruik infrastructuur als code om bij elke build automatisch consistente omgevingen in te richten.

Mijn ervaring is dat de grootste verandering cultureel van aard is. Ontwikkelaars en testers als één team laten samenwerken, in plaats van in opeenvolgende fasen, is wat Agile testen laat werken.

De rol van automatisering en AI in de moderne STLC

Automatisering hoort thuis in je STLC, maar het is geen vervanging voor een teststrategie. Het versnelt de juiste soorten tests.

Wat je kunt automatiseren

Automatiseer tests die veelvuldig worden uitgevoerd, stabiel zijn en veel tijd kosten om handmatig uit te voeren:

• Regressietesten: De toepassing met het hoogste rendement voor automatisering. Voer je volledige regressiesuite bij elke build uit.
• API-testen: Snel, betrouwbaar en gemakkelijker te onderhouden dan UI-tests.
• Smoketesten: Automatiseer je smoketests, zodat validatie van de omgeving minuten in plaats van uren duurt.
• Belastbaarheids- en prestatietesten: Tools zoals k6 en Apache JMeter kunnen duizenden gelijktijdige gebruikers simuleren. Dit is handmatig onmogelijk na te bootsen.

Hoe AI de STLC verandert

AI zorgt voor betekenisvolle veranderingen in de manier waarop testen gedurende de gehele levenscyclus wordt uitgevoerd:

• Genereren van testgevallen: AI-tools analyseren vereisten of gebruikersverhalen en stellen testgevallen voor die je team anders mogelijk zou missen.
• Zelfherstellende tests: AI-gestuurde frameworks detecteren wanneer een UI-element verandert en werken de testselector automatisch bij, waardoor de onderhoudslast afneemt.
• Voorspellende defectanalyse: Sommige platforms analyseren historische defectgegevens om te voorspellen welke onderdelen van een codebase bij een bepaalde release het grootste risico vormen.
• Visueel testen: AI-aangedreven tools vergelijken schermafbeeldingen pixel voor pixel en signaleren wijzigingen in de lay-out zonder kwetsbare XPath-selectors.

Ik zie AI bij het testen op dezelfde manier als automatisering in het algemeen: het handelt repetitief werk waarbij patronen worden herkend af, zodat je QA-engineers zich kunnen richten op testen waarvoor menselijk beoordelingsvermogen nodig is.

Beste praktijken voor de levenscyclus van softwaretests

Volg deze praktijken om in elke fase het maximale uit je STLC te halen:

• Begin bij de vereisten met testen: Hoe eerder QA wordt betrokken, hoe minder onduidelijkheden in de ontwikkeling terechtkomen.
• Houd een actuele RTM bij: Houd de traceerbaarheidsmatrix voor vereisten bijgewerkt, zodat hiaten in de dekking in realtime zichtbaar zijn.
• Pas risicogestuurd testen toe: Richt je inspanningen eerst op gebieden met een hoog risico en een grote impact, vooral wanneer de tijd beperkt is.
• Beoordeel testgevallen vóór de uitvoering: Door collega's beoordeelde testgevallen brengen hiaten en onjuiste aannames aan het licht voordat die misleidende resultaten opleveren.
• Integreer tests in CI/CD: Geautomatiseerde tests moeten bij elke commit worden uitgevoerd, niet alleen vóór een release.
• Voer elke cyclus een evaluatie uit: Gebruik wat je uit elke STLC leert om de volgende te verbeteren.

Belangrijke meetwaarden om te volgen

Deze KPI's geven je het duidelijkste beeld van de testkwaliteit en de gezondheid van het proces:

Meetwaarde	Wat deze meet	Waarom deze belangrijk is
Defectdichtheid	Defecten per eenheid code of functie	Geeft inzicht in de codekwaliteit en grondigheid van het testen
Slagingspercentage van testgevallen	% van de testgevallen die in een cyclus slagen	Volgt de algehele gezondheid van de build
Defectlekken	Defecten die in productie worden gevonden versus tijdens het testen	Meet hoeveel er tijdens het testen over het hoofd is gezien
Testdekking	% van de vereisten die door testgevallen worden gedekt	Garandeert dat niets ongetest blijft
Oplostijd van defecten	Gemiddelde tijd van registratie tot oplossing	Weerspiegelt de reactiesnelheid van het ontwikkelingsteam
Testuitvoeringspercentage	% van de geplande testgevallen dat is uitgevoerd	Volgt of het testen volgens schema verloopt

Houd je kennis over testen actueel

Als je op de hoogte wilt blijven van trends in kwaliteitsengineering en de tools die de moderne ontwikkeling vormgeven, bezorgt de nieuwsbrief van The CTO Club wekelijks inzichten van CTO's, engineeringdirecteuren en technische leiders rechtstreeks in je inbox.