In de vorige 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 blog gaat in op het derde deelgebied: het testen van de interfaces met SAP.
Deelgebieden:
- Inrichting
- Conversie
- Interfaces
- Rapportages
- Keten Acceptatie
- Productie Acceptatie
Interfaces
Een veel voorkomende praktijksituatie is dat de inrichting en de conversie nog verre van gereed zijn en nog worden doorontwikkeld op basis van testbevindingen waarbij gelijktijdig gestart wordt met het functioneel testen van de SAP interfaces.
Door deze gelijktijdigheid komt het SAP-project gegarandeerd in de vicieuze cirkel van testen en hertestenterecht (zie ook de voorgaande tips uit deze reeks).
Dit komt doordat het wijzigen van een veldinhoud vanuit de inrichting en/of datawijziging vanuit conversie direct gevolgen kan hebben voor de samenstelling van de berichten welke via de interfaces worden uitgewisseld. Het analyseren van bevindingen wordt in dit voorbeeld een complexe en tijdrovende activiteit. Er moet namelijk uitgezocht worden of de bevinding door de inrichting, de conversie of foutief werkende interface programmatuur veroorzaakt wordt. Bovendien resulteert deze werkwijze in onnodig (veel) rework. Door de interfaces te ontwikkelen en te testen op een meer stabielere basis van inrichting en conversie kan het onnodige rework grotendeels voorkomen worden en is de oorzaak van de bevinding sneller en eenduidiger te bepalen.
Conclusie; SAP interfaces zijn pas volledig goed en eenduidig te ontwikkelen en te testen als je weet welke data tussen de systemen uitgewisseld moet gaan worden. Hierbij is het cruciaal dat de inrichting en de conversie stabiel zijn.
Natuurlijk moeten de interfaces voorafgaand aan de functionele testen onafhankelijk van elkaar met onder andere simulatie software zoals stubs/drivers getest worden. Deze testen zorgen ervoor dat de interfaces bij aanvang van de functionele testen daadwerkelijk technisch en functioneel werken.
Het testen van SAP interfaces vereist een specifieke testaanpak. Een ogenschijnlijke kleine aanpassing in één applicatie kan grote gevolgen hebben voor de verwerking binnen de keten. Dit maakt een keten georiënteerde productrisicoanalyse noodzakelijk. De teststrategie en de keten regressietest moeten hierop gebaseerd worden. Dit is echter niet het enige specifieke aandachtspunt.
Top 6 Aandachtspunten bij het functioneel testen van SAP interfaces
- Architectuuroverzicht en datamodel van het applicatielandschap en datastromen moeten beschikbaar zijn.
Reden: Voor de teststrategie is het van belang dat duidelijk is welke data op welke wijze door de systemen uitgewisseld gaat worden - Keten georiënteerde product risicoanalyse moet uitgevoerd worden. De teststrategie en keten regressietest dienen hierop afgestemd te worden.
Reden: Het is onmogelijk en niet in verhouding om bij een kleine wijziging in de keten alle betrokken applicaties volledig opnieuw te testen. De risico gebaseerde teststrategie inclusief bijbehorende keten regressietest maakt het mogelijk de juiste zaken met de juiste inspanning en bijbehorende testdekking te testen. - Interface documentatie zoals functioneel ontwerp, technisch ontwerp en mappingsdocument (van de gegevensstromen) moeten door de betrokken stakeholders gereviewd en geaccordeerd zijn.
Reden: Het zogenaamde statisch testen (reviewen) heeft enorm positief effect op het vroegtijdig constateren van bevindingen. Grote winst bij interface testen zit in het reviewen van het mappingsdocument. Deze kan in zijn geheel statisch getest worden waardoor uitval van berichten op de berichtenvalidatie tijdens de testen niet meer voor hoeft te komen. - Eenduidig gedefinieerde acceptatiecriteria moeten door de betrokken acceptanten worden opgeleverd. Hierbij worden security- en performance criteria expliciet benoemd.
Reden: Het is van belang dat de data eigenaren en beheerders (technisch en functioneel) bekend zijn zodat deze bewust betrokken worden bij het testen en accepteren van de dataverwerking binnen de keten. Omdat de data zowel intern als extern door de keten beweegt kan het zijn dat de data van eigenaar en dus van acceptant wijzigt. - Gebruikersacceptatietestomgeving met:
A.Fysiek gekoppelde interfaces inclusief beveiligingscertificaten.
B. Ingerichte berichten validatie.
Reden: De testen dienen zo realistisch mogelijk uitgevoerd te worden; alleen dan kan de performance binnen de keten representatief beoordeeld worden. Het beschikbaar hebben van fysieke koppelingen mag daarbij niet ontbreken. Ontwikkelteams testen veelal de happy flow waarbij de berichten validatie wordt uitgezet. Indien de berichtenvalidatie in de acceptatieomgeving niet wordt aangezet loopt men in productie tegen verstoringen aan die in test gevonden hadden moeten worden. - Security- en performancetest als extra test inrichten.
Reden: Indien uit de product risicoanalyse blijkt dat beveiliging en/of performance grote risico’s vormen is het aan te raden een separate securitytest en performancetest uit te voeren.
De combinatie van de juiste volgorde en bewust omgaan met de top 6 van de interface specifieke aandachtspunten zorgen voor een efficiënt en effectief interface testtraject waarbij het SAP-project niet in de vicieuze cirkel van testen en hertesten belandt.
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 blog wordt het efficiënt testen van het testdeelgebied ‘Rapportages’ 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.
