In de eerste jaren was het vooral zaak het agile-gedachtengoed te evangeliseren, maar op dit moment verlaten meer en meer organisaties hun klassieke aanpakken voor een agile-aanpak, op dit moment meestal Scrum. Daardoor kan ik mijn pijlen inmiddels richten op agile anti-patterns; dingen die misgaan in agile-projecten. Ook erg leuk, want er gaat ook in agile-projecten meer dan genoeg mis. Ook agile is geen silver bullet.
Voorbeelden? Alhoewel je steeds meer mensen hoort zeggen dat ze DE agile-methodiek gebruiken, bestaat er helemaal niet zoiets als DE agile-methodiek. Wel zijn er een heleboel agile-werkwijzen, zoals Scrum, XP, Smart, FDD of Kanban. Elk met hun eigen voorgangers, discipelen en volgelingen, om in de evangelisatie-metafoor te blijven.
Helaas constateer ik dat de agile-comminity toch langzaam wat dogmatischer wordt. Calvinistischer. Populariteit verstart nu eenmaal. Al meerdere malen heb ik discussies meegemaakt dat ik geen smart use cases mag gebruiken in agile-projecten of dat een stand-up meeting geen facilitator mag hebben. Zeggen dat er in de diverse agile-werkwijzen zaken ontbreken die broodnodig zijn in projecten, is dan ook vloeken in de kerk.
De meeste agile-processen focussen namelijk maar op een klein deel van wat er in systeemontwikkelprojecten allemaal gebeurt. Er is tereecht heel veel aandacht voor het schrijven van code, maar er is veel minder aandacht voor analyse, ontwerp en zeker voor testen. Alhoewel de meeste agile-werkwijzen wel over unit testing spreken, onderscheiden ze geen aparte rol voor testers. En unit testing is met name een techniek voor ontwikkelaars, waarbij kort gezegd testcode wordt geschreven voor de eigenlijke code.
Wanneer we echter grote agile-projecten doen voor grote organisaties speelt in mijn optiek de tester een cruciale rol. Er is namelijk veel meer tussen hemel en aarde dan unit testing. Zo coachte ik recent een complex servicegeorienteerd agile-SAP-project. Een unieke aangelegenheid, waarschijnlijk het eerste in zijn soort in Nederland, maar zeker niet het laatste als het aan de projectleden ligt. In dit project speelden onze testers een cruciale rol. Omdat we in korte iteraties software analyseren, ontwerpen, bouwen, testen en opleveren, maken de testers vanaf dag één deel uit van het project. Dat biedt perspectieven.
De unieke kijk op de wereld die testers namelijk aan de dag leggen, onderscheidt ze sterk van ontwikkelaars. Ontwikkelaars bemerken vaak niet of niet snel genoeg de uitzonderingen die testers als het ware vanzelfsprekend wel opmerken. In complexe projecten maken we graag en dankbaar gebruik van dit godgegeven talent. Onze testers zijn dan met de ontwikkelaars medeverantwoordelijk voor het ontwerp van de software. Op deze manier voorkomen we veel fouten in het schrijven van de software nog voordat we ze maken. Eigenlijk is dit een functionele vorm van unit testing.
Helaas focussen veel agile-werkwijzen en -projecten zich (voorlopig) vooral op het schrijven van de juiste code en is er, mede door het ontbreken van de rol tester in de meeste werkwijzen, nog onvoldoende aandacht van de positieve rol die testers in projecten kunnen spelen. En dat is, om in de evangelisatie-metafoor te blijven: zonde. Amen.
Reacties
Mooi artikel, helder en bondig
Testen is in mijn ogen per definitie objectief werk, waarbij je het liefst geen projectpet op hebt - en dan meestal veel gebreken ontdekt.
Aanhaken van testers in een zo vroeg mogelijk stadium verdient zeker aanbeveling, het liefst op het moment van design. Want alhoewel ontwikkelaars soms wat ik noem "doelgericht coderen" geldt dat ook voor ontwerpers.
Idealiter biedt een FO ruimte voor alle regels en uitzonderingen op het functionele vlak, en een TO doet dat op het technische vlak. Waarbij de unieke kijk op de wereld en een positief-kritische aanpak een waardevolle bijdrage zullen leveren
Overigens merk ik het calvinisme ook als je het onderwerp "onderhouden van door Agile-projecten opgeleverde code" aansnijdt ...
Doelgericht coderen vind ik wel een mooi term!
Overigens, in onze agile-projecten is er uiteraard niet zoiets als "we maken eerst een FO, dan een TO en dan gaan we bouwen, en daarna testen."
Werken in korte iteraties betekent echter: we pakken 1 smart use case bij de horens, en ontwerpen, bouwen, testen en opleveren we precies die ene. Dat is nogal anders dan veel testers (en in minder mate developers, projectmanagers, archtitecten, analisten) op dit moment veelal gewend zijn.
Absoluut met het artikel eens. Komt wellicht het imago van testers ook ten goede. Niet achteraan de boel vertragen, maar parallel meelopen. En een ontwikkelaar wil uiteindelijk een goed werkend product afleveren.
Belangrijkste winst die ik zie is dat er voor enkel achteraf (goed) testen en oplossen in een agile benadering geen tijd meer is. Dat redt je nooit in sprints van 4 weken of minder.
Je ziet inderdaad (helaas) vaak gebeuren dat organisaties agile teams vormen zonder daarbij testen te betrekken. Daarmee zijn we eigenlijk weer terug bij af: er wordt (heel effici?nt) iets gebouwd en het testen gebeurt aan het eind. Waar heb ik dat meer gehoord? Iedereen was het er inmiddels wel over eens dat je zo vroeg mogelijk moet beginnen met testen, (en met agile kan dat juist heel goed) worden de testers toch weer aan de kant gezet.
Verder lijken organisaties het moeilijk te vinden om het testen in agile projecten goed op de rit te krijgen. Bij Sogeti krijgen we regelmatig vragen om advies op dit gebied. Met ons pas herziene testproces verbeteringsmodel (TPI NEXT, lancering op 17 november 2009) kunnen we hier gelukkig goed antwoord op geven.
Wat betreft het dogmatisme: er zijn altijd mensen die alle regeltjes willen volgen zonder naar de context te kijken. Welk model of welke methode je ook gebruikt, je moet ze altijd doelgericht en doeltreffend toepassen.
Goed geschreven artikel. Wij gebruiken Scrum en de testers zijn vertegenwoordigd in het scrum team. Het probleem is vaak dat ze klagen dat de testomschrijving niet in het begin van de sprint gemaakt kan worden. Een ander punt is de rol van de technisch schrijver. Deze wordt meestal verwaarloost (taak en rol wordt eigenlijk nergens beschreven). In een utopische situatie zou de technisch schrijver met de tester samen eerst moeten beschrijven wat de developer moet ontwikkelen. Hierdoor komt het resultaat vaak dichter bij wat de PO wil. Daarnaast is er een probleem van planning voor alle deelnemers in het team en de overkoepelende teamleader voor bijvoorbeeld de technisch schrijvers. Ik hoop dat ook deze punten beschreven kunnen worden.
Tja...wat zal ik zeggen
Op het artikel valt niks af te dingen, goed geschreven.
Maar het geeft te denken over de volwassenheid van een deel van onze nationale it-community.
In aanvulling van eerdere opmerkingen (geen aandacht voor de technisch schrijver en onderhoudbaarheid) kan ik ook nog noemen: geen aandacht voor configuration management, geen aandacht voor product lifecycle management
Een systeem maken is meer dan alleen wat code kloppen en unit testen, dat wordt nogal eens vergeten geloof ik.
Goed artikel! Alleen wel jammer dat er niet verteld wordt waarom er voor een dergelijke methodiek gekozen wordt. Ik heb redelijk goed beeld bij wanneer het handig is om een bepaalde methodiek te gebruiken, maar er wordt nog steeds teveel geroepen dat een bepaalde methodiek altijd of nagenoeg altijd de beste is. Zet ze voor jezelf eens op een rij en geef dan de voordelen en nadelen aan. Dan kun je een keuze maken afhankelijk van je situatie en wens!!! Daarna is het van belang of je de methodiek kan toepassen. Heb je er wel de middelen voor in huis! Als de keuze niet onderbouwd wordt met middelen kom je ook niet erg ver! Pas dan je keuze aan en/of je middelen waar nodig.
De schrijver komt blijkbaar situaties tegen waarbij anno tegenwoordig functionele testers geen deel uitmaken van het team (of de lijn) en niet in elke iteratie of sprint de software testen, dan wel niet de ontwerpen beoordelen op testbaarheid en risico's.
Als dat werkelijk zo is, dan vraag ik me af hoe dat komt. Binnen het agile manifesto staat nergens iets over unit test dan wel functioneel testen genoemd maar noemt werkende software als maatstaf van voortgang. Ik was mij er niet van bewust dat er mensen zijn die dit anders interpreteren dan dat er een functionele test heeft plaatsgevonden i.t.t. alleen een unit test. Ik heb XP op wikipedia er op nageslagen en die spreekt alleen van unit test en acceptance test, misschien is dat de verwarring? In SCRUM is het volgens mij zeker niet de bedoeling om de functionele test over te slaan binnen de definitie van Done voor "werkende software".
Ik sta 100% achter de inhoud van het artikel, echter ik herken het eigenlijk niet zo. Binnen het agile manifesto staat nergens iets over specifiek unit testen dan wel functioneel testen genoemd maar noemt werkende software als maatstaf van voortgang. Ik was mij er niet van bewust dat er mensen zijn die dit anders interpreteren dan dat er een functionele test heeft plaatsgevonden i.t.t. alleen een unit test. Ik heb XP op wikipedia er op nageslagen en die spreekt alleen van unit test en acceptance test, misschien is dat hetgeen verwarring heeft gebracht bij onze meer dogmatische vakbroeders? In SCRUM is het volgens mij zeker niet de bedoeling om de functionele test over te slaan binnen de definitie van Done voor "werkende software". Wij hebben bij al onze agile en formal projecten in ieder geval al jaren professionele testers in het team opgenomen, ik hoop dat iedereen dat doet of gaat doen of het nu ergens staat of niet.
In de agile projecten die ik voorbij zie komen zie ik inderdaad een sterke focus op unittesten en hooguit acceptatie testen. Aangezien de klant vaak verantwoordelijk wordt gehouden voor de AT ligt de focus vrijwel uitsluitend op unit testen (of unittests aan elkaar gekoppeld en dan is het een integratietest). Ik kan Sanders verhaal dan ook onderschrijven.
Wat de agile teams vergeten is dat unit tests slechts een beperkt aantal type fouten kan constateren. Ja, inputwaarden kunnen gevalideerd en veldlengtes, CRUD, cursorpositie etc. Maar wat doet een agile team met de GUI? Autorisatie? Sorteringen? Ergonomie? Kortom: er blijven HEEL VEEL bugs in je systeem zitten als je alleen maar een unittest uitvoert!
Ja, inderdaad. De schrijver van dit artikel komt heel veel projecten tegen waar testers geen deel van uitmaken. Testen is, zowel in traditionele alsook in agile projecten, als professie niet altijd even zichtbaar. En dat is jammer.