Portfolio

Uitdaging: Bij een tier-1 toeleverancier moest een testproces geautomatiseerd worden. Samen met enkele collega’s werkte ik als inhuurkracht in een klein testteam, naast enkele vaste medewerkers die daar al jaren zaten en talloze projecten hadden meegemaakt. Vanuit management was besloten dat er geautomatiseerd moest worden: projecten werden complexer en vroegen steeds meer testtijd, en met beperkte capaciteit en budget was automatisering de voor de hand liggende keuze.

Op papier een heldere, technische opdracht. In de praktijk bleek er nauwelijks ruimte voor automatisering. Als inhuurkrachten werden we overladen met taken als het schrijven en ontwikkelen van handmatige testcases; zelfs het uitvoeren van testen kwam uiteindelijk alleen nog bij de vaste medewerkers te liggen. Voor automatisering was geen ruimte: geen licenties, geen hardware en geen mogelijkheden om een vaste opstelling voor geautomatiseerde regressietesten in te richten. Het automatiseringstraject, dat op termijn juist verlichting van het handmatige testwerk had moeten opleveren, werd steeds uitgesteld met als excuus dat er te weinig tijd was, juist omdat er zoveel handmatig getest moest worden. De kruiwagen met het vierkante wiel: te druk met duwen en geen tijd om het ronde wiel te monteren.

De onderliggende oorzaak (het technische QA-vraagstuk):De onderliggende oorzaak (het technische QA-vraagstuk): Het testteam was voortdurend bezig met brandjes blussen op systeemniveau. Dat was het gevolg van te weinig testen op softwareniveau, waardoor softwareintegratiefouten, functionele softwarefouten én systeemintegratiefouten (waar software en hardware samenkomen) allemaal in de systeemtest naar de oppervlakte kwamen. Een fout in die systeemtest kan daardoor tal van onderliggende oorzaken hebben, wat de analyse aanzienlijk complexer maakt. Bovendien kostten de handmatige testen zoveel tijd dat ze niet vaker dan één keer per softwarerelease uitgevoerd konden worden, waardoor fouten pas laat ontdekt konden worden.

De juiste methode om dit aan te pakken zou zijn om teststappen in het proces toe te voegen op de testlagen van het V-cycle-model, de rechter zijde van de V. Een softwareintegratietest (SWE.5) of een functionele softwaretest (SWE.6), zonder de ECU-hardware erbij te betrekken. Echter, dat is voor veel embedded systems geen mogelijkheid. Wanneer dit niet tot de mogelijkheden behoort, helpt het om de iteraties klein te houden en vaker te testen. Bijvoorbeeld: na elke softwarecodewijziging. Dit vereist echter dat de gewijzigde softwaremodule wordt geïntegreerd in de softwareapplicatie, die op zijn beurt weer met de ECU-hardware wordt geïntegreerd tot een systeem. Dit systeem kan dan op een HIL-testopstelling een regressietest ondergaan. Ook deze integratiestappen zijn geen formaliteit; ze vragen bewuste keuzes en kosten tijd. Zonder automatisering van zowel de testcases als het integratieproces, is zo’n proces te zwaar om bijvoorbeeld dagelijks uit te voeren.

Automatisering van testcases bespaart (uiteindelijk) veel tijd, met name tijdens de testexecutiefase; er is immers geen menselijke interactie meer benodigd om de testcase uit te voeren. Daarnaast is een geautomatiseerde testcase in de regel ook sneller, nauwkeuriger en constanter. Dit alles zorgt ervoor dat er in een korter tijdsbestek, méér testcases kunnen worden uitgevoerd, die ook nog eens een betere ‘dekking’ (coverage) hebben. Wanneer de testen vaker en sneller uitgevoerd kunnen worden, kunnen de iteraties kleiner blijven en is het achterhalen van de bron van een fout aanzienlijk minder complex.

Bij dit project zag het management het probleem als een Quality Control-probleem: te weinig testtijd, te veel druk op het testteam. Er is daardoor te snel en met te weinig onderbouwing naar een oplossing gegrepen, zonder eerst goed te kijken naar de oorzaak van deze problemen. Er was te weinig aandacht voor de dagelijkse gang van zaken binnen het testteam en het team werd niet genoeg betrokken bij het verbeterproces. Daardoor bleef het team volledig in de QC-stand: brandjes blussen en problemen zo snel mogelijk oplossen zodra ze zich voordeden, in plaats van ze te voorkomen. De vaste testers, met de testlead voorop, waren al jaren gewend om bij elke release opnieuw dezelfde brandjes te blussen. Dat deden ze graag en keer op keer bewezen ze dat ze daar ook goed in waren; het was hun comfortzone. Automatisering zagen ze, al dan niet bewust, als een bedreiging: het zou hun dagelijkse werk fundamenteel veranderen. Na jaren van reactief de fouten van vandaag analyseren, zou automatisering diezelfde fouten juist in een vroeger stadium vinden; brandpreventie in plaats van brandbestrijding, waardoor de brand klein blijft of zelfs nooit ontstaat. Voor de “brandweermannen” was dat, na jaren in hetzelfde ritme, geen aantrekkelijk vooruitzicht. Ondanks dat het uiteindelijk rust, controle en efficiëntie zou opleveren voor zowel het team als het proces.

De les:Een goed proces optuigen is niet alleen een technisch vraagstuk. Het gaat net zo goed over mensen; niet iedereen is aan verandering toe of staat er voor open. Een oplossing voor een onduidelijke oorzaak en een team dat niet wordt meegenomen in het waarom, leiden zelden tot verandering die beklijft. Juist daarom zijn de STRAK-trajecten gefaseerd, met concrete evaluatiemomenten en met het team achter het stuur. Door het team zelfstandig het proces te laten bouwen, begrijpt het team welke keuzes er gemaakt zijn en waarom. Het zal verantwoordelijkheid nemen voor het proces en uiteindelijk zelfstandig aanpassingen in het proces kunnen implementeren, wanneer dat aan de orde is.

Door samen te werken met het team, en met focus op QA (Quality Assurance) te beginnen met het proces, ontstaat er een proactieve focus op het voorkomen van fouten voordat ze ontstaan. Een focus op gestandaardiseerde procedures en continue procesverbetering. Het gaat om de vraag: “hoe richten we het proces zo in, dat fouten niet ontstaan?”. Dat voorkomt uiteindelijk dat het testen van het (eind)product, QC (Quality Control), een te zwaar proces wordt.