We kunnen er niet meer omheen, agile ontwikkeling is meer regel dan uitzondering. Naast dat er ontzettend veel gezegd en geschreven wordt over agile, wordt de werkwijze in de praktijk volop toegepast. De voordelen van agile-ontwikkelmethodes op het gebied van resultaatgerichtheid, snelheid en flexibiliteit worden breed gedragen. Als je software ontwikkelt via de agile-ontwikkelmethode, dan zullen de processen en werkzaamheden die met de ontwikkeling in hand gaan naadloos op elkaar moeten aansluiten.
Testen binnen agile heeft nog maar weinig voet aan de grond gekregen, terwijl het belang van testen in het algemeen wel steeds vaker wordt onderkend. Onzorgvuldig of helemaal niet testen kan je duur komen te staan. Organisaties zijn momenteel dan ook zoekende naar hoe testen goed te regelen binnen agile. Maar welke keuzemogelijkheden zijn er om testen binnen agile goed te beleggen?
Onderdeel
Om zuiver volgens de basisprincipes van agile te werken, is de tester onderdeel van het development team. Officieel worden binnen agile projecten immers geen externe disciplines betrokken. Het testen komt op deze werkwijze voor rekening van het development team, waar zowel testers als ontwikkelaars deel van uit maken. Dit gaat in mijn optiek ten koste van de kritische blik en objectiviteit van het testwerk. Want zeg nou zelf, hoe objectief kan jij je eigen werk testen? Het uitbreiden van het development team met een tester kan uitkomst bieden. Zijn taken worden afgebakend tot alleen testwerkzaamheden, en dus geen ontwikkeltaken. Op deze manier blijft de objectiviteit gewaarborgd en ontstaat er een natuurlijke dualiteit tussen ontwikkelaar en tester. In het geval van innovaties en compleet nieuwe concepten kan deze vorm heel passend zijn. Verhoudingsgewijs valt er dan veel te testen, en door de tester in het team op te nemen wordt het echt een ongoing proces. In andere situaties kan de benodigde capaciteit voor het testwerk meer variëren.
Het uitbesteden van testwerk is misschien niet helemaal volgens de richtlijnen van de agile ontwikkelmethode, maar kan hier wel goed op aansluiten. Met off- en nearshoring is goed financieel voordeel te behalen, zeker ten opzichte van het uitbreiden van het agile projectteam. Het uurtarief lijkt aanlokkelijk, maar in de praktijk duren testprojecten vaak drie keer zo lang. Daarnaast kan het cultuur- en tijdverschil een groot struikelblok vormen.
Dichter bij huis zijn er ook testoplossingen. Volgens het Test Factory model werk je met een on demand testteam dat aangestuurd wordt door de product owner, de tester of een andere verantwoordelijke uit het team. De tests worden uitgevoerd volgens specificatie met gevalideerde testdata, die door zowel het projectteam als door het Test Factory team opgesteld kunnen worden. Door testing on demand kan gezorgd worden voor stabiliteit en wordt de totale kwaliteit gewaarborgd. Het testteam wordt ad hoc ingeschakeld en sluit daardoor perfect aan bij de agile ontwikkelmethodes, waarbij flexibiliteit en wendbaarheid vereist zijn.
Meerdere mogelijkheden
Er zijn dus meerdere mogelijkheden voor handen om testen goed te beleggen binnen de agile ontwikkelmethodes. Echter door krampachtig vast te houden aan het agile gedachtegoed zet je jezelf schaakmat. Ga dus agile met agile om. Denk iets buiten de traditionele kaders, en er gaat een nieuwe wereld aan testmogelijkheden open. Zorg ervoor dat testen geen bottleneck gaat vormen en toets het testproces aan de kenmerken van agile: Flexibel, wendbaar, up-to-date, schaalbaar en snel. Kies de meest passende methode bij het betreffende project en top de testprestaties.
Meer informatie over het testen binnen agile is te lezen in het whitepaper ‘Top testprestaties binnen agile’.
“Het testen komt op deze werkwijze voor rekening van het development team, waar zowel testers als ontwikkelaars deel van uit maken. Dit gaat in mijn optiek ten koste van de kritische blik en objectiviteit van het testwerk.”
Geldt dit niet voor alle disciplines binnen de software ontwikkeling???
Als het agile team zich bezig moet gaan houden met requirements management, requirements engineering, configuration management, build management, testmanagement, release management, document management, project management (en alle andere disciplines die ik nu vergeet), blijft er dan nog wel tijd over voor ontwikkeling?
Ik geloof in de kracht van multidisciplinaire teams, maar niet in het bundelen van meerdere disciplines (zoals in het artikel genoemd wordt bijvoorbeeld testen en ontwikkelen) in één persoon. Het grote gevaar wat in deze aanpak schuilt is dat je na een tijdje generalisten hebt in plaats van specialisten, daar waar specialistische kennis onontbeerlijk is voor innovatie.
De tester binnen het agile team is als het goed is ook betrokken in het vastleggen van requirements met de klant/opdrachtgever. En in die betrokkenheid is het zaak dat de tester zijn rol goed invult ten opzichte van de klant en ten opzichte van de teamleden, met een kritische blik naar de requirements en naar het ontwikkelde systeem.
Ik zie daar geen conflict, tenzij het ontbreekt aan wederzijds respect voor ieders rol in het team zodat de agile aanpak tot een goed systeem leidt.
Beste Sjoerd,
Je stelt: “Testen binnen agile heeft nog maar weinig voet aan de grond gekregen, terwijl het belang van testen in het algemeen wel steeds vaker wordt onderkend.” en ook “Organisaties zijn momenteel dan ook zoekende naar hoe testen goed te regelen binnen agile.”
Mag ik jou en de lezers van dit artikel attenderen op het boek “Testen2.0. De praktijk van agile testen” wat sinds 2008 al uit is via Sdu Uitgevers? Nog steeds is die informatie actueel als het gaat om de rol van testen in een agile project.
https://www.sdu.nl/testen-2-0-paperback.html
Actuele inhoud rondom Agile, testen en organisaties die meer Agile willen vind je onder meer op onze blog.
Waarom wordt hier (een vaak elders) van “Testen” als één proces gesproken?
En dan wordt er nog gediscussieerd over het beste aanpak van het “testen” binnen agile. Een tester binnen de team plaatsen? of toch outsourcen?
Grappig en triest.
De software dient getest te worden op verschillende vlakken, o.a. programmeerfouten, gebruiksvriendelijkheid, stabiliteit, compatibiliteit, beveiliging, prestatie, doeltreffendheid en veel meer. Je kunt niet simpelweg één aanpak kiezen, of één persoon tests laten uitvoeren!
Het testen op elk van deze vlakken vereist verschillende betrokkenen, verschillende aanpakken, verschillende omgevingen, verschillende testgegevens en verschillende specialisten.
Voorbeeld:
Zo moeten de producteigenaar en de eindgebruiker actief participeren in het testen van doeltreffendheid en gebruiksvriendelijkheid, want zij weten als geen ander (vaak heel gedetailleerd) wat er van de software wordt verwacht en hoe het later geïmplementeerd en gebruikt zal worden. Nog niet te vergeten dat bij de laatste een UI/UX designer ook aanwezig te zijn. Hij is namelijk degene die de verwachtingen van de genoemde personen kan “decoderen”. De klant zegt namelijk vaak ‘Ik wil de mogelijkheid om de achtergrond te veranderen’, terwijl hij last heeft van een slecht leesbare tekst.
Bedenk even of je iemand van deze mensen bij beveiligingstests nodig hebt…? Bij het testen op programmeerfouten…? Hanteer hiervoor je ook dezelfde aanpak als bij de eerdergenoemde tests? Dat dacht ik al…
Conclusie:
Gebruik je overal dezelfde aanpak? Dezelfde mensen? Dan ben je aan het testen voor een vinkje, en niet voor een resultaat.
Beste Slava, is het doel van een Agile-team niet om werkende functionaliteiten op te leveren? Andere testvormen worden dan ook niet opgepakt binnen het Agile-team. Simpelweg omdat het niet de opdracht is voor het team. Hier komt een testmanager om de hoek kijken die bepaalt welke testvormen wanneer (scope en planning) toegepast gaan worden en door wie.
@ all: Ik ben het wel met Sjoerd eens dat de onafhankelijke positie van de testers in het geding kan komen als deze plaats neemt binnen het Agile-team. Een tester moet kritisch zijn en daarom objectief. De andere disciplines hebben meer aan samenwerking om gezamenlijk hetzelfde beeld te krijgen, elkaar meer te gaan begrijpen, zodat gebouwd wordt wat wenselijk is. Dit betekent dat een tester anders samenwerkt in het Agile-team dan de andere disciplines. Als dit niet wordt onderkend, dan heb je kans op uitdagingen. De tester is kritisch in het kijken of de functionaliteit werkt. De gebruiker en de product-owner kijkt of de functionaliteit werkbaar is. Uiteraard leert men van elkaar en zal dat het proces versnellen, maar uiteindelijk zijn de testtaken zoals benoemd.
Even voor de goede orde (en wellicht een open deur): agile is een container begrip. Waarmee wordt aangegeven dat het toegepaste ontwikkel proces o.a. flexibel is en sneller tot resultaten komt in vergelijking met bijvoorbeeld de waterval methode of het V model.
Maar het is feitelijk niks meer dan een doorontwikkeling van RAD uit de jaren 80. Met als moderne invulling bijvoorbeeld SCRUM.
Binnen die methode beslaat een ontwikkelperiode ongeveer 4 weken. Op het eind van die 4 weken dient dan een werkende functie opgeleverd te worden.
Na een aantal van deze periodes is de nieuwe app klaar en kan begonnen worden aan een laatste kwaliteitscontrole en de uitrol.
Maar met een dergelijke korte ontwikkeltijd lijkt het me ondoenlijk om nog iets van testen te doen – vooral de non-functional testen lijken dan zwaar onder druk te staan.
Om vervolgens de gebruikers (ook) te gebruiken als testers – performance problemen lossen we dan wel op bij een volgende versie – nu eerst maar eens live!
Samengevat – zelfs de meest prachtige test methodes vallen in het water op het moment dat time-to-market en winstgevendheid belangrijker is als kwaliteit en een tevreden klant/gebruiker. En dat lijkt vandaag de dag toch een veel voorkomende wegingsfactor bij het in bedrijf nemen van een nieuwe app…
🙂
Wat opvalt aan zowel artikel als de reacties dat we het kennelijk als de gewoonste zaak van de wereld beschouwen dat het hele realisatieproces van karakter veranderd is maar dat testen en het testproces kennelijk buiten deze veranderingen vallen.
Het is te realiseren dat het daadwerkelijk agile werken voortkomt uit behoeften van de klant en dat het nu ook kan door toegenomen professionaliteit van de IT-ers en kwaliteit van de tools.
In het verlengde daarvan ben ik ervan overtuigd dat ook het testen de komende jaren dramatische veranderingen zal ondergaan. Zo zal het gebruik van tooling sterk toe gaan nemen. Dit vereist specialisten om te zorgen dat de tools effectief gebruikt worden. Zo zal binnen een scrumteam geen plaats zijn voor testers. Het team zal hooguit support krijgen van een specialist die toeziet op de kwaliteit van testen.
Als er al een rol is voor testers dan is het als sparring partner van de IT-ers om te zorgen dat de gemaakte code kwalitatief goed is. Boehm zal blij zijn, een vroeger moment om fouten te detecteren is niet denkbaar.
Tenslotte zullen er specialisten zijn die de testinfrastructuur managen.
Mijn conclusie: geachte testers, u zult zichzelf opnieuw uit moeten vinden. En dat lijkt me niet alleen nodig maar ook een heel goede, energie gevende ontwikkeling.
Ik krijg altijd kromme tenen als ik de dooddoener hoor … ‘we kunnen er niet meer omheen’ of ‘…. u kunt wel anders willen maar hier gaan we wel naartoe…’ Ongeacht even de achtergrond waartegen dat dan word gesteld.
Testen.
Testen op zich is een ABC dat een heel eenvoudig cyclus kent. De Civile Matrix toont dat al jaren in zijn gehele eenvoud en daar is helemaal niets ‘agiles’ aan. Het is gewoon common sense.
Proces en inrichting
Heel sec stelt men de voorwaarde op waaronder zal worden getest. Of dit nu software is of hardware, de beginselen zijn gewoon dezelfde. het is overigens wel erg handig dat de tester word uitgelegd waarom er moet worden getest, zodat die dat ook (weer) eens op het netvlies krijgt.
Communicatie
Een zeer belangrijk onderdeel, altijd al geweest, is de communicatie. Die kan op verschillende momenten plaats vinden en nemen en laten we wel zijn, niet iedere IT-er is nu eenmaal behept met een goede vorm en zin voor communicatie. Jammer dat je dat aspect dan weer zo weinig terug ziet vaak in de processen.
Klaarmaken voor Pilot
Wat je door kostendrang ook nog wel eens ziet gebeuren dat men domweg een streep zet door een pilot, terwijl juist dat een wezenlijk onderdeel is van het proces, tenminste, dat zou een logisch doel moeten zijn na het test traject. Ook daar zie je dan weer het nodige mis gaan.
Approval
Als laatste is dan natuurlijk ook de handtekening zien te krijgen van management of gebruiker dat het test deel is geslaagd waardoor hard of software feitelijk klaar is voor implementatie.
Nu kan het natuurlijk volkomen aan mij liggen maar wanneer ik telkens weer mensen nieuwe dingen, termen en namen hoor en zie verzinnen, maar feitelijk de ballen verstand hebben van IT als materie, en de wetmatigheden, dan haal ik mijn schouders maar weer eens op want ik heb nog steeds de voordelen en besparingen van agile uiteindelijk nog niet kunnen besparen t.a.v. de meest basale vorm van testen.
Het zal dan ongetwijfeld wel weer aan mij liggen, ik hoef dan ook gelukkig de rekening niet te betalen.
Met enige regelmaat zie artikelen voorbij komen over hoe problematisch testen wel niet is in relatie tot software ontwikkeling. Het probleem zit hem volgens mij niet zozeer bij het testen maar bij de schrijver. Testen is namelijk, zeker bij agile, een onderdeel van het ontwikkel proces. Net als al die andere activiteiten en rollen die programmeurs nodig hebben om samen met hen tot werkbare software te komen.
Volgens mij valt met dit inzicht redelijkerwijs de bodem onder het bovenstaande artikel weg. En oh ja, zet er voortaan even bij dat het advertentie is als je naar je eigen dienst (TestFactory) toe schrijft. Niet dat daar verder iets mee mis is.