Ben je bekend met de Agile Testing Life Cycle (ATLC)? Het is een proces dat door softwareontwikkelingsteams wordt gebruikt om ervoor te zorgen dat hun applicaties correct en effectief worden getest.
Dit bericht leidt je door alles wat je moet weten over ATLC, inclusief de voordelen, stappen in het proces, het plannen van een praktische teststrategie, het uitvoeren van tests op basis van het verzamelen van vereisten en het volgen van bugs, gebruikersacceptatietests (UAT) en continue integratie & automatisering van testen.
Na het lezen van deze gids, zult u beter begrijpen hoe u agile testen kunt gebruiken als onderdeel van uw softwareontwikkelingslevenscyclus!
Als u een agile ontwikkelaar, tester of productmanager bent en op zoek bent naar een betere manier om uw producten te leveren, dan legt dit artikel de betrokken fasen uit, samen met de nodige actie die moet worden ondernomen.
Overzicht van de levenscyclus van agile testen
Het is geen geheim dat testen enorm belangrijk is in de wereld van agile ontwikkeling. Maar ondanks dat is het vaak een onderschatte activiteit binnen agile delivery. De reden hiervoor is natuurlijk het geld in verhouding tot de leveringstijd tot productie.
Maar zonder gedetailleerde tests is er geen garantie voor kwaliteit of betrouwbaarheid voor elk product dat uw team ontwikkelt. Daarom is het cruciaal om de agile testlevenscyclus te begrijpen – van het identificeren van werkitems tot het begrijpen welk type test binnen elke fase moet worden gebruikt.
De agile testcyclus vereist dat ontwikkelaars en testers bij elke afzonderlijke sprint worden betrokken. Door het goed te doen, is testautomatisering in elke fase mogelijk, waardoor bugs eerder en vaker worden gedetecteerd, waardoor er later minder tijd nodig is om problemen op te lossen.
Agile testen helpt ook bij de vroege validatie van vereisten en verbetert, als neveneffect, de klanttevredenheid door een kwaliteitsproduct te leveren.
Wat is Agile Testing en de voordelen ervan
Agile Testing is een innovatieve methode voor het testen van software die gebruikmaakt van automatisering om een iteratief testproces te creëren. Deze op automatisering gerichte benadering helpt teams om snel eventuele inconsistenties of problemen in de code te analyseren en vervolgens wijzigingen te testen op basis van deze feedback.
De belangrijkste voordelen van dit proces lijken dus duidelijk:
- ervoor te zorgen dat het testen de nodige impact heeft,
- het leidt tot efficiëntere ontwikkelingstijden,
- het ontwikkelde systeem heeft over het algemeen snellere oplossingen voor bugs,
- en de klanttevredenheid is verbeterd.
Kwaliteit en snelheid zijn hierbij cruciale factoren, aangezien de sprint wordt gedefinieerd als een korte periode (meestal 2 tot 4 weken). Hoe meer het team kan vertrouwen op de kwaliteit die is opgenomen in de sprinttesten, hoe groter het vertrouwen en de snellere ontwikkelingsvoortgang die het team kan produceren.
Focus op automatisering zou het primaire doel moeten zijn van elk agile team. Hierdoor kunnen teams het risico op kostbare mislukkingen verkleinen en kan er meer tijd worden besteed aan het maken van nieuwe inhoud in plaats van aan het repareren van wat al in productie is.
Een ander bijkomend voordeel is een betere inschatting van de projectkosten en de tijdlijn. Omdat het product veel volwassener en voorspelbaarder is, zijn er minder situaties waarin het team te maken krijgt met onverwachte problemen die tijdens de sprint naar voren komen zonder dergelijke complicaties vooraf te berekenen.
Agile Testing Levenscyclusstappen
De agile testlevenscyclus bestaat uit vier verschillende stadia.
Eenheidstests
Dit zijn de tests die door ontwikkelaars worden uitgevoerd zodra de code klaar is vanuit het oogpunt van ontwikkeling. Het wordt geïsoleerd uitgevoerd in een ontwikkelomgeving zonder tussenkomst van andere delen van het systeem.
Unit-tests worden uitgevoerd om de code te testen en kunnen handmatig en automatisch worden uitgevoerd.
Indien handmatig uitgevoerd, voert de ontwikkelaar zijn testcases uit tegen de code. Dit is snel te achterhalen, maar het kost meer tijd van de sprint die aan de ontwikkeling is gewijd, vooral vanuit een langetermijnperspectief.
Een alternatief hiervoor is het maken van een geautomatiseerde unit-testcode, die in feite de functiecode verifieert door deze uit te voeren. Dit betekent dat de ontwikkelaar niet alleen tijd moet besteden aan het ontwikkelen van de nieuwe functie, maar ook aan het ontwikkelen van de unit-testcode die die functie zal testen.
En hoewel dit vanuit een kortetermijnperspectief misschien een grotere inspanning lijkt, bespaart het het project als geheel tijd, omdat dergelijke unit-tests gemakkelijk opnieuw kunnen worden gebruikt, ook in latere stadia van de sprinttesten. Ze kunnen zelfs worden opgenomen in reguliere regressietestcases, wat nog meer tijd bespaart.
Ten slotte, hoe hoger de codedekking door geautomatiseerde unit-tests, hoe beter de betrouwbaarheidsstatistieken van de code aan de klant kunnen worden getoond.
Functionele testen
Functionele tests zijn ontworpen om te bepalen hoe goed een functie van een applicatie werkt. Dit type testen wordt gebruikt om de juiste functionaliteit van de code te garanderen in plaats van technische aspecten (die voornamelijk deel uitmaakten van het testen van eenheden), en om te beoordelen of deze al dan niet voldoet aan de behoeften en verwachtingen van de gebruikers.
Met andere woorden, functionele tests worden gebruikt om te verifiëren dat wat is ontwikkeld, voldoet aan de eisen die door de zakelijke gebruikers worden gesteld.
Het is een goede gewoonte om van tevoren belangrijke testgevallen te verzamelen bij relevante belanghebbenden (van de producteigenaar of zelfs van de eindgebruikers) en een lijst te maken van al dergelijke testgevallen die nodig zijn voor de inhoud in de sprint.
Het automatiseren van functionele tests vergt meer inspanning aan de kant van de testontwikkeling, aangezien dit complexe processen zijn die moeten worden geverifieerd, waarbij verschillende delen van het systeem samen worden betrokken. In dit geval is de beste strategie om een speciaal team op te richten dat alleen de functionele tests ontwikkelt langs de lijn die het hoofdontwikkelingsteam bezig is met het ontwikkelen van nieuwe functies.
Zeker, voor het project betekent dit hogere kosten voor het onderhouden van een apart team, maar het heeft ook een groot potentieel om het projectgeld op de lange termijn te besparen. Het is alleen aan projectmanagers om de voordelen en besparingen uit te leggen en specifiek te berekenen om voor zakelijke gebruikers een solide argument te maken dat zal leiden tot een dergelijke toename van de goedkeuring van projectkosten.
Aan de andere kant kan deze activiteit, indien handmatig gedaan, worden gedaan door een heel klein team (in sommige gevallen zelfs een enkele persoon). Er is echter een constante handmatige en herhaalde activiteit nodig voor elke sprint. Naarmate de functieset van het systeem zich na verloop van tijd uitbreidt, kan het moeilijker zijn om sprint voor sprint solide functionele tests in te halen.
Regressie testen
Het doel van de regressietest is om ervoor te zorgen dat alles wat tot nu toe werkte, ook zal werken na de volgende release. Er moeten regressietests worden uitgevoerd om ervoor te zorgen dat er geen compatibiliteitsproblemen zijn tussen verschillende modules.
Testcases voor regressietests zijn het beste als ze voor elke release regelmatig worden onderhouden en herzien. Op basis van de concrete projectspecificaties is het het beste om ze eenvoudig te houden, maar toch het merendeel van de kernfunctionaliteiten en belangrijke end-to-end-flows die door het hele systeem lopen te dekken.
Gewoonlijk heeft elk systeem dergelijke processen die veel verschillende gebieden raken, en dat zijn de beste kandidaten voor regressietestcases.
Als er bestaande geautomatiseerde unit-tests en functionele tests zijn, is automatisering in regressietesten een zeer gemakkelijke taak. Gebruik gewoon wat je al hebt voor het belangrijkste deel van het systeem (bijvoorbeeld voor processen die het meest in de productie worden gebruikt).
Gebruikersacceptatietests (UAT)
Last but not least valideert UAT dat de applicatie voldoet aan de benodigde vereisten voor productie-implementatie. Deze aanpak werkt het beste wanneer een stuk software regelmatig in korte en intense cycli wordt getest.
De UAT-test wordt uitsluitend uitgevoerd door de mensen buiten het agile team, idealiter door zakelijke gebruikers in een speciale omgeving, die zo dicht mogelijk bij de toekomstige productie ligt. Als alternatief kan de producteigenaar hier de eindgebruikers vervangen.
Dit moet in ieder geval een schone, functionele test zijn vanuit het perspectief van de eindgebruiker, zonder enige connectie met het ontwikkelteam. De resultaten van deze tests zijn hier om de allerbelangrijkste go/no go-beslissing te nemen voor productievrijgave.
Planning voor een effectieve teststrategie
Planning is een belangrijk onderdeel van agile testen, omdat het de hele strategie met elkaar verbindt. Het moet ook duidelijke tijdlijnverwachtingen stellen in de context van de sprints.
Door agile testplanning effectief te beheren, kunnen teams een duidelijke richting creëren die leidt tot efficiënt gebruik van middelen binnen een sprint. Het is duidelijk dat er meer samenwerking tussen testers en ontwikkelaars wordt verwacht.
Er moet ook een alomvattend plan worden opgesteld om in kaart te brengen wanneer het testen van eenheden, functionele testen of gebruikersacceptatietesten plaatsvindt binnen elke ontwikkelingssprint. Zo weet iedereen precies wanneer hun deelname vereist is voor een succesvolle agile lancering.
Hoe het plan moet worden opgesteld, kan worden bepaald na verdere bespreking en overeenstemming. Het belangrijkste is echter om er een proces van te maken en je eraan te houden. Creëer een periodiciteit die betrouwbaar en voorspelbaar is.
Drijf niet weg van het proces. Anders zal het tegenovergestelde de realiteit zijn: chaos en onvoorspelbare productiereleases.
Testen uitvoeren op basis van het verzamelen van vereisten
Tests moeten worden uitgevoerd tegen de vereisten van elke fase. Tickets worden vervolgens geopend wanneer een bug of probleem wordt gevonden en toegewezen aan het ontwikkelingsteam, dat vervolgens kan uitzoeken wat er moet worden opgelost of gewijzigd voor de code. Zodra alle bugs zijn verholpen, kan de uitvoering van agile tests worden voortgezet totdat alle tests zijn geslaagd.
Resultaten bekijken en bugs volgen
Een effectieve beoordeling van de resultaten en een solide proces voor het opsporen van fouten zijn essentieel. Bij het proces moeten alle relevante belanghebbenden worden betrokken, van projectmanagers en testers tot ontwikkelaars, en uiteindelijk ondersteuningsteams, maar ook klanten voor het verzamelen van feedback.
Dit moet voldoende uitgebreide activiteit zijn, zodat problemen snel kunnen worden geïdentificeerd en verholpen voordat de reeds geplande releasedatum in gevaar komt.
De tool naar keuze is weer aan het team. Maar eenmaal gekozen, moet elke testactiviteit betrouwbare processen voor het volgen van bugs bevatten om problemen te monitoren, ze te prioriteren op basis van afhankelijkheden, statusupdates van ontwikkelaars te rapporteren over oplossing of overdracht voor verder onderzoek, en vervolgens tickets te sluiten zodra ze zijn opgelost.
Reviewen helpt agile testers het gedrag van hun systeem te begrijpen en fouten bij elke stap te identificeren in plaats van later in het proces. Regelmatige beoordelingen stellen agile teams ook in staat om trends en gebieden te identificeren die verbetering behoeven, waardoor ze hun testkader voortdurend kunnen bijwerken en sneller producten van betere kwaliteit kunnen bouwen.
Afronding van de productrelease met productierooktest
Om het succes van de release te maximaliseren, is een Smoke Test-run tegen productie (net na release) een manier om meer vertrouwen te krijgen.
Deze test bestaat uit een reeks alleen-lezen activiteiten binnen het productiesysteem, die geen nieuwe willekeurige gegevens creëren, maar toch de basisfunctionaliteit van het systeem verifiëren vanuit het oogpunt van eindgebruikers.
Door de juiste belanghebbenden bij het proces te betrekken, zorgt u voor afstemming en verantwoording en vergroot u het vertrouwen dat de doelen zijn gehaald. Uiteindelijk staan deze testen garant voor een succesvolle release.
Continue integratie en automatisering van tests om de efficiëntie te verbeteren
Continue integratie en automatisering van tests worden steeds vaker door bedrijven toegepast om agile processen naar een hoger niveau te tillen.
Als het team automatisering in verschillende fasen kan implementeren, zoals hierboven beschreven, dan kunnen die worden gecombineerd en verbonden in een speciale testpijplijn, wat in feite een volledig geautomatiseerd batchproces is dat de meeste testactiviteiten onafhankelijk en zonder tussenkomst van een ander team uitvoert lid.
Na verloop van tijd zal zo’n uitgebreide testpijplijn de totale tijd die nodig is voor alle testfasen verkorten. Uiteindelijk kan het leiden tot een zeer snelle incrementele productierelease na het einde van elke sprint. Hoewel dit een ideaal scenario is, is het in werkelijkheid moeilijk te bereiken met alle betrokken teststappen. Automatisering is de enige manier om daar te komen.
Verschil tussen agile testen en watervaltesten
Agile-teststrategieën verschillen op verschillende manieren van traditionele watervalteststrategieën, zoals periodiciteit, parallellisme of toegewijde tijd voor elke activiteit.
Maar het meest opvallende verschil is de focus van elke benadering:
- Agile testen richt zich op constante, snelle iteraties van ontwikkeling en feedbackloops om problemen te identificeren en het product snel te verbeteren. Een iteratief proces gericht op samenwerking met klanten, continue integratie en adaptieve planning.
- Aan de andere kant legt traditioneel watervaltesten de nadruk op een lineair proces waarin elke fase afzonderlijk en in sequentiële volgorde wordt opgelost, waardoor de feedback van de hele oplossing alleen overblijft voor de allerlaatste fase van het project en zeer dicht bij de uiteindelijke releasedatum van de productie.
Het is duidelijk dat hoe eerder de problemen door de belangrijkste belanghebbenden worden geïdentificeerd, hoe beter de situatie voor het project is. In dit opzicht heeft de agile-methodiek zeker een grotere kans van slagen.
Conclusie
Hoewel de agile testlevenscyclus korter lijkt dan de waterval, is dat in werkelijkheid niet het geval. Het hele proces is continu en gaat door tot de releasedatum van het product. Afhankelijk van het budget en de beschikbare tijd voor elke sprint, moet je prioriteren welke tests tijdens die specifieke sprint worden uitgevoerd.
Een goed geplande teststrategie helpt u te kiezen welke functies of modules meer aandacht nodig hebben dan andere. Automatisering maakt het mogelijk om verschillende testfasen in dezelfde sprint op te nemen, waardoor de algehele betrouwbaarheid van het systeem van sprint tot sprint toeneemt.
U kunt nu enkele van de best practices voor scrumtesten bekijken.
