Testen kan veel effectiever en efficiënter

Testen kan vaak veel effectiever en efficiënter. Met als bijkomend voordeel dat testtrajecten minder lang duren en dus goedkoper worden.

In de meeste dagelijks gebruikte elektronische producten zit software. In de elektrisch aangedreven Chevrolet Volt van General Motors zitten ongeveer tien miljoen regels code (loc). Ter vergelijking, in Windows 3.1 zaten er circa zes miljoen en in Windows Vista vijftig miljoen. In elke regel code kan een fout worden geïntroduceerd. Elk project, die al deze zaken realiseert, heeft beperkte middelen ter beschikking. Simpelweg alles testen kan niet. Dit zou te lang duren en kost (daardoor) te veel geld. Dat geldt tevens voor bijvoorbeeld je auto.

Hoe bepaalt de testmanager wat wel en niet getest wordt? Deze persoon is immers verantwoordelijk voor het testproces en geeft uiteindelijk een vrijgave advies voor de ingebruikname van het software product. Belangrijker is bovendien wat niet getest wordt. Per organisatie wordt bovendien anders tegen testen aangekeken. Er zijn (gelukkig) standaarden voor ‘safety critical’ systemen, zoals de DO-178 standaard voor de vliegtuigindustrie. Maar dan nog: je kent misschien nog het vliegtuig incident uit 2011 met een Airbus A330 waarbij 119 gewonden zijn gevallen ten gevolge van een software fout in de boordcomputer. Er zal dus een keuze gemaakt moeten worden wat wel en niet getest moet worden, en met welke diepgang.

Wel en niet testen

Door een testmanager kan een zogenaamde pra (product risico analyse) worden uitgevoerd. De scope van het project wordt onderverdeeld in een decompositie en per onderdeel uit deze decompositie wordt bepaald wat de kans is en de impact. Tezamen levert dit een product risico op (risico = kans x impact). Wanneer een onderdeel een groot risico heeft dan wordt er ‘uitgebreider’ (is duurder) getest. Het omgekeerde is tevens waar, minder risico betekent minder (diepgaand) testen en dit kost minder tijd en dus geld. Maar hoe vertaalt zich dit tot het testen? En, is het doel van testen om fouten te zoeken? Niet helemaal, het doel van testen is (tevens) om naast de productkwaliteit, inzichtelijk te maken welke productrisico’s op kunnen treden met in gebruik nemen van het product.  De product kwaliteit zegt iets over de mate waarin de software conform de specificaties is gebouwd.

Aan het eind van een project wordt een zogenaamd vrijgave advies gegeven door de testmanager. Testmanagers weten dat het halen van de deadline aan het eind van een project vaak erg belangrijk gevonden wordt. De motivatie hiervoor is vaak dat de marketing campagne start op een bepaald moment, en het kost geld om het product later in gebruik te nemen (time to market). Of men wil de concurrentie voor zijn zodat men eerder een product of dienst op de markt kan zetten. Het is de taak van de testmanager om een goed onderbouwd vrijgave advies te geven over wat wel en niet van het product conform de testbasis is (product kwaliteit), en welke productrisico’s er gemoeid zijn met het in gebruik nemen van het product. Hierdoor kan er een weloverwogen besluit worden genomen over het moment van ingebruikname van het product.

Effectief testen

Terug naar de pra: De onderdelen uit de pra met een hoog risico zullen getest worden met behulp van testtechnieken die een relatief groot deel van het product afdekken. Onderdelen met een laag risico worden getest met behulp van testtechnieken die slechts een (zeer) beperkt deel afdekken van het product. Het risico wordt, zoals beschreven, bepaald door de kans x de impact. De kans wordt bepaald door de ’technische impact’ in te schatten. Dat wil zeggen, met kenmerken als: de complexiteit, de grootte, het aantal interfaces en dergelijke die samen met stakeholders worden ingeschat. De impact wordt geschat met kenmerken als: business belang, financiële of imago schade, zichtbaarheid.

Een goede pra levert draagvlak op voor de testaanpak, en helpt de testmanager invulling te geven aan de testaanpak. De testers kunnen hun testgevallen van een prioriteit voorzien welke is afgeleid van de pra. Deze testers beginnen met het uitvoeren van de testen met de hoogste prioriteit. Als er geen tijd meer over is dan zijn de belangrijkste testen al uitgevoerd, en kan de testmanager aangeven welke delen van de decompositie van de pra nog niet ‘getest’ zijn. Er kan dan onderbouwd worden welke (product) risico’s het in gebruik nemen van het product opleveren wanneer nog niet alle testen afgerond zijn. Er kan dan beslist worden of het product dan in gebruik wordt genomen of dat er meer tijd wordt uitgetrokken voor het mitigeren van nog bestaande productrisico’s middels het voortzetten van de test uitvoer.

