In onze digitale wereld is een korte time to market cruciaal om de concurrentie een stapje voor te blijven. Maar daar heb je een agile en kwalitatief IT-apparaat voor nodig. Quality Assurance kan hier een belangrijke bijdrage in leveren.
Concepten als het V-model en de verschillende testfases komen op de schoolbanken wel aan bod, maar in de praktijk? Niet langer dan 15 jaar geleden was het testen van software een noodzakelijk kwaad en werd dit zelden op een gestructureerde wijze opgezet.
Bovendien was dit ook de eerste activiteit waarop bespaard werd in geval van tijdsgebrek. De resultaten liegen er dan ook niet om: rond de eeuwwisseling haalde meer dan 70% van de IT-projecten wereldwijd de vooropgestelde planning, kwaliteit en/of budget niet.
Hoewel tijdens het laatste decennium aanzienlijke vooruitgang geboekt werd (Quality Assurance is niet langer synoniem met monkey testing), is het slagingspercentage van een project niet wezenlijk verbeterd. Al te vaak ligt de focus op manuele testuitvoer door eindgebruikers die de juiste testvaardigheden niet beheersen en die dit bovenop hun operationele taken moeten nemen.
Los van de bovenstaande situatie staan de ondernemingen en hun ICT-afdelingen onder steeds hoger wordende druk om op te leveren. Een mobielere en veeleisende klant, mondiale concurrentie en doorgedreven digitalisatie zijn slechts enkele van de uitdagingen waar ‘business’ en bijgevolg ook ‘ICT’ mee worstelen.
Een kortere time-to-market is hierin cruciaal, maar een klassiek waterval ICT-model met drie releases per jaar verander je niet zomaar in een agile maandelijks releaseproces. QA kan een belangrijke rol spelen om deze transformatie mogelijk te maken en wel op 2 vlakken:
- First time right, m.a.w. investeren in QA van bij het begin van de SDLC.
- Het verkorten van de doorlooptijd (lead time), door een doorgedreven automatisatie van de manuele QA-activiteiten.
First time right: betrek business vanaf het begin
Een trend die we momenteel nog te veel zien is dat business een idee heeft en het door IT laat uitwerken, om dan tijdens UAT of in productie tot de conclusie te komen dat het toch niet is wat men nodig heeft. Omwille van eerdere slechte ervaringen groeit het besef dat de vereisten van bij het begin duidelijker gedefinieerd moeten worden. Traditioneel bespreekt business de vereisten met analisten die dan uitzoeken en documenteren wat mogelijk is, zodat het project daarna door ontwikkelaars en kwaliteitsverantwoordelijke kan worden opgenomen.
Met de agile manier van projectaanpak is de betrokkenheid van de business door de producteigenaar al groter en krijgt men al sneller feedback na elke sprint. Maar ook in dit geval hebben de ontwikkelaars dikwijls al een sprint met mogelijke foute features proberen te implementeren. Om dit op te vangen en de dingen van de eerste keer correct proberen te krijgen, gaan we business nog sneller moeten betrekken.
Amigos meeting: breng al je requirements in kaart
Een steeds vaker gebruikte manier om business vroeger te betrekken is de zogenoemde amigos meeting. Dit is een meeting met de producteigenaar en een vertegenwoordiger van alle betrokken IT partijen (architectuur, ontwikkeling, analyse en QA). Tijdens de amigos meeting legt de producteigenaar feature per feature uit. Alle betrokken partijen krijgen de informatie rechtstreeks van de producteigenaar, waardoor mogelijke valkuilen of problemen in een vroeg stadium geïdentificeerd en aangepakt kunnen worden.
Op het einde van de meeting moeten alle vragen en bemerkingen uitgeklaard zijn en moeten alle vertegenwoordigers op dezelfde lijn zitten. De deliverable van de meeting is een checklist waarin alle vereisten staan waaraan de feature moet voldoen om als 'done' beschouwd te worden.
Deze checklist is op dit moment goedgekeurd door de producteigenaar en door alle andere vertegenwoordigers. Op basis hiervan kunnen dan door de QA-verantwoordelijke de te valideren/te testen zaken worden gedefinieerd. Het is dan ook meestal deze persoon die zal opvolgen en controleren of bij de oplevering aan business aan alle vereisten is voldaan.
Door deze manier van werken wordt de validatie door business een formaliteit. Maar om zo ver te geraken zal het vertrouwen van business in IT voldoende gegroeid moeten zijn.
Automated testing helpt de lead time van je project te verkleinen
Momenteel zien we al een vooruitgang inzake het automatiseren van testen. Deze automatisatie wordt verspreid over het automatiseren van unit, integratie en GUI testen. Net omwille van een gebrek aan vertrouwen wordt er door business nog te veel tijd geïnvesteerd in het manueel testen van de software tijdens de UAT-testfase. Dit is een zeer tijdrovende activiteit, met een grote impact op de doorlooptijd van de release.
Door het eerder aangehaalde ‘first time right’ principe, wordt de business al heel vroeg en nauw betrokken, vóór de ontwikkelingsfase. Aangezien er op dat moment ook al een checklist is met de vereisten waaraan elke feature moet voldoen om als klaar te worden beschouwd, is het ook makkelijk om vroeger in het proces al testen te gaan automatiseren, met andere woorden meteen op low-level unit test niveau. Het geautomatiseerd testen van elke feature tijdens het ontwikkelen leidt tot een stabieler systeem in een veel vroeger stadium.
Als we daarbij ook de integratietesten (de zogenaamde services als API, Rest, …) kunnen automatiseren, gaan we een stabiel systeem krijgen dat aan de vereisten van de business zou moeten voldoen. Hierdoor zal de effort naar GUI testen, al dan niet geautomatiseerd, beperkt kunnen worden. Een handig model dat dit toont is de test pyramid van Mike Cohn, die een richtlijn geeft voor de investering in test automation over de verschillende testfases heen. Dit is uiteraard een richtlijn waar we allemaal naar streven, maar waar we momenteel zeker nog niet zijn.
Continuous deployment en continuous delivery
Eens de stap gezet is naar het automatiseren van de meeste tests in een zo vroeg mogelijk stadium, kunnen we gaan denken aan continuous deployment.
In een continuous deployment proces is het mogelijk om het resultaat van een development proces onmiddellijk te installeren op een pre-productieomgeving die zo kort mogelijk aanleunt bij de productieomgeving zelf. Op deze omgeving kunnen dan nog enkele functionele of GUI testen uitgevoerd worden door de business.
Waar de meeste bedrijven van dromen is een volledig geautomatiseerd proces. Dus niet alleen geautomatiseerde testen, maar eigenlijk een volledig geautomatiseerd proces van het inchecken van code tot en met het installeren in productie. Dit noemt men een continuous delivery proces.
Tijdens dit proces zal het inchecken van de nieuwe code automatisch gevolgd worden door het automatisch valideren of de nieuwe code voldoet aan de ‘definition of done’. Wanneer aan de definitie van done is voldaan zal de code via hetzelfde automatisch proces in productie worden geïnstalleerd.
Op deze manier wordt de time to market danig verkort. Het spreekt voor zich dat dit laatste model zich niet voor elke situatie leent (legacy omgeving) en van alle IT-activiteiten een hoge maturiteit vereist. Anderzijds laat het je wel toe om net iets sneller in te spelen op de wijzigende realiteit dan je concurrent.
Wil je graag je IT delivery model aan snelheid laten winnen zonder aan kwaliteit in te boeten? Neem contact op met ons QA-team.
Met dank aan Joeri Wijns voor zijn input bij het samenstellen van dit artikel.
