Testing & Quality Assurance is al lange tijd een ondergeschoven kindje: bij veel organisaties is niet of nauwelijks sprake van een professionele en geïnstitutionaliseerde teststrategie, -aanpak en -organisatie. Om greep te krijgen en te houden op de zo belangrijke user en customer experience is het nodig stappen te zetten om te komen tot een meer volwassen approach van testen. In deze blog presenteren we de verschillende fasen die een bestaand bedrijf doormaakte om te komen tot een hoog niveau van testen en kwaliteitsborging.
In dit digitale tijdperk zijn twee trends van grote invloed op het vakgebied van testen en kwaliteitsborging: de eerste is agile development, de tweede is de sterke focus op de user/customer experience. De drang naar reductie van time-to-market van software en systemen, en de toepassing van agile softwareontwikkeling bevorderen een optimale gebruikers- en/of klantervaring, maar zijn daar niet uit zichzelf een garantie voor. Het grondig testen van (elk gedeelte van) nieuwe software is de enige manier om de kwaliteit van in productie te nemen systemen te borgen. Dit betreft zowel het aansluiten op de gevraagde functionaliteit, de gebruiksvriendelijkheid alsmede de performance van de opgeleverde software.
Op reis naar foutloosheid
Om begrip te krijgen van de problemen rondom testen en kwaliteitsborging, volgen we de reis die een bestaande onderneming daadwerkelijk in de praktijk maakte van het nulpunt (geen geïnstitutionaliseerde testing) naar een aanzienlijk hoger niveau van maturity op het gebied van testen. De kenmerken van elke fase worden kort beschreven alsmede de manier waarop gekomen is tot de volgende stap. Tijdens de reis zijn twee modellen als gids gebruikt. Aan de hand van het Testing Maturity Model (TMM), ontwikkeld door het Illinois Institute of Technology, zijn de verschillende stadia afgemeten en is de verdere koers bepaald.
Fase 1. Geen dedicated test engineer
Bij de aftrap van een ontwikkelingsproject is er geen enkele focus of visie op testen. Er is ook geen speciaal aangestelde tester. De developer test zijn eigen modules, soms testen de ontwikkelaars elkaars modules. Het doel van dat testen is minimaal, namelijk aantonen dat de software werkt. Belangrijkste nadeel van deze aanpak is dat de kwaliteit van de software erg laag blijft op aspecten zoals performance en de customer experience. Er zijn ontelbare ‘field errors’ (in één geval zelfs meer dan 300!), en in één module worden twee jaar na de oplevering nog steeds bugs gevonden.
Fase 2. Er wordt alsnog een dedicated test engineer aangesteld
Terwijl het project al vijf maanden loopt besluit het management alsnog een speciale testengineer te benoemen. Direct vanaf dat moment is er een verbetering zichtbaar in de kwaliteit van de producten, voornamelijk door de onafhankelijkheid van de tester ten opzichte van de ontwikkelaar. De tester schrijft een testplan en testcases, en voert zijn activiteiten uit op afzonderlijke aan hem toegewezen machines. Het aantal fouten – hoewel in vergelijking tot eerder al aanzienlijk minder – blijft nog steeds aan de hoge kant. Dat komt met name doordat de testengineer niet voldoende kennis heeft van alle requirements van het product, omdat hij er immers pas later bijgehaald is. Het tweede probleem is het ontbreken van voldoende tijd voor planning en ontwerp, wat gevolgen heeft voor het soort testen dat de testengineer ontwikkelt en uitvoert.
Fase 3. Een dedicated test engineer vanaf de start
Tijdens deze periode besluit het management om de tester bij volgende projecten eerder in de planning op te nemen, zodat hij ook al in de requirementsfase betrokken is bij het project. De tester bereidt een gedetailleerd testplan en een gedetailleerde lijst van testcases voor.
Hoewel dit toch weer een aanzienlijke verbetering in de kwaliteit te zien geeft, blijven er nog genoeg problemen over. Belangrijkste struikelblok is dat de tester rapporteert aan de projectmanager, en hij dus geen stem heeft bij releases. Omdat de projectmanager verantwoordelijk is voor testen, kan hij besluiten de testtijd in te korten om zo elders verloren gegane tijd in te halen en de aan de gebruikers beloofde releasedatum te halen. Bovendien heeft de projectmanager al genoeg aan zijn hoofd om zich ook nog intensief bezig te houden met aan testen gerelateerde zaken.
Een ander issue is het ontbreken van een standaard manier van foutenrapportages. Op verschillende momenten worden verschillende manieren gebruikt, zoals e-mails, spreadsheets en documenten.
Er is nog geen centrale pool van testers, en geen geconsolideerde ‘repository of knowledge’ waar testers informatie kunnen delen.
Fase 4. Een dedicated testmanager en een centraal testteam
Het management wil verdere verbetering van de resultaten bewerkstelligen en de genoemde problemen aanpakken. Dat gebeurt door de vorming van een afzonderlijk testteam onder leiding van een testmanager. De testengineers rapporteren aan de testmanager; het team is verantwoordelijk voor testen van alle producten die uit de ontwikkelgroep komen. De testmanager bestudeert eventuele problemen en knelpunten, en bepaalt de prioriteiten.
Deze aanpak resulteert in een aanmerkelijke verbetering van de kwaliteit – en van het moreel in het team, en meer engineers krijgen interesse in een baan als tester. In het centrale testteam wordt een herbruikbare repository van testcases ontwikkeld. Er kunnen eventueel – tijdelijk of vast – extra testers aan bepaalde projecten worden toegewezen.
Ondanks dit blijven er nog steeds problemen en issues die moeten worden opgelost.
Fase 5. De droom komt bijna uit
In deze fase van de journey komt de droom van foutloosheid in zicht, maar kan nog steeds niet bereikt worden. Een van de belangrijkste problemen is het herhaaldelijk crashen van de testplanning, wat vooral komt doordat testen nog steeds aan het eind van de project lifecycle zit, en de planning voortdurend te maken heeft met uitloop in andere fasen van het ontwikkelingsproces.
Hinderlijk is dat de testmanager herhaaldelijk wordt gevraagd om managers en bestuurders de voordelen en kostenbesparingen van een centraal testteam aan te tonen.
Op dit moment werkt het bedrijf aan het oplossen van deze issues, om zodoende de stap te maken naar het hoogste niveau van Testen & Kwaliteitsborging.
Tot slot
Om de kwaliteit van nieuwe software te kunnen garanderen en grip te krijgen en te houden op de user/customer experience, is continu aandacht nodig voor de bij het testen gebruikte processen en technieken. Naast een sterk commitment van het senior management, is daarbij de inrichting van een dedicated centrale testgroep onder leiding van een onafhankelijke testmanager een cruciale succesfactor. Elke organisatie kan voordeel behalen uit het toepassen van een combinatie van de modellen TMM en TPI, Test Process Improvement. Wellicht ten overvloede: het bereiken van een bepaald hoger volwassenheidsniveau mag niet een doel op zich worden; de focus moet liggen op het realiseren van een relevante kwantitatieve en kwalitatieve verbetering in de dagelijkse performance.
Timo Fine, Manager Benelux Wipro Technologies