Efficiënt testen

Naast effectief testen, is het belangrijk om efficiënt te testen. De wet van Böhm (Software Engineering Economics. Englewood Cliffs, NJ : Prentice-Hall, 1981 ISBN 0-13-822122-7) zegt dat de kosten om fouten in de loop van de tijd op te lossen exponentieel oplopen. Het is zaak om zo vroeg mogelijk de fouten uit een product te halen. Het is belangrijk de regie te houden op de leverancier wdi de unit test (ut) en de systeem test (st) uitvoert. Dit zijn testsoorten die vroeg in het ontwikkeltraject gepositioneerd zijn en onder de verantwoordelijkheid van de leverancier worden uitgevoerd. De testmanager zal moeten zorgen dat de leverancier daar ‘het juiste’ afdekt en daardoor kan het totale testtraject veel goedkoper zijn. Wat ‘het juiste’ dan precies is, kan niet kort worden omschreven. Dat de test soorten van de leverancier ook conform de pra ingericht moeten zijn, mag duidelijk zijn.

Het is belangrijk om een leverancier te hebben die bereid is om een kijkje in ‘de keuken’ te geven, en mee wil werken aan het verbeteren van het kwaliteitsproces. Een goede relatie tussen de leverancier en de testmanager is hierin cruciaal. Vaak wordt het de testmanager niet gemakkelijk gemaakt aangezien de leverancier al is gekozen en de contracten reeds zijn getekend voordat een testmanager wordt ingeschakeld. Het is dan veel lastiger voor de testmanager om afspraken te maken met de leverancier.

Het mes snijdt hier echter wel aan twee kanten. Het is immers in het belang van een leverancier om een product op te leveren van een goede kwaliteit. Zelfs leveranciers zonder een volwassen kwaliteitsproces kunnen overgehaald worden tot kleine stapjes in de goede richting. Daarin moet de testmanager vooral beginnen bij zaken die er ‘echt’ toe doen en duidelijk uitleggen waarom bepaalde zaken van leveranciers verwacht worden en dat dit in het voordeel is van betreffende partij.

Efficiënt testen houdt ook in dat de testsoorten een minimale overlap hebben. Daarnaast is het belangrijk dat vroeg in het test traject de business en de beheer partij(en) betrokken worden. Ten eerste zullen zij hun input moeten geven aan het tot stand komen van de pra. Daarnaast is het belangrijk om samen met hen acceptatie criteria vast te leggen zodat duidelijk is op basis waarvan het product geaccepteerd gaat worden. De visie van de business- en de beheerpartij(en) worden natuurlijk meegewogen in het vrijgave advies. Deze partijen bepalen of de productkwaliteit van dat moment, of nog niet gemitigeerde productrisico’s, acceptabel zijn of niet.

Daarnaast is het belangrijk dat er op een goede manier reviews worden uitgevoerd met alle stakeholders op minimaal alle documentatie die gebruikt wordt als testbasis. En dat de verschillende soorten documenten goed ‘vertaald’ en op elkaar afgestemd zijn en dat deze compleet, en correct zijn. Daarmee is de kans groter dat de documentatie aansluit op de wens van de business en dat fouten vroeg uit de documentatie worden gehaald. Wanneer dit niet gebeurt, dan worden betreffende fouten pas veel later ontdekt en is het duurder om deze op te lossen.

Opvallend

Wat mij de laatste jaren opvalt, is dat in een aantal organisaties in diverse branches gemiddeld slechts een relatief klein percentage van de testmanagers een pra toepast. Er is de laatste jaren wel een langzame kentering ten goede te zien. Tevens heeft niet elke testmanager zelf in de modder gestaan, en zelf met testtechnieken gewerkt. Het is wel ‘de’ testmanager die de teststrategie moet bepalen. Een belangrijk onderdeel van deze strategie is een pra en de keuze in de juiste test-technieken.

Bovendien worden reviews niet altijd uitgevoerd, en worden er niet altijd (goede) afspraken gemaakt met leveranciers over het aantoonbaar maken van de kwaliteit van het (tussen) product dat men oplevert. Het is dan belangrijk om testmanagers vroeg in projecten te betrekken zodat bovengenoemde zaken opgepakt kunnen worden. En het is belangrijk dat de teststrategie gebaseerd is op de pra en dat zo vroeg mogelijk de belangrijkste fouten ontdekt worden. En dat niet te veel tijd wordt besteed aan het testen van zaken met weinig risico. Veel testtrajecten kunnen veel effectiever en efficiënter ingericht worden. Met als bijkomend voordeel dat testtrajecten minder lang duren en dus goedkoper worden, dat de productkwaliteit verbetert en dat de productrisico’s afnemen. Hierdoor neemt het draagvlak toe en de tevredenheid van de business en de beheerpartijen.