Wat maakt SAP testen nu zo speciaal is een vraag die mij vaak gesteld wordt. De afgelopen vijf jaar heb ik als SAP Test Manager een rol gespeeld in een groot aantal implementaties en upgrades. Telkens weer komt deze vraag voorbij. En mijn antwoord… tjah… SAP testen is een specialisatie en vraagt specifieke kennis, maar is het wel echt zo speciaal als sommige doen lijken?
Zoals vele andere erp-pakketten valt ook in het geval van SAP alles te relateren aan bedrijfsprocessen. De continuïteit van deze bedrijfsprocessen wordt geborgd door intensief te testen en zo te bepalen of een implementatie of upgrade zonder ‘klamme handjes’ in productie kan worden genomen. De aanpak van SAP testen is hierbij in hoofdlijnen dan ook niet anders van andere erp-pakketten zoals Oracle. Een gestructureerde aanpak en standaard set aan testtechnieken zoals beschreven in TMAP kan door een ervaren test professional moeiteloos ingezet worden.
Autorisaties, maatwerk, interfacing (zowel SAP intern als extern) en conversies zijn onderdelen die vaak genoemd worden als onderdelen die SAP zo uniek maken. Standaard SAP hoeft immers niet getest te worden is het uitgangspunt in veel trajecten (je test bijvoorbeeld Windows ook niet). Toch zijn ook deze onderdelen naar mijn mening niet uniek te noemen en ligt bij veel ERP pakketten de nadruk van het testen juist op punten als maatwerk en interfacing.
Uniek karakter
Ondanks deze constateringen wordt SAP testen door verschillende bedrijven en specialisten als wezenlijk anders beschouwd van regulier testen. Twee auteurs (Markus Helfen & Hans Martin Trauthwein) hebben zelfs een boek van 735 pagina's weten te vullen met nagenoeg alles wat je moet weten over SAP testen. Kortom, het is toch echt wel specifiek te noemen! De wereld rondom SAP is namelijk volop in beweging en daar speelt testen een belangrijke rol in. Het opzetten van een SAP-testtraject dat past bij de ASAP-methode, het gebruik van de specifieke set aan tools zoals SAP Solution Manager en de focus van het testtraject zijn wezenlijk anders van andere pakketten.
Verder is het inrichten van SAP, de opbouw van het pakket, de transportmechanisme, communicatielagen en de specialistische kennis uniek. Hoewel het gebruik van SAP met de juiste trainingen bij te brengen is vraagt het inrichten, maar ook het testen, om kennis van het systeem. Vanzelfsprekend geldt ook dit voor andere nieuwe pakketten waar al snel een achterstand is als iemand systeemkennis ontbeert.
Waar het op neer komt
Mijn conclusie is dat SAP testen dan ook een groot generiek karakter heeft als we over testen in brede zin praten. Ieder nieuw systeem vraagt immers om de opbouw van kennis vanuit de test-specialist. Het unieke karakter van SAP is echter ook onmiskenbaar en bepaalde basiskennis is cruciaal om het goed te kunnen testen. De tientallen jaren ontwikkelwerk hebben geleidt tot een fors pakket dat niet eenvoudig eigen kan worden gemaakt en waar iedere testaanpak zomaar bij past.
Waar het op neer komt is dat het de kunst is om bij het testen van SAP de juiste instrumenten te gebruiken. De juiste testtechnieken, methodische opzet en het opbouwen van testdata zijn hier voorbeelden van. Het vakgebied testen is in de afgelopen jaren namelijk uitgegroeid tot een vakgebied met vele methoden en technieken die een gereedschapskist aan instrumenten heeft opgeleverd. Mijn mening is dat zonder kennis van SAP menig testmanager of testanalist zal falen in het testen van SAP. Natuurlijk spreek ik uit eigen ervaring en ben ook ik zonder enige SAP-kennis gestart.
Het is namelijk een kunst om de juiste technieken te kiezen, aansluiting te vinden bij de verschillende functionele deelgebieden, regressietesten op te pakken of testautomatisering succesvol in te richten. Waar het bij veel pakketten mogelijk is om binnen een paar weken ‘op stoom te zijn' vraagt SAP meer inwerktijd. Een test-specialist met veel kennis van bedrijfsprocessen zal snel aansluiting vinden met SAP en zal naast een set aan specifieke trainingen onder de vleugels van een opererend testteam meegenomen moeten worden. Iemand ‘zomaar aanhaken' is geen optie, want de wereld van SAP is specialistisch en te groot waardoor het een kunst is om niet te verdwalen. Dat is wat het zo speciaal maakt!
Bovenstaand relaas laat duidelijk zien dat je niet alle resource problemen met inhuurders op kunt lossen.
Een goede tester draagt een standaard pakket aan kennis met zich mee daar waar het gaat om testmethodieken etc.
Maar vooral bij grotere complexe producten of implementaties, waar SAP er één van is, komt er ook een stuk domeinkennis om de hoek kijken.
De combinatie domeinkennis – testmethodieken maakt een tester pas echt goed en zinvol inzetbaar.
Een interessante discussie zou kunnen zijn welke van de 2 nu het belangrijkste is of hoe de verhouding tussen testkennis en domeinkennis zou moeten zijn.
Beste PaVaKe,
Bedankt voor je toevoeging. Je slaat de spijker op zijn kop. Domeinkennis is cruciaal in het testen van SAP en ieder ander pakket waarbij bedrijfsprocessen zo’n belangrijke rol spelen. Bedrijfsprocessen zijn vaak onstaan vanuit bepaalde domeinkennis en zelfs uit sociale constructen vanuit de werkvloer. Het is een valkuil om hier geen aandacht aan te besteden.
Je opmerking over wat het belangrijkste is of hoe de verhouding ligt is inderdaad interessant. Uit de praktijk merk ik dat een goede domeinspecialist niet altijd een goede tester kan zijn. Testen is immers een vak en gaat verder dan domeinkennis. Een domeinkennis alle kneepjes van het testvak leren en bekend maken met alle testtechnieken en methoden is zinloos. Een tester ontbeert vaak echter weer bepaalde domeinkennis, ondanks het feit dat hij juist helemaal de processen in duikt.
Als ik terug kijk naar succesvolle implementaties en upgrades was de kracht juist te vinden in een combinatie van de twee werelden. Een testteam moet eigenlijk altijd bestaan uit domeinspecialisten, noem het key-users of eindgebruikers, en professionele softwaretesters. Dan heb je pas echt een krachtige mix te pakken. Je noemt daarbij inhuur, maar ik geloof juist ook in de kracht van interne testers rapporterend aan iemand van de business. Interne testers kennen het bedrijf en de politiek, iets wat in SAP implementaties/ upgrades ook onmisbaar is om in het achterhoofd te houden!
Wat betreft SAP kan je verschillende soorten testen onderscheiden:
– verificatie van de customer specifieke functionaliteit : kan nodig zijn om vast te stellen of deze functionaliteit intact blijft ondanks veranderingen die erin plaatsvinden.
– performance testing : is soms nodig voor en na wijzigingen in de infrastructuur, upgrade en aantal gebruikers om vast te stellen of de huidige capaciteit voldoende is en er geen resource bottlenecks bestaan onder verschillende typen load (memory/CPU/IO). Het realistisch simuleren van eindgebruikers is lastig en vereist veel ervaring.
– periodieke compliancy checks
Betreffende SAP performance testing:
Benevens het genoemde boek “Testing SAP Solutions” zou ik ook de “SAP Performance Optimization Guide” van Thomas Schneider en “SAP BW Performance Optimization Guide” van Thomas SChroder willen aanraden.
Mooi artikel Rene! Proficiat.
Is dit niet een artikel met de strekking “Wij van WC-eend, adviseren WC-eend, met dan met name als het om testen gaat.
Wat een beetje tegenvalt is dat SAP implementaties niet veel meer op Best Practices stoelen. Bij iedere SAP implementatie wordt het wiel voor de zoveelste keer uitgevonden. Het is juist de kunst om Specifiek en Generiek te benoemen en alleen het specifieke deel specifiek te testen en niet de gehele suite.
Ik heb laatst gehoord dat SAP zelf bijna 80.000 testserver in huis heeft en het is dan ook de vraag wat er voor de implementatie bij de klant wordt getest en wat daarvan de toegevoegde waarde is. Dat SAP consultants alles willen testen lijkt mij niets nieuws, het gaat gewoon om keiharde cash, of er toegevoegde waarde in zit en of het allemaal nuttig is, dat valt te bezien.
Omdat SAP alle verantwoordelijkheid van het juist functioneren van SAP bij de klant neerlegt zal de klant zich gedwongen zien om alles te testen en zo is de cirkel rond. Het lijkt inderdaad niet mogelijk om met generieke testmethodes zoals Tmap en Testframe de certificatie van SAL rond te krijgen en dan ga je als bedrijf geen risico nemen er zijn al teveel organisaties failliet gegaan aan een SAP implementatie.
@willem oorschot, 02-09-2012 12:59
Dat is een wat bitter verhaal, Willem.
Kijk eens naar : http://help.sap.com/bestpractices rapid-deployment solutions bijvoorbeeld. SAP levert de instrumenten wel degelijk aan en het is aan de klanten / implementatiepartners om deze te gebruiken.
De redenen om te testen heb ik een mijn eerdere reactie al gegeven. Jouw stelling dat het hierbij gaat om keiharde cash onderschrijf ik niet. Kan je misschien aangeven waarom je deze mening bent toegedaan ?
De verantwoordelijkheid voor het juist functioneren van SAP ligt uiteraard bij de klant. Het gaat hier namelijk niet om een simpele cloud oplossing of een stuk standaard software, maar om een ERP systeeem waarvan de business critical delen bestaan uit maatwerk programmatuur, klant-specifieke customizing en vele interfaces met 3rd party software. Aangezien de businesslogica per implementatie verschilt kan je dus niet zoveel met generieke testtools. Daarom blijft het testen van SAP ook een vak apart zoals de auteur al aangaf.
Wat is SAL certificatie ? Bedoel je SAP Certificatie ? Wat is dat precies en waarvoor dient dat ? Biedt zo’n certificatie bescherming tegen het fout lopen van een SAP implementatie en hoe werkt dat precies ?