Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Testen kan veel effectiever en efficiënter

 

Computable Expert

ing. Benno Goede
Sr. Testmanager / Testconsultant, The Pancompany B.V.. Expert van Computable voor de topics Management, Datamanagement en Development.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4691469). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Een lesje testen zoals het hoort van iemand weet van de hoed en de rand. Ik deel de mening van Benno dat er te weinig gebruik wordt gemaakt van ontwikkelde testmethodieken. We hebben allemaal het certificaat gehaald, maar lijken de kennis daarna te laten voor wat het is. Jammer want daar zit zoals Benno aangeeft een grote efficiency winst.

Peter, je slaat de spijker op z'n kop. Het is een lesje testen.
Het artikel bevat een hoog theoretisch gehalte, en dat vind ik jammer.
Want ik herken dat relatief weinig pra's worden gemaakt, maar een constatering alleen en de theoretische onderbouwing waarom pra's nodig zijn is niet voldoende.
De volgende stap is dan een stuk analyse, waarom zien we dit gebeuren, om vervolgens door te zetten en handvatten aan te bieden dit proces te herkennen en daarop te kunnen anticiperen. Dit in combinatie met toepassingsgebieden in huidige projectvormen als Agile SCRUM, outsourcing, etc.

Ik hoop dat Benno hier dan ook een vervolg aan wilt geven. De aanzet is er immers al.

Benno, wat mij opvalt is dat je verhaal niet speciaal over ICT gerelateerde testen gaat.
Je zou het zomaar kunnen vertalen naar b.v. elektronica, autoindustrie of welicht een huishoudelijk apparaat. Eigenlijk ook niet zo vreemd natuurlijk.

Wel had ik gehoopt iets meer gedetalieerde ideeen van je te lezen hoe je zo'n testprocedure het verstandigste kunt aanpakken.
Ik heb zelf natuurlijk wel ervaring met technieken als extreme programming, waarin je aan unittesting doet (die testen zijn vaak significant ingewikkelder dan het deel dat het eigenlijke probleem afhandeld) maar echt veel meer weet ik er niet van.

Overigens allemaal heel mooi dat testen, de praktijk is toch eerder 'if it compiles, ship it'

Het verhaal van de PRA is mooi, maar let op dat de PRA het "efficiënt" testen niet in de weg zit.

Als tester van een in India ontwikkeld systeem werden we geconfronteerd met dat daar alleen de "belangrijke" fouten werden hersteld, zodat we de "onbelangrijke" fouten bij elke hertest weer konden rapporteren.
Onbelangrijke fouten als zondigen tegen GUI-standaards, lay-out, spelling, uitlijning, weergave van getallen en datums.
Bij elke hertest konden we dezelfde fouten weer registreren - met de hand, in Excel.

Uiteindelijk moeten de onbelangrijke fouten ook gecorrigeerd worden. Doe het meteen - dat scheelt de testers een hoop werk.
En kom niet met de smoes dat daar geen tijd voor is: *juist* deze onbelangrijke fouten zijn in geen tijd te herstellen.



Eeuh, wat is het verschil tussen risk based testing en dit hele verhaal?

PaVaKe, risk based testing zegt mij mogelijk nog minder.
Maar wat is er mis met een duidelijke productspecificatie, op basis waarvan een voorstel gedaan wordt van testcases, welk voorafgaande aan de acceptatietest door de klant eerst uitvoering geëvalueerd wordt ? Dit is de methode die ik uit de luchtvaart ken, zeer vervelend langdurig, arbeidsintensief werk dat ook nog eens erg veel specialistische kennis vereist.
Maar je haalt zo wel al in een vroeg stadium een hoop issues boven water, en dan heb ik het niet over (m.i.) totaal onbelangrijke onzin die de eerste de beste gebruiker al meteen bij het inschakelen van het systeem vaststelt.

Het woord efficiënt is een aantal keer genoemd, maar ik lees niets over automatisering van testen. Terwijl automatische testen juist de enige manier is om niet alleen testen efficiënt te laten verlopen, het is ook de enige manier om testen doelmatig te (effectief) laten zijn.

@Pascal: risk based testing is (bij mijn weten) een algemene term die onder andere in gebruik is bij ISEB/ISTQB gcertificeerde testers.

Benno:

Quote uit de introductie: "Echter niet alle software wordt getest en veel wordt direct in de markt gezet. Met alle gevolgen van dien."

Ik ben benieuwd of je hiervoor een bronvermelding hebt, want dit is regelrechte onzin.



Risk based testing is juist het testen gebaseerd op de risico's die door middel van een Product Risico Analyse (PRA) worden vastgesteld. Dat het theoretisch goede idee de uit te voeren testen te baseren op de geïnventariseerde risico's in de praktijk vaak niet wordt gebruikt / uit de verf komt, heeft naar mijn idee vooral te maken met:

* de situatie die vaak voorkomt dat wel een product risico analyse gedaan wordt, maar het resultaat ervan niet meer wordt onderhouden en niet (pro-)actief wordt gebruikt om aan de uitgevoerde testen te relateren. Het wordt een risico administratie ipv risico management

* de behoefte aan zekerheid en de angst fouten te maken. Testers hebben over het algemeen een hoog ontwikkeld gevoel voor kwaliteit. Het is tegennatuurlijk om dan aan bepaalde onderdelen minder aandacht te besteden. Het gevoel aan alle aspecten aandacht gegeven te hebben, levert meer gemoedsrust dan aan de risicovolle functionaliteit heel veel aandacht te geven en aan minder risicovolle functionaliteit weinig of geen aandacht.

* de ongenuanceerdheid waarmee fouten in productie worden beoordeeld. De neiging is al snel "er is niet goed (genoeg) getest" te roepen als er iets fout gaat. De volgende drie vragen zouden gesteld moeten worden om tot fundamentele testverbetering te komen:
1) had deze fout - gegeven de teststrategie gevonden moeten worden?
2) als 1 = ja:
2a) in welke testsoort had deze gevonden moeten worden?
2b) wat is de reden dat deze niet is gevonden?
3) als 1 = nee:
3a) was de teststrategie goed(gezien risico en impact)?
als 3a = ja: "leef met de consequentie van je keuze"
als 3a = nee:
3b) hoe moet de teststrategie worden bijgesteld?

Een dergelijke analyse wordt in de praktijk weinig toegepast.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×