In het artikel ‘Testen software nog altijd sluitpost’ (Computable, 7 oktober 2005) wordt software testen en ‘controleren op de gevolgen voor de bedrijfsvoering’ gelijk getrokken. Dit is echter niet hetzelfde. Software testen is typisch het verifiëren dat software doet wat het belooft te doen.
Foutloze software (als het zou bestaan) hoeft niet goed te zijn voor de bedrijfsvoering. Het artikel verwart quality assurance met software testen. Deze spraakverwarring is ons inziens juist de oorzaak van het gesignaleerde probleem: “Testen software nog altijd sluitpost”.
Bij onze klanten signaleren we inderdaad dat het testen van software een aparte taak is, die zoveel mogelijk apart van het bouwtraject wordt gehouden en achteraf wordt uitgevoerd. Testen is letterlijk en figuurlijk de sluitpost. Software testen wordt zo een activiteit die de veranderbaarheid van software in de weg zit: het opnieuw testen na wijzigingen kost veel tijd en geld. Gewenste wijzigingen worden daarom of slecht getest, wat een risico is voor de kwaliteit van het eindproduct, of achterwege gelaten omdat implementeren en testen te duur is. De gevolgen voor de bedrijfsvoering worden op de koop toe genomen.
Het artikel geeft ook een oorzaak voor het gesignaleerde probleem: “Doordat it-managers de verantwoordelijkheid op zich nemen zonder een acceptabele ondersteuning van de commerciële afdeling, heeft men vaak een gebrek aan de juiste testmiddelen en testcapaciteit”. Dit is waar, maar tegelijkertijd onderdeel van het probleem, niet van de oplossing.
Door quality assurance, software testen en software accepteren als één activiteit te zien, die na de eerste oplevering van de software wordt uitgevoerd en na elke oplevering herhaald, zijn de doorlooptijd en kosten van het software proces niet meer te managen. De oplossing is zoals bijna altijd: opsplitsen van het probleem. Software testen is maar één onderdeel van quality assurance, maar traditioneel wel het meest arbeidsintensieve onderdeel. Software testen is bovendien een onderdeel waar op een eenvoudige manier veel winst valt te behalen. Enkele constateringen kunnen daarbij helpen.
Hoe eerder je begint met testen, en daarmee dus problemen signaleert, hoe minder kosten er verbonden zijn aan het oplossen van die problemen.
Testen is, na het opstellen van een testplan, een repetitieve taak. Een deel van de testtaak is bijvoorbeeld het handmatig starten van de applicatie, openen van schermen, velden invullen en de resultaten controleren tegen vooraf vastgestelde verwachte waarden. Bij uitstek een taak waar computers goed in zijn.
Daarbij geldt dat je de tests zo vaak mogelijk wilt herhalen. Elke wijziging, hoe klein ook, in software, kan onverwachte problemen veroorzaken in andere onderdelen van een systeem. Herhaling van acties is iets waar computers goed in zijn. Een testteam vraag je niet alle tests opnieuw uit te voeren bij een kleine last-minute aanpassing, er is dan simpelweg niet genoeg tijd.
De teststrategie moet niet focussen op het eindproduct als geheel, maar beginnen bij de kleinste onderdelen van de software: unit-testen. Unit-tests zijn eenvoudig te automatiseren, en de kwaliteit van deze tests is goed objectief te meten. Unit-tests zijn daarnaast vanaf de eerste minuut dat er code ontwikkeld wordt in te zetten. De aanwezigheid van automatische unit-tests zorgt ervoor dat de testinspanning voor een acceptatie test veel minder hoeft te zijn.
Tot slot moeten programmeurs veel meer betrokken worden bij testen. Het blijkt in de praktijk dat programmeurs die hun eigen unit-tests schrijven beter testbare en minder complexe software produceren. Daarbij geldt dat ontwikkelaars de programma units die zij ontwikkelen toch al moeten testen. Het herhaalbaar maken van zulke tests door ze te programmeren kost weinig extra, maar levert wel op dat de tests altijd uit te voeren zijn.
Quality assurance is voor een groot deel mensenwerk. Maar dat ene onderdeel daarvan dat zoveel tijd en geld kost – testen – kan voor een deel geautomatiseerd worden. Er is tegenwoordig veel standaard tooling beschikbaar voor het maken, onderhouden en beoordelen van automatische unit-tests, user interface tests en regressie tests. Het toepassen van deze tooling waarborgt de kwaliteit van de applicatie met de spreekwoordelijke druk op de knop. Dit betekent niet dat er geen testers meer nodig zijn, maar mankracht is beter gespendeerd aan onderdelen van quality assurance die niet makkelijk te automatiseren zijn, zoals:
opstellen van een QA strategie; implementeren (coderen) van unit-tests en andere automatiseerbare tests; testen van usability-aspecten; beoordelen van de gevolgen voor de bedrijsfvoering en efficiëntie.
Door een grotere nadruk te leggen op het in vroeg stadium beginnen met testen van kleine units en onderdelen van een systeem, en het automatiseren van een belangrijk deel van de testinspanning, kan software sneller, doeltreffender en goedkoper aangepast worden. De acceptatie van gewijzigde software wordt daarmee eenvoudiger en goedkoper. Wijzigingen kunnen zonder dure en arbeidsintensieve acceptatie tests geaccepteerd worden.
Kortom, om ervoor te zorgen dat software veranderbaar blijft, moet de teststrategie aangepast worden. Er moet meer nadruk komen op automatiseerbare tests, die eenvoudig te herhalen zijn en waarvan de kwaliteit objectief is vast te stellen. Dit betekent dat tests vaker uitgevoerd kunnen worden, problemen eerder gesignaleerd worden, de software beter onderhoudbaar en sneller aanpasbaar is, de test- en ontwikkelkosten afnemen en last-but-not-least er simpelweg betere software wordt gemaakt. Quality assurance is mensenwerk, maar het testen van de software kunt je beter door de computer laten doen.
Gerjon de Vries, Tobias Kuipers, Software Improvement Group
