“Hoeveel testen is voldoende?” Dit is een veelgehoorde vraag binnen software development. En een terechte vraag. Immers, het testen van software geeft vertrouwen om het product in gebruik te nemen en het toont aan dat het opgeleverde systeem voldoet aan de vooraf gestelde eisen. Daarnaast kan het releasen van foutieve code voor sommige organisaties desastreus zijn, bijvoorbeeld wanneer klanten van een webshop vanwege een storing een hele dag niet kunnen betalen. Maar hoe bepaal je nu wanneer er voldoende is getest en alle seinen op groen kunnen?
Helaas is er niet één passend antwoord op die vraag. Wel zijn er enkele belangrijke aandachtspunten en best practices die helpen bij het opstellen van een teststrategie. Hiermee kun je vaststellen wanneer een systeem voldoende is getest.
100% testen is niet haalbaar
Een logische gedachte: als we veel testen, kunnen we ervan uitgaan dat de software geen fouten bevat. Toch blijkt in de praktijk vaak dat hiervoor niet voldoende middelen beschikbaar zijn: er zijn simpelweg teveel combinaties en scenario’s te bedenken om alles volledig te kunnen testen en afdekken. Daarnaast wordt in veel organisaties dagelijks nieuwe code geïmplementeerd. Dan zou je dus na het volledige testproces alles weer opnieuw moeten uitvoeren. Een test coverage van 100% is dus niet altijd haalbaar of zelfs nodig.
Dat neemt niet weg dat in specifieke situaties de gewenste dekkingsgraad van een test veel hoger is dan in andere gevallen. Belangrijk is vooral te kijken naar het doel: waarvoor wordt het product gebruikt? En wat zijn de risico’s? Voor het testen van bijvoorbeeld software in vliegtuigen of medische apparatuur is een hogere dekkingsgraad nodig, dan bij het checken van een nieuwe functionaliteit voor het aanmaken van een gebruikersaccount bij een webshop.
Voer een productrisicoanalyse uit
Bepalen wat de juiste test coverage is begint met een goede voorbereiding. Door middels een productrisicoanalyse vast te stellen wat de meest risicovolle elementen van het systeem zijn en in gesprek te gaan met alle belanghebbenden (stakeholders, business analisten, developers, testers, etc.), kunnen de meest kwetsbare onderdelen van het systeem in kaart gebracht worden. Als deze risicoanalyse zwart op wit staat, vindt er afstemming plaats over de diepgang van het testen en worden de beschikbare resources besteed aan de meest belangrijke onderdelen van het systeem. Doordat alle partijen betrokken zijn bij het opstellen van de risicoanalyse, ontstaat een breed gedragen aanpak voor het volledige ontwikkelproces.
Begin zo vroeg mogelijk in het proces met testen
Testen wordt vaak ten onrechte gezien als de laatste fase in het software development-proces. Dit zorgt ervoor dat fouten soms te laat worden gevonden. Dikwijls loopt dan de hele planning vertraging op. Fouten herstellen en lokaliseren is daarnaast een stuk lastiger als ze worden gevonden na de oplevering van een grote hoeveelheid code. Testen zou daarom niet moeten worden gezien als een fase, maar als een continu proces om kwaliteit te realiseren.
Testen hoeft ook niet alleen te worden belegd bij testers. Ook developers kunnen hun steentje bijdragen aan het opleveren van kwalitatief goede software door hun eigen code te testen. Bijvoorbeeld door het uitvoeren van code audits of unittests, waarbij softwaremodules of stukjes broncode (units) afzonderlijk worden doorlopen en getest.
Testvariaties
Is het mogelijk om de te testen software te gebruiken op verschillende devices? Zijn er koppelingen met andere systemen? Welke data wordt gegenereerd en waar moet deze aan voldoen? Vaak kunnen niet al deze vragen met één testsoort worden gecontroleerd. Door het toepassen van de juiste combinatie van testen (zoals een functionele acceptatietest, unittest etc.) en het inzetten van testontwerptechnieken (zoals een semantische test of een use case test), worden gerichte testgevallen afgeleid. Hiermee kunnen specifieke fouten worden gevonden.
Overleg en documenteer
Door met elkaar het gesprek aan te gaan en te documenteren wat en hoe grondig getest moet worden, ontstaat een startpunt voor het gehele testproces. Begin dit testproces niet pas aan het einde van het ontwikkeltraject, maar zorg dat zowel testers als developers in een vroeg stadium de (deel)producten checken. Achteraf fouten ontdekken levert namelijk vertraging op en kan tot veel frustratie leiden. Zorg daarnaast voor een verscheidenheid aan testen. Alleen met de juiste combinatie van verschillende inzichten kom je tot een veilig en kwalitatief goed product.
Er is online veel te vinden over testplannen, strategieën en best practices, of misschien heb jij goede ervaringen met een bepaalde aanpak. Ik ben benieuwd naar jouw aanvullingen of opmerkingen. Mail ze naar info@computest.nl.
Linda van Duijn
