Auteur: Nanno van der Laan ● nanno@liquidsequence.com
Bij een Agile ontwikkelmethode wordt voor applicatie ontwikkeling en het testen veelal Test Driven Development (TDD) gekozen. TDD schiet ruimschoots tekort als het gaat om het ontwikkelen van bedrijfskritische systemen waarbij de nadruk ligt op het ondersteunen van bedrijfsprocessen. Data Driven Development is een effectievere aanpak, mede doordat het de drempel verlaagt naar ‘gebruikers’ die actief kunnen deelnemen aan het ontwikkelproces. De doelen van DDD zijn het definiëren van specificaties en het valideren hiervan. De insteek is het, in data formaat, opstellen van testcases, als onderdeel van test stories, waarna deze zelfde testcases ter verificatie gebruikt worden. In dit artikel beschrijven wij deze aanpak, daarbij gebruik makend van twee cloud platformen: Testimony voor het specificeren en testen – Harmony als application development en ‘executie’ platform. In dit artikel worden de ervaringen beschreven met DDD op de Duch Open Hackathon waar het team van Liquid Sequence de case voor Transavia en Schiphol heeft opgelost. De uitdaging: http://www.dutchopenhackathon.com/
De case: Transavia’s uitdagingen
Transavia wil haar passagiers helpen met een verscheidenheid aan service-informatie en oplossingen voor het vinden en boeken van tickets, check-in comfort, tax-free winkelen in-flight entertainment, et cetera. Nieuwe functionaliteiten stellen eisen aan de huidige Transavia systemen. Eisen die niet of moeizaam kunnen worden opgelost vanwege beperkingen, mede veroorzaakt door de verouderde technologie. Transavia gelooft sterk in de grenzeloze creativiteit van een nieuwe generatie ontwikkelaars die zowel binnen als buiten de luchtvaartsector actief zijn. In het kader van de DutchOpenHackathon heeft LiquidSequence een nieuw boeking systeem ontwikkeld dat als ‘hart’, fundament, kan dienen voor de wensen en ideeën zoals hierboven omschreven. Met andere woorden, uitbreidbaarheid, ook voor wensen welke nog niet onderkend zijn, is een belangrijke non-functional requirement welke door het team van Liquid Sequence is gerealiseerd.
Een nieuw online boeking systeem: de ‘AirPort(al)’
Het nieuwe boeking systeem is opgezet op basis van een portal concept: het ondersteunt gemeenschappelijk gebruik voor ‘interne’ business gebruikers (luchtvaartmaatschappijen, Schiphol) en ‘externe’ consumenten gebruikers, de reizigers. De AirPortal ondersteunt beide vanuit het diensten principe van gezamenlijk afnemers van IT-services. De AirPortal gebruikt twee API’s voor communicatie: één communiceert met het Transavia systeem dat availability & pricing aanlevert en één voor een de connectie met Schiphol voor real-time vluchtinformatie. Alle data wordt binnen de AirPortal opgeslagen. Hierbij is onder andere gebruikgemaakt van een zogeheten Triplestore, een database geoptimaliseerd voor de opslag en ophalen van subject-predicaat-objecten, zoals een vlucht naar Barcelona. 
Kortom, een uitstekend voorbeeld van de toepassing van de nieuwste [open source] technologieën. De 24 x7 beschikbaarheid eis is ingevuld door de Harmony ‘build-to-break’ multi-node architectuur. Door Harmony te implementeren op Google Compute Engine of Amazon wordt een lineaire schaalbaarheid bewerkstelligd.
De aanpak: Data Driven Development & tool ondersteuning
De AirPortal is ontwikkeld door gebruik te maken van Harmony en Testimony. De focus van de eerste oplevering het systeem voor het vinden van een bestemming en het kopen van een ticket. Data Driven Development en Test Driven Development zijn volgens een gelijke structuur opgezet; – beide kennen drie data-blokken:
- invoer ( input);
- verwachtingen (expectations);
- uitkomsten (outcomes).
DDD richt zich echter op functionele omschrijving van data en gewenste uitkomsten. DDD richt zich op domein experts, de gebruikers die de business goed kennen en deze kennis kunnen inzetten in het concreet beschrijven wat een systeem moet ‘doen’ (de verwachtingen). Het efficiënt beschrijven van specificaties is het meest flexibel door gebruik te maken van spreadsheets: deze brengen structuur aan en zijn eenvoudig uit te breiden, zowel in aantallen testgevallen (door meer testspecificaties toe te voegen) of door nieuwe functionaliteit (door nieuwe velden toe te voegen). Hiermee dient zich dan meteen de volgende vraag aan: Welke tooling kunnen we hiervoor gebruiken? Immers, het opslaan van testgevallen in spreadsheets moet omgezet kunnen worden in productiviteit en kwaliteit. Vandaar de link naar Testimony, een door ons ontwikkeld test platform volledig gebaseerd op spreadsheets.
Testimony spreadsheets zijn feitelijk templates en bieden op voorhand de hierboven beschreven ‘3-blokken’ structuur aan. Een belangrijk doel bij DDD is het minimaliseren van ongestructureerde specificaties. Een ideaal voorbeeld is een systeem beschrijving waarbij 100% van de functionele specificaties zijn vastgelegd in spreadsheets. Dus niet, zoals vaak het geval, in tekst documenten. Testimony is ontwikkeld op basis van Google DOCS. Hiermee kunnen de Testimony sheets makkelijk gedeeld worden met collega’s – en kan in voorkomende gevallen – zelfs binnen de sheets een ‘chat’ worden gestart om bijvoorbeeld nadere uitleg te geven over testspecificaties en/of testresultaten. Onze ervaring is dat dit een veel gebruikte functie is, niet in het minst omdat werken in de cloud het werken op afstand mogelijk maakt.
Test stories: het beschrijven van het boekingsysteem
Het voordeel van boekingsystemen is dat de specificaties eenvoudig herleidbaar zijn. Immers, een rondgang langs bestaande bo boekingssystemen zoals in gebruik bij KLM, Schiphol en Transavia, geeft reeds een goede aanzet tot specificaties. Een bijkomend voordeel voor dit artikel is dat het voor de meesten onder ons een heldere case is – iedereen heeft wel eens een vlucht geboekt met een online reservering systeem. De belangrijkste functies voor het nieuwe systeem zijn gegroepeerd in test stories, tekstregels die beschrijven wat de functies zijn. We structureren deze door eerst alle test stories te definiëren die de mogelijkheden van het systeem beschrijven Voorbeelden van test stories zijn:
1. standaard boekingen voor volwassenen;
2. idem maar nu voor volwassenen met kinderen;
3. idem maar nu voor volwassenen met baby’s;
4. idem maar nu voor volwassenen met kinderen en baby’s.
Daarna voegen we test stories toe die de beperkingen van het systeem beschrijven. Hierbij wordt het interessanter. Een voorbeeld van een beperking van het huidige systeem is:
5. Transavia’s [huidige] systeem accepteert geen boekingen voor alléén minderjarigen (jonger dan 12 jaar).
Deze beperking willen we ruimer gaan definiëren – iets wat tot meer passagiers moet gaan leiden. We voegen dus test stories toe die de uitbreidingen van het systeem beschrijven:
6. Transavia’s NIEUWE systeem accepteert wel boekingen voor alléén minderjarigen (jonger dan 12 jaar) – maar dan moet wel het ‘unaccompanied minor formulier ingevuld worden’.
Opmerking over scope en context
De bovenstaande groepen van test stories zijn typische voorbeelden hoe direct betrokkenen deze test stories zouden definiëren – de focus ligt duidelijk op het boeking systeem – met de daarbij behorende beperkingen. Wanneer we echter in ogenschouw nemen dat het nieuwe systeem het ‘hart’, het fundament moet gaan worden van alle nieuwe IT-systemen (dit in verband met toekomstige, nog niet onderkende uitbreidbaarheid eisen), dan is het wenselijk dat we in ieder geval de context verruimen en wellicht zelfs de scope van het nieuwe systeem. Twee voorbeelden worden aangedragen; hierbij de opmerkingen dat de laatste niet van toepassing is voor Transavia:
7. Peter 74 jaar, vliegt van Amsterdam naar Barcelona, kan geen lange afstanden lopen (min/meer gehandicapt) heeft behoefte aan transport naar de gate;
8. Roy vliegt naar Bali. Bij het boeken blijkt dat zijn paspoort niet lang genoeg geldig is. De bedrijfsregel is: vertrek [datum] uit Bali – paspoort vervaldatum > 6 maanden.
Definiëren van testcases: structuur + data = specificatie
Voor elk van de test stories, ‘in-scope’ van de AirPort(al), dienen test cases gedefinieerd te worden. Ook hier komt dus weer het voordeel van de herleidbaarheid van boekingen aan de orde: invoer (‘input’) en verwachtingen (‘expectations’) zijn eenvoudig te definiëren. Een voordeel is dat de availability & pricing data in de AirPortal worden opgeslagen – deze zijn, net zoals real-time vlucht informatie aan veranderingen onderhevig; iets wat het testen van de verwachtingen bemoeilijkt.
Uitgewerkte test cases:
1. volwassene boekt van Barcelona (Spain) naar Amsterdam (Netherlands), airline code = HV
a. vertrek 20/09/2014 om 14:00:00Z
b. vertrek 21/09/2014 om 14:00:00Z
2. volwassene boekt van Amsterdam (Netherlands) naar Barcelona (Spain), airline code = HV
a. vertrek 21/09/2014 om 05:55:00
b. vertrek 21/09/2014 om 12:25:00Z
c. vertrek 21/09/2014 om 18:50:00Z
Vanwege de opzet van een AirPortal is het tevens van belang dat een ‘derde’ airline geboekt kan worden, dus creëren we een KLM boeking. Vanuit de ‘richtlijnen’ gedachte had hiervoor een test story aanwezig moeten zijn
3. volwassene boekt van Amsterdam (Netherlands) naar London (Britain), airline code = KL
a. vertrek 20/09/2014 om 14:00:00Z
Feitelijk ontstaat er nu een beeld waarbij alle mogelijke invoer bekend wordt gemaakt, zowel geldige als niet geldige boekingen. Voor elke test case moeten de verwachtingen (‘expectations’) gedefinieerd worden … in dit geval betreft het availability (zijn er voldoende stoelen beschikbaar, kan er geboekt worden) & pricing (de ticketprijs).
Agility – aanpassen & uitbreiden van test stores
Een groot voordeel van Agile werken is dat het niet nodig is om ‘compleet’ te zijn (dus alle functionaliteit op voorhand gedefinieerd). Een mooi voorbeeld is een uitbreiding (zie voorgaande paragraaf) als er onvoldoende stoelen beschikbaar zijn. Dit vereist het aanmaken van een nieuwe test story en het beschrijven van testgevallen. Het volgende is van belang:
1. de beslissing welke [het systeem] moet nemen dient helder/concreet beschreven te zijn in termen van
a. tekst (de story / de uitleg);
b. data (onder welke condities het systeem een alternatief voorstel aandraagt).
2. Er dienen voldoende verschillende testgevallen aanwezig te zijn opdat degenen die het systeem creëren weten of deze beslissingen zijn op te lossen met een simpele conditie of dat hiervoor een decision table benodigd is.
Het creëren van de applicatie/het systeem
Hier volgt een korte omschrijving van de ontwikkeling van de applicatie, we beperken ons tot de boodschap van dit artikel – te weten DDD.
De aanwezigheid van testgevallen maakt het mogelijk om invoer [user interface], rules en expressies, zoals berekeningen, te implementeren; het motto is immers ‘data drives development’. Hoe gaat dit in de praktijk ?
Executie van test cases / testgevallen
Nadat invoer (‘input’) en verwachtingen (‘expectations’) zijn gedefinieerd is het mogelijk om de test uit te voeren. Uiteraard geschiedt dit automatisch. De inputs worden via een API aanroep ‘ingeschoten’ in het AirPortal systeem, de resultaten (‘outcomes’) worden vergeleken met de verwachtingen waarna de uiteindelijke uitkomst ‘goed’ of ‘fout’ is.
Productie Acceptatie Test (PAT)
In traditionele ontwikkelomgevingen moet er tijd besteed worden aan performance en schaalbaarheid testen. Hier zien we de belangrijke voordelen van oplossingen die ‘onder architectuur’ ontwikkeld zijn – zoals Harmony. De kans dat er performance en/of schaalbaarheid issues naar voren kunnen komen is verwaarloosbaar – zeker in de ‘AirPort(al) case’. Alleen in extreem complexe systemen (met tien duizenden business rules) zouden deze issues zich kunnen voordoen op basis van grote aantallen en een te kleine deployment/productie omgeving. In dat geval is het wenselijk dat specifieke testen bepaald moeten worden op basis van de onderkende risico’s.
Samenvattend
Echte schaalvoordelen van een Agile methode worden pas concreet als het totale ontwikkeltraject ook mee evolueert; dit vereist nieuwe tooling. Transformatie van traditioneel naar Agile omvat meer dan alleen het Agile testen of the invoeren van DDD of TDD.
Nieuwe, reeds beschikbare, tools faciliteren de automatisering van systeemontwikkeling, zoals bijvoorbeeld het geautomatiseerd testen. Van belang is te weten dat er niet zo gek veel aandachtspunten zijn om dit tot een succes te maken; laagdrempeligheid is hierbij het sleutelwoord. Met minder IT expertise kan meer bereikt worden in kortere tijd – zonder dat dit afbreuk doet aan de kwaliteit van de oplossing. Deze is immers ‘unbreakable’.