Het VNSG Magazine, het vakblad voor alle SAP gebruikers in Nederland en Vlaanderen, verschijnt 5 keer per jaar. PTWEE geeft in iedere editie een praktische tip over testen in een SAP omgeving. Deze tip gaat over de reductie van herstelkosten door fouten eerder op te sporen.
Onderzoek van professor Barry Boehm leidde eind jaren 70 al tot de onderbouwing dat de kosten om softwarefouten te herstellen exponentieel toenemen naarmate deze fouten later in een ontwikkeltraject worden vastgesteld. Opmerkelijk genoeg wordt het bewijs voor deze theorie ruim 30 jaar later in diverse SAP projecten nog regelmatig geleverd.
Stelt u zich eens voor dat u uw keuken gaat vervangen door een gloednieuwe keuken die van alle gemakken is voorzien. Na zorgvuldig afwegen, passen en meten maakt u met de keukenleverancier een keuze voor de indeling, de kastjes en de grepen, de apparatuur en het aanrechtblad. Het geheel wordt door de leverancier keurig vastgelegd in een ontwerp. Aangezien de indeling compleet anders is vergeleken bij de oude keuken worden electra-, gas- en waterleidingen verlegd en netjes in de muur gefreesd. Nadat ook de stukadoor de muren heeft gladgestreken kan de keuken worden geplaatst. Als men klaar is met de tegels en voegen zet u de kraan open en constateert een lage waterdruk. Boven de afzuigkap ontstaat op de muur een steeds groter wordende donkere plek…
Uiteraard hoeven er geen onderzoekers aan te pas te komen om aan te tonen dat het slimmer was geweest om direct na het leggen van de waterleidingen te controleren op lekkages. Daarnaast is het ook een goed moment om te toetsen of de stopcontacten en aansluitingen op de juiste plaats zitten conform het ontwerp. De herstelkosten voor het oplossen van fouten zijn in deze fase immers nog relatief laag.
Een gemiddeld SAP project is vanzelfsprekend een stuk complexer dan een keuken. Toch zijn er twee kleine maatregelen die ook in een SAP project grote (herstel)kosten kunnen voorkomen.
Bovenstaande figuur laat de ‘Wet van Boehm’ zien, afgezet tegen de ASAP fasering. De herstelkosten van een fout geconstateerd in de Blueprint fase is bijna verwaarloosbaar vergeleken bij fouten na Go Live.
Een van de problemen in het voorbeeld van de keuken is dat het zwaartepunt van de ‘foutopsporing’ pas relatief kort voor Go Live ligt. Ook in een SAP traject ligt het zwaartepunt veelal bij de gebruikersacceptatietest. Een eerste goede maatregel is om het accent meer te leggen op de systeemintegratietest. Door al in deze testfase gestructureerd en op basis van risico’s te testen (zie ook de vorige VNSG tip over de Productrisicoanalyse) is het mogelijk om de fouten met de grootste schade het eerste in kaart te krijgen en te verhelpen. Fouten met grote (gevolg)schade zijn veelal ook de fouten die de grootste herstelkosten met zich mee brengen.
De tweede maatregel is om testers al vroeg in het SAP traject aan te haken, bij voorkeur al in de Blueprint fase. Op deze manier kan de ontwerpdocumentatie worden bekeken op testbaarheid. Denk aan zaken als niet meetbaar of concreet omschreven requirements, ruimte voor verkeerde interpretatie in functionele ontwerpen of begripsverwarring worden gesignaleerd en verholpen ruim voordat de leverancier is gestart met ontwikkelen. Ook kunnen testers tijdens workshops al use cases of logische testscripts opstellen en deze toetsen.
Zorg dus dat de teststrategie van uw SAP traject is opgezet om een zo vroeg mogelijke foutopsporing te bereiken. Het vroeg aanhaken van testers verscherpt bovendien de ontwerpdocumentatie, wat weer kan leiden tot een soepeler ontwikkeltraject. Zo kunt u voorkomen dat u vlak voor Go Live nog dweilt met de kraan open!
