Testen in een SAP-omgeving is soms meer complex dan testen van zichzelf al is. Vaak ligt maatwerk bovenop de standaard SAP-functionaliteit hieraan ten grondslag. Een andere oorzaak is de manier waarop de OTAP ontwikkelstraat is ingericht. Voor de problemen die uit die complexiteit ontstaan, wil ik een oplossing aandragen. Maar eerst duiken we dieper in de problematiek zelf.
Maatwerk
Stel je voor je werkt alleen maar met standaard SAP en in een afgesloten, niet keten, omgeving. Het enige probleem dat je dan hebt als het gaat om verschillen tussen de testomgevingen en de productieomgeving, is testdata. Maar als de omgeving onderdeel is van een grotere keten, wordt het al wat lastiger. Is er ook nog eens sprake van maatwerk dan heb je de poppen pas echt aan het dansen.
Om nieuwe of gewijzigde functionaliteit zo betrouwbaar mogelijk te kunnen testen, is het noodzakelijk om een Almost Production Like (APL) omgeving te hebben. De acceptatie-omgeving is daarvoor meestal de aangewezen plek. Helaas gaat het daar nogal eens mis. Maatwerk vraagt om het bijhouden van aparte tabellen, extra interfaces om in de lucht te houden, autorisaties voor alle omgevingen gelijk te trekken en nog veel meer technische zaken waar ik als testprofessional op dit moment niet dieper in zal gaan. Maar het is een potentiele bron van ellende, simpelweg doordat een vinkje vergeten te zetten bij een SAP-transport tot enorme verstoringen kan leiden. De kans hierop is nog groter als niet alle activiteiten binnen het eigen team plaatsvinden. Zorgen dat een omgeving APL is, vraagt om structurele aandacht voor het onderliggende proces. Dat is telkens een kleine investering in tijd en geld, die door organisaties het liefst wordt gemeden. Belangrijke redenen hiervoor zijn het anonimiseren van productiedata, het tijdelijk niet beschikbaar hebben van de acceptatie-omgeving en de rekening die de beheerpartij er doorgaans voor op tafel legt.
OAP
Een “standaard” straat bestaat uit een ontwikkel-, test-, acceptatie- en productieomgeving, ook wel de OTAP-straat genoemd. Wat op dit moment echter steeds vaker gebeurt, is dat bedrijven omwille van bezuinigingen de testomgeving achterwege laten. Stom! Een volledige OTAP-straat maakt het je als team en organisatie juist makkelijk het proces van ontwikkelen en testen richting releases optimaal in te richten.
Vooral de testomgeving (T) wordt dus nogal eens wegbezuinigd. Of we nou denken vanuit waterval of vanuit agile testen, de ontbrekende testomgeving zorgt ervoor dat al het functionele testen op de acceptatie-omgeving plaatsvindt. Gestructureerd testen gaat het best als alle testsoorten op de juiste plek uitgevoerd worden, op de juiste omgeving dus! Een organisatie die ervoor kiest om slechts een OAP-straat in de lucht te houden, komt bijvoorbeeld al snel in een squeeze met de regressietest.
Een simpel advies
De oplossing is een simpel advies: werk met een volledige OTAP-straat en zorg dat de acceptatie omgeving zoveel en zo vaak als mogelijk production like (APL) is. In de praktijk betekent dat een frequente refresh vanaf de productieomgeving. Er zijn tools beschikbaar die dit in korte tijd kunnen uitvoeren. De testomgeving mag dan zelfs wat beperkter ingericht zijn (bijvoorbeeld door slechts een deel van de catalogus beschikbaar maken).
Onderstaand scenario van een agile traject met een sprint van twee weken (maar de slimmeriken onder ons vertalen het met gemak naar andere scenario’s) laat zien hoe je als tester gestructureerd(er) aan de slag kan.
In dit scenario wordt alles rond acceptatie testen in de eerste week van de sprint gedaan. Dus ook de Gebruikers Acceptatie Test, die door deze opzet bovendien veel makkelijker te plannen is. Dit komt omdat de tester precies weet wanneer de code en configuratie van de vorige sprint op de acceptatie-omgeving beschikbaar is. Omdat er een OTAP-straat is, kan deze slag in een keer gedaan worden in plaats van elk afgerond stukje functionaliteit een voor een te deployen. Het overzetten en configureren van de nieuwe code van de gehele sprint naar acceptatie is daarnaast een generale repetitie voor de release naar productie. Juist als er sprake is van veel maatwerk op SAP, is dit geen overbodige luxe maar een must.
Voordeel
Het grote voordeel van dit scenario is daarnaast dat een tester aan het begin van een sprint meteen aan de slag kan met testen en daardoor zijn of haar werkzaamheden evenwichtiger zijn verdeeld gedurende de sprint.
Er zijn ongetwijfeld nog meer goede varianten denkbaar zijn, maar waar het vooral om gaat, is dat duidelijk is dat als de testomgeving wegvalt er veel minder mogelijkheden zijn en bovenal: veel minder flexibiliteit. En dat is waar het ook in een SAP-omgeving om gaat.
PTWEE helpt SAP gebruikende bedrijven beter en slimmer te testen en hanteert daarbij een pragmatische aanpak. Deze tip is opgesteld door Martin Heining, SAP Testconsultant bij PTWEE. Heeft u behoefte om vrijblijvend met ons van gedachten te wisselen over uw testuitdagingen? Neem dan contact op met Roel van Bremen.
