In onze eerdere blogs is aangegeven dat het efficiënt functioneel testen binnen SAP-projecten leunt op de juiste volgorde van de deelgebieden: inrichting, conversie, interfaces, rapportages, keten acceptatie en productie acceptatie. Deze tip gaat in op het vierde deelgebied: Rapportages.
- Inrichting
- Conversie
- Interfaces
- Rapportages
- Keten acceptatie
- Productie acceptatie
Rapportages
De rapportages zijn het sluitstuk van de functionele opleveringen binnen een SAP-project en daardoor test technisch gezien het meest efficiënt te testen als de voorgaande deelgebieden niet meer (of nog maar minimaal) wijzigen. Dit komt omdat de rapportages gevoed worden vanuit de bronsystemen. Deze brondata wordt onderling door de gekoppelde systemen via de interfaces uitgewisseld en komt tevens via interfaces en het ETL-proces (Extract Transfer & Load proces) in de vorm van rapportages beschikbaar. Het is dan ook niet moeilijk om in te zien dat een wijziging in één van de drie voorgaande deelgebieden direct impact kan hebben op de inhoud van de rapportages.
Testen van bestaande rapporten bestaat uit het vergelijken van de rapporten uit het oude systeem met de rapporten vanuit het nieuwe systeem (na datamigratie). De inhoud van de oude en de nieuwe rapporten moet exact aan elkaar gelijk zijn. Uitzonderingen hierop zijn de verschillen welke veroorzaakt worden door:
- De conversieregels. Dit betreft data die bewust niet mee gemigreerd wordt naar het nieuwe systeem.
Voorbeelden hiervan zijn: - Hele oude data die niet meer noodzakelijk is.
- Data die door gewijzigde functionaliteit van het nieuwe systeem ten opzichte van het oude systeem niet gemigreerd kan worden. Als het goed is, is dit bij het vaststellen van het nieuwe datamodel al inzichtelijk.
- Uitval tijdens de conversie. Dit betreft data die, buiten de conversieregels om, onbedoeld is uitgevallen. Deze uitval moet dan wel geaccepteerd zijn anders betreft het een nieuwe conversie bevinding.
Rapporten vergelijken is een redelijk eenvoudige test. De moeilijkheid zit hem in de interpretatie van de eventuele verschillen. Hierbij moet geanalyseerd worden of deze verschillen terecht of onterecht zijn. Bevindingen kunnen de volgende vijf hoofdoorzaken hebben:
- Een fout in het bronsysteem (software of inrichting).
- Niet gecommuniceerde aanpassing(en) van het bron systeem.
- Foutieve brondata, veroorzaakt door conversie.
- Een fout in de interfaces tussen de betrokken systemen.
- Een fout in het ETL-proces en/of de rapportagetool die ten grondslag ligt aan het genereren van de rapportages.
Let op! Misschien is het wel een combinatie van deze mogelijke hoofdoorzaken. Meerdere oplossingsmogelijkheden zijn vaak van toepassing waardoor samenwerking met de verschillende expertises zoals onder andere: functioneel beheer, ETL-ontwikkelaar, conversie consultant, SAP consultant en business noodzakelijk is.
In de meeste gevallen moeten door de wijzigingen van de functionaliteit van het bronsysteem tevens hele nieuwe rapportages ontwikkeld worden. Het testen van deze rapportages is op voorhand ingewikkelder dan het testen van reeds bestaande rapportages. Dit komt omdat het kader waartegen getest wordt bestaat uit specificaties. Het handige controlemiddel van een bestaand rapport uit de oude situatie is niet voorhanden. Nieuwe rapportages moeten op inhoudelijke juistheid tegen de bron getest worden. Zeker de meer ingewikkelde rapportages kunnen alleen met business support goed getest en beoordeeld worden. De teststrategie voor het testen van compleet nieuwe rapportages is te veelomvattend om hier verder te beschrijven, in de toekomst zullen we hier een nieuwe blog aan wijden.
Functionaliteit, conversie en interfaces hebben invloed op de inhoud van de rapportages. Elke aanpassing kan direct gevolgen hebben voor de inhoud of generatie van de rapportages. Juist hier is het weer van cruciaal belang dat de voorgaande deelgebieden onafhankelijk goed getest zijn en nagenoeg geen bevindingen meer bevatten. Alleen dan kan de vicieuze cirkel van testen en hertesten voorkomen worden. Bovendien zit hier een groot gevaar op inefficiënte inzet van de ETL-ontwikkelaars. Indien wordt gestart met de ontwikkeling van de ETL-programmatuur en de ontwikkeling van de rapportages (bestaand en nieuw) terwijl de functionaliteit, inrichting, conversie en interfaces niet eenduidig vastliggen is de kans op rework gegarandeerd. Rework betekent in dit geval verspilling van tijd en middelen.
Een ander aspect van inefficiëntie zit bij het testen op regressie. Elke aanpassing in één van de deelgebieden betekent een reële kans op regressie binnen één of alle deelgebieden. Herhaaldelijk regressietesten is het gevolg. Het komt vaak voor dat met het testen van rapportages bevindingen geconstateerd worden die tijdens het individueel testen van de voorgaande deelgebieden over het hoofd zijn gezien. Eigenlijk moeten deze bevindingen eerder gevonden worden maar door tijdsdruk en het afwijken van de juiste volgorde van de deelgebieden is dit meer regelmaat dan uitzondering. Bij het oplossen van deze bevindingen moet de impact op de al uitgevoerde testen bepaald worden en moet er mogelijk aanvullend getest worden. Dit om het risico op regressie tot een minimum te beperken. Geautomatiseerd regressietesten is hier vaak geopperde toverwoord. Maar ook hier wordt dan onnodig veel tijd geïnvesteerd in het aanpassen van de geautomatiseerde regressietestscripts en het analyseren van de bevindingen.
Het op de juiste wijze dirigeren van de opleveringen en de daaraan gekoppelde teststrategie zorgt voor een efficiënt en effectief SAP-project. De ervaren testmanager kan zich juist op dit vlak onderscheiden en is daarmee van enorme meerwaarde bij complexe en dynamische SAP-projecten.
In de volgende tip wordt het efficiënt testen van het testdeelgebied-5 ‘Keten Acceptatie’ verder uitgediept.
PTWEE helpt SAP gebruikende bedrijven beter en slimmer te testen en hanteert daarbij een pragmatische aanpak. Deze blog is opgesteld door Henk van de Wardt, SAP Testmanager bij PTWEE, en is onderdeel van een reeks over testmanagement in SAP projecten. Heeft u behoefte om vrijblijvend met ons van gedachten te wisselen over uw testuitdagingen? Neem dan contact op met Roel van Bremen op info@ptwee.nl of via 073 711 45 20.
