Agile testen past de principes van de agile-methodologie toe op producttesten, waarbij continu testen wordt geïntegreerd in elke ontwikkelingsfase.
Misschien wel meer dan welke andere ontwikkelingsmethode ook heeft de agile benadering van softwareontwikkeling de manier waarop bedrijven het maakproces van apps benaderen, volledig veranderd. In tegenstelling tot de meer traditionele 'waterval'-methodologieën, waarbij lineaire systemen vereisen dat teams een volledige projectfase voltooien voordat de volgende fase kan beginnen, stelt agile ontwikkeling teams in staat om gelijktijdig aan meerdere projectfasen te werken.
De voordelen van deze aanpak zijn onder andere een snellere time-to-market, een grotere transparantie van projecten en de flexibiliteit om midden in het project van koers te veranderen om rekening te houden met veranderende doelstellingen of andere nieuwe informatie. En een kernelement van de agile aanpak is agile testen.
Bij agile hoeft het testen niet te wachten tot het ontwikkelingsaspect van het project is voltooid. In plaats daarvan vindt testen continu plaats naast andere ontwikkelingsinspanningen. Testers werken samen met ontwikkelaars en zelfs klanten om voor een eindproduct van hogere kwaliteit te zorgen.
Er zijn verschillende elementen die agile testen onderscheiden van de waterval-benadering:
Zoals hierboven vermeld, stelt traditionele softwareontwikkeling het testen uit tot het einde van de ontwikkelingscyclus. Dit komt omdat in de Waterfall-methodologie elke projectfase moet wachten tot de vorige fase is voltooid, voordat deze kan beginnen. Als zodanig kon de test- en integratiefase alleen worden gestart na de systeemontwerp- en implementatiefasen, waarin het ontwikkelingswerk al is voltooid.
Dit starre ontwikkelingsmodel is duidelijk gestructureerd en relatief eenvoudig te beheren. Er zijn echter ook verschillende nadelen. Wanneer projectvereisten onverwacht veranderen of wanneer tests inherente problemen aan het licht brengen in vroege conceptuele fasen, kan aanpassing om rekening te houden met deze problemen bijna onmogelijk zijn. Simpel gezegd, wanneer testen wordt uitgesteld tot na de ontwikkeling, wordt het aanpakken van wijzigingen en softwarebugs moeilijk en kostbaar en kan dit het vermogen van een team om deadlines te halen belemmeren. Vaak worden ze geconfronteerd met een ongelukkige keuze: de release uitstellen totdat elk probleem kan worden opgelost, of een ondermaats product uitbrengen: een situatie met alleen maar verliezers.
In tegenstelling tot de waterval-methodologie staat agile erop dat tests in elke ontwikkelingsfase plaatsvinden. Wanneer een update van de softwarecode wordt uitgevoerd, controleert het testteam automatisch de functionaliteit ervan. Initiële tests kunnen ook worden gebruikt om te bepalen welke vorm de code moet hebben. Tests kunnen ook geautomatiseerde oplossingen omvatten, evenals bruikbaarheidstests waarbij eindgebruikers betrokken zijn.
Hoewel het chaotisch lijkt om in elke fase testen te implementeren, kunnen teams in werkelijkheid sneller betere eindproducten produceren door tijdens de gehele ontwikkeling te testen. Hiervoor moeten ze zich houden aan verschillende belangrijke agile principes:
- Continue feedback
Testers moeten voortdurend feedback van gebruikers en testresultaten aan ontwikkelaars verstrekken. - Klanttevredenheid
Het bieden van een positieve gebruikerservaring moet het primaire doel van alle agile testers zijn. - Onbeperkte communicatie
Communicatie is van het grootste belang bij agile tests. Directe ontmoetingen met ontwikkelaars helpen fouten en misverstanden te verminderen, en geven feedback van gebruikers veel effectiever door. - Eenvoud
Er is geen ruimte in de agile methodologie voor onnodig testen of verkeerd afgestemde werkzaamheden. Agile testers moeten alle benodigde tests uitvoeren, maar alleen die tests die nodig zijn. - Aanpasbaarheid
Agile testers moeten in staat zijn om in te spelen op projectwijzigingen en feedback van gebruikers. - Samenwerking
Testers werken rechtstreeks met en voor mensen, waarbij interactie boven technologie wordt gewaardeerd. Een duidelijke focus op mensen helpt bruikbaarheid te prioriteren.
Omdat agile testen een integraal onderdeel is van de agile ontwikkelingsmethode, sluiten de voordelen ervan nauw aan bij andere agile voordelen. Deze voordelen omvatten het volgende:
Aangezien agile testen de teams in staat stelt defecten veel eerder in het ontwikkelingsproces op te sporen en te corrigeren, is de kans kleiner dat bugs worden meegenomen naar de lancering. Tegelijkertijd wordt elk lid van het ontwikkelingsteam bij het testen betrokken, zodat zij hun unieke vaardigheden kunnen inzetten voor een beter eindproduct.
Bij traditionele ontwikkeling wordt het product pas vrijgegeven wanneer elke ontwikkelingsfase is voltooid. Helaas kan, door het snelle tempo van de technologische evolutie, zelfs een paar maanden ontwikkelingslimbo resulteren in functies, of zelfs volledige producten, die volledig verouderd zijn tegen de tijd dat ze klaar zijn om te worden geïmplementeerd. Door ontwikkeling en testen continu te combineren gedurende de hele levenscyclus, verloopt de productie snel en zijn vrijgegeven toepassingen relevant voor de huidige markt.
Wanneer teams werken als lopende banden, gaat er veel tijd verloren wanneer testers moeten wachten tot projecten in de testfase komen. Agile testen elimineert dit tijdverlies, waardoor testers tegelijkertijd met ontwikkelaars kunnen werken. Dit betekent dat meer taken in minder tijd worden voltooid.
Klanten en andere eindgebruikers willen nu oplossingen. Als ze gedwongen worden te wachten op productlanceringen, verliezen ze hun interesse. Agile tests leveren niet alleen sneller toepassingen op, maar zorgen er ook voor dat toepassingen altijd worden verbeterd om de klantervaring beter te bedienen.
Hoewel Agile testen in elke fase van de ontwikkelingscyclus plaatsvindt, omvat een effectieve Agile teststrategie een eigen levenscyclus, die bestaat uit vier verschillende fasen:
De eerste fase van agile testen wordt vaak aangeduid als "Iteratie 0" en omvat het grondwerk dat nodig is om tests vooruit te helpen. Hieronder valt het opstellen van een business case, bereik en grenzen voor het project, terwijl ook de belangrijkste eisen worden geschetst, risico's worden geïdentificeerd en kostenramingen worden gemaakt. Het behelst ook het identificeren en veiligstellen van essentiële testresources (waaronder mensen en tools).
De meeste agile-tests vinden plaats in deze fase. Constructie-iteraties zijn herhaalde testacties die kunnen worden geclassificeerd als bevestigingstests of onderzoekstests. Bevestigingstests verifiëren of de functie of het product voldoet aan het vastgestelde doel waarvoor het is ontworpen. Onderzoekstests lokaliseren bugs of andere problemen die niet direct verband houden met het doel van het product, zoals bruikbaarheid of integratiefouten.
Wanneer het project zijn voltooiing nadert, moeten agile testers de voltooide software als geheel valideren. Dit omvat testen van het gehele systeem en acceptatietesten, en is over het algemeen veel strenger dan testen halverwege de ontwikkeling.
Tenslotte kan het product, als het testen is voltooid, in productie worden genomen.
Naarmate ze meer bedreven raken in agile ontwikkeling, geven veel organisaties er de voorkeur aan hun eigen agile testmethodologie te creëren die beter aansluit op hun unieke behoeften. Toch helpt het vaak om te beginnen met een gevestigde methodologie, en die vervolgens aan te passen aan specifieke use cases. Hieronder volgen verschillende populaire benaderingen van agile testen:
Testgestuurde ontwikkeling (Test-Driven Development/TDD) plaatst tests aan het begin van het agile ontwikkelingsproces. Voor elke functionaliteit worden tests gemaakt en vervolgens uitgevoerd. Als het programma de test niet doorstaat, wat zal gebeuren omdat de code voor de functie nog niet is geschreven, schrijven ontwikkelaars de eenvoudigste code die mogelijk is om de test te laten slagen. Geautomatiseerde testscripts geven ontwikkelaars instructies om alleen code te schrijven wanneer tests mislukken, waardoor het risico van dubbele code wordt geëlimineerd.
Acceptatietestgestuurde ontwikkeling (Acceptance Test-Driven Development/ATDD) is vergelijkbaar met standaard testgestuurde ontwikkeling. De onderscheidende factor is dat ATDD begint met het creëren van een klantverhaal. Teams stellen vast hoe het product moet worden gebruikt en maken vervolgens een gebruikersacceptatietest om de ontwikkeling te begeleiden. Deze benadering plaatst de verwachtingen van gebruikers voorop in de ontwikkelingscyclus.
Als een natuurlijke aanvulling op ATDD begint gedragsgestuurde ontwikkeling (Behavior-Driven Development/BDD) ook met het maken van een gebruikersverhaal. Dat verhaal moet echter direct verbonden zijn met een bedrijfsresultaat, en specificeren waarom - vanuit zakelijk perspectief - de functie wordt ontwikkeld. Vervolgens worden tests gebouwd om de ontwikkeling in de richting van de gewenste bedrijfsresultaten te sturen.
Terwijl bij TDD-, ATDD- en BDD-testmethoden geautomatiseerde testscripts worden gebruikt, wordt bij verkennend testen een handmatige aanpak gevolgd. Het is afhankelijk van menselijke testers die relevante tests genereren terwijl ze het product in ontwikkeling verkennen. Hoewel verkennend testen niet zo gestructureerd of snel is als de hierboven vermelde testmethoden, maakt het volledig gebruik van de vaardigheden en intuïtie van de tester en is het effectief bij het lokaliseren van risicogerelateerde problemen die bij andere testbenaderingen onopgemerkt zouden blijven.
Sessiegebaseerde testen gaan verder dan verkennende tests. In plaats van zo sterk te vertrouwen op de instincten van de tester, voegt het structuur toe waarmee tests kunnen worden uitgevoerd. Aan het begin van elke sessiegebaseerde test stellen testers een charter op waarin precies wordt beschreven wat het team hoopt te ontdekken met de test. Dit wordt gevolgd door een gerichte, ononderbroken test, waarna de test wordt gerapporteerd. Door verkennende tests te starten met een duidelijk doel in gedachten, kunnen testers ervoor zorgen dat er geen gebieden over het hoofd worden gezien.
Agile testen voorziet in veel verschillende benaderingen en soorten tests, waardoor het moeilijk kan zijn om te bepalen welke tests het meest geschikt zijn in welke omstandigheden, en of handmatig of geautomatiseerd testen de betere aanpak is. Veel bedrijven vertrouwen op agile testkwadranten om hun ontwikkelingsteams te leiden.
Agile testkwadranten bieden essentiële testtaxonomie: teams kunnen snel bepalen welk soort code moet worden geschreven door naar de twee kwadranten aan de linkerkant te kijken, en meer te weten komen over de code die ze hebben geschreven in de twee kwadranten aan de rechterkant. De vier kwadranten zijn als volgt:
Dit kwadrant bevat tests om de code en het product te verbeteren. Ze zijn over het algemeen geautomatiseerd en worden gedurende de hele levenscyclus van de app-ontwikkeling uitgevoerd, zodat ontwikkelaars feedback krijgen over de kwaliteit van de code.
Het tweede kwadrant is gewijd aan tests die helpen de bedrijfsresultaten van het product te verbeteren. Deze tests combineren handmatige en geautomatiseerde scripts en zorgen ervoor dat het product doet wat het zou moeten doen en de waarde voor zowel het bedrijf als zijn klanten verhoogt.
Kwadrant 3 geeft feedback over tests in de vorige twee kwadranten en bestaat uit gebruikersacceptatie-, bruikbaarheids- en verkennende tests. Het doel van deze handmatige tests is om zowel het product zelf als de gebruikerservaring te testen, en om ontwikkelaars essentieel inzicht te geven in het product, zodat het zijn aangewezen functie kan vervullen.
Kwadrant 4 omvat tests met betrekking tot de niet-functionele vereisten van het product, zoals gegevensbeveiliging, stabiliteit en compatibiliteit. Deze technologiegerichte prestatietests zijn gebaseerd op tools die het testproces kunnen automatiseren.
Samen bieden deze kwadranten een holistisch overzicht van softwaretests om de besluitvorming te ondersteunen. Ze bieden echter geen middel om tests te prioriteren. Deze beslissingen moeten door de teams zelf worden genomen.
Agile softwareontwikkeling heeft de manier veranderd waarop organisaties van alle soorten en maten software maken, en agile testen is een groot deel van deze revolutie. Maar doordat constant testen bij elke stap van de ontwikkelingscyclus is geïntegreerd, kunnen testprocessen snel chaotisch worden.
ServiceNow, de marktleider op het gebied van IT-beheeroplossingen, biedt de tools die bedrijven nodig hebben om het meeste uit agile testen te halen. De applicatie ServiceNow Testbeheer 2.0 helpt het beheer van testprocessen te organiseren en te stroomlijnen. Managers kunnen eenvoudig tests en testsets bouwen en bewaken, testplannen en -cycli maken, resources toewijzen en tests en testresultaten evalueren. Ook testers krijgen meer ondersteuning bij het maken van tests en testsets, het uitvoeren van tests en het registreren van resultaten, en het rapporteren van defecten.
Geef je tests de kracht om agile ontwikkeling te optimaliseren. Probeer ServiceNow Testbeheer 2.0 en ga verder met tests dan ooit tevoren.