Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Author:
Reading time: 3 minutes
Op het ontwikkelcentrum van Sioux passen we vrijwel altijd de Agile-ontwikkelmethode toe. Daarom is scrummen dus de dagelijkse praktijk voor de verschillende projecten die er op dit moment lopen. Het strikte watervalmodel heeft echt afgedaan en kan inmiddels toch wel worden omschreven als iets uit de prehistorie.
Maar de Agile-werkmethode uitleggen aan klanten valt niet altijd mee. Velen van hen wensen een fixed-priceproject of willen op zijn minst van tevoren een uitspraak hebben over de ontwikkelkosten en niet iedereen wil of kan de rol van producteigenaar effectief spelen. Veelal moeten we dus alsnog eerst een requirementsfase uitvoeren om een goede inschatting te kunnen maken van de kosten en om intern de producteigenaarsrol te kunnen vervullen. Toch stellen de meeste klanten tweewekelijkse oplevering van werkende code zeer op prijs. Daarmee raken ze automatisch meer betrokken bij de ontwikkeling dan in de prehistorische situatie.
Natuurlijk maken we ijverig heel veel unittests die na de continuous build automatisch worden uitgevoerd, maar hier wordt het lastiger om de eindklant bij te betrekken. Voor veel unittests geldt dat ze een stukje functionaliteit testen dat niet direct zichtbaar is voor de eindklant. Ook is het voor hem of haar vaak onduidelijk voor welke requirement deze test nodig is. Hiervoor moeten we traceerbaarheid toevoegen en daarvoor moeten we de requirements van identificatie voorzien. Maar dat is een beetje een kunstmatig gedoe en weinig mensen controleren de match tussen requirements en code en test. Eigenlijk zou je willen dat de eindklant begrijpt wat de code doet, maar ja, die heeft wel wat beters te doen.
Gelukkig is er een manier om ook de klant bij tests te betrekken: behaviour driven design (BDD). Deze aanpak blijkt een enorme bijdrage te leveren aan de betrokkenheid van de klant bij de ontwikkeling van het project. Bij BDD worden de requirements in een natuurlijke taal weergegeven die goed leesbaar is voor iedereen. Na vertaling levert dit extra unittests op die natuurlijk eerst falen totdat de juiste functionaliteit is toegevoegd. Bij twee projecten zetten we de requirements om in het taaltje Gherkin. Cucumber (Ruby) en Specflow (.Net) zijn de tools die Gherkin-scenario‘s omzetten naar unittests. Deze tests blijkt de eindklant prima te kunnen reviewen.
Met een dergelijke agiele manier van werken voorkomen we veel fouten en borgen we dat we echt het juiste implementeren. Toch blijkt het na ingebruikname van een systeem soms nog nodig om problemen in de praktijk snel te kunnen opsporen. Goede logginginformatie is hiervoor essentieel. Ontwikkelaars moeten zo veel mogelijk de loginformatie gebruiken om een test te laten slagen. Dus behalve op de beoogde toestand of uitkomst van het systeem kun je testen op de juiste ingang in het logbestand.
Veelal wil de klant de logfile in leesbare vorm opgeleverd zien. Door daarnaast Gherkin toe te passen, kan hij zichzelf ervan overtuigen dat de juiste requirements zijn geïmplementeerd en bijbehorende correcte logging wordt gegenereerd. Het toevoegen van logging als middel voor het verbeteren van de softwarekwaliteit noemen we quality enhancing logging, oftewel Quel. Met deze methodes hebben we middelen om het domein van de klant gemakkelijk om te zetten naar ons domein en wordt hij toch betrokken bij dit stadium van het ontwikkelproces.
