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. In het magazine van juni gaat de tip in op testen in de lijnorganisatie.

Het succes van een SAP implementatie of upgrade hangt voor een groot deel af van de mate waarin er op gestructureerde wijze wordt getest. De verantwoordelijkheid m.b.t. testen ligt dan in handen van de aangestelde testmanager. Hij belegt de verschillende testtaken binnen de projectorganisatie. Bij testen in een beheer situatie zijn de verantwoordelijkheden meestal een stuk minder duidelijk. Het is van groot belang dat het voor iedere medewerker in de lijn helder is wat van hem of haar wordt verwacht.

Anders testen

‍
Kort na de testfase in het SAP implementatie- of upgrade project wordt het nieuwe SAP systeem in gebruik genomen en overgedragen aan de lijnorganisatie. Deze is enerzijds verantwoordelijk voor het ‘in de lucht houden’ van de systemen (beheer) en anderzijds voor het doorvoeren van aanpassingen (onderhoud) als gevolg van nieuwe inzichten, wensen, fouten in productie, etc. Hoewel het testen van deze aanpassingen wezenlijk anders is dan tijdens een project, zijn de risico’s minstens even groot.

Planning en resources
Gestructureerd testen valt of staat bij het vooraf plannen van de verschillende testactiviteiten. Het acceptatietesten wordt veelal door kerngebruikers naast de reguliere werkzaamheden uitgevoerd. Het is dus niet altijd mogelijk om de juiste resources vrij te maken voor het testen van wijzigingen. Wanneer ad hoc aanpassingen (als gevolg van bijvoorbeeld acute productieproblemen) zo snel mogelijk moeten worden doorgevoerd leidt dit vaak tot onvoldoende testen, met alle gevolgen van dien.

  • Wie is in uw organisatie verantwoordelijk voor het plannen van de testtaken en het inplannen van de resources hiervoor?

Testen op basis van impact en risico’s
In een project is ruimte om de diepgang van de tests te baseren op afgestemde (product)risico’s, waarbij het systeem over de volle breedte onder handen wordt genomen. Aanpassingen in de beheer fase worden vaak niet getest op basis van risico’s en het systeem wordt niet over de volle breedte getest. Het is dus van belang om de impact van een wijziging goed in te schatten om te bepalen welke onderdelen van het systeem getest moeten worden (de testscope). Daarnaast is het zinvol om de risicoanalyse uit het project te hergebruiken bij het bepalen van de testdiepgang.

  • Wie is in uw organisatie verantwoordelijk voor het bepalen van de testscope en testdiepgang bij een wijziging?

Testomgeving en transportbewaking
Projecten hebben vaak de beschikking over een eigen OTAP straat. De testdata is ofwel een recente kopie van productie ofwel door een subset van productie representatief gemaakt. Ook vindt hier bewaking op SAP transporten plaats. Omdat de testomgeving die de lijnorganisatie tot haar beschikking heeft minder vaak wordt ververst is de kans groot dat de omgeving onvoldoende representatief is voor productie. De testresultaten verliezen hun waarde als de testomgeving niet gelijk is aan de productie omgeving.

  • Wie is in uw organisatie verantwoordelijk voor de kwaliteit van de testomgeving?

Testcases en testscenario’s
Waar tijdens een project uitgebreid de tijd wordt genomen om testscenario’s op te stellen, wordt in beheer vaak een stuk minder formeel getest. Omdat de testscenario’s uit het project niet goed zijn geborgd in beheer zal de tester nieuwe testscenario’s moeten opstellen. In veel gevallen gebeurt dit niet en wordt de wijziging volgens de JBF methode (Jan Boeren Fluitjes) getest; zonder vooraf opgestelde test en zonder verslaglegging. Er vindt geen hergebruik van bestaande testscenario’s plaats of bestaande testscenario’s worden niet bijgewerkt op basis van de gewijzigde functionaliteit. Ook is onduidelijk in hoeverre er getest is op regressieproblemen.

  • Wie is in uw organisatie verantwoordelijk voor het beheren van de regressietestset?
  • Wie is in uw organisatie verantwoordelijk voor het opstellen en uitvoeren van tests?
  • Wie is in uw organisatie verantwoordelijk voor het beoordelen van de testresultaten?

Conclusie

‍
Veel testtaken zijn in beheer een stuk minder formeel ingeregeld dan in een projectsituatie. De kans is groot dat u niet direct een antwoord heeft op de gestelde vragen. Of dat degene die u in gedachte heeft als verantwoordelijke dit zelf anders ziet. Het belangrijkste is dat alle betrokkenen helder voor ogen hebben wie waarvoor verantwoordelijk is.

Het loont om iemand (tijdelijk) aan te stellen als overall verantwoordelijke voor testen. Deze persoon kan vervolgens een standaard testaanpak voor beheer uitstippelen en afstemmen met alle betrokkenen. De verantwoordelijkheden en taken worden vervolgens belegd bij key users, functioneel (applicatie) beheerders, technisch beheer en eventueel uw externe SAP partner.

Ook kan het helpen om wijzigingen in uw beheersituatie periodiek live te brengen (releasematig), zodat testen een formelere plek krijgt en meer ruimte ontstaat voor een uitgebreide regressietest. Daarnaast helpt een laagdrempelige testmanagement tool om het testproces te bewaken en tests te hergebruiken.

PTWEE helpt SAP gebruikende bedrijven om het testen beter en slimmer in te richten. We denken graag vrijblijvend met u mee over de manier van testen in uw beheer situatie. Neem gerust eens contact met ons op.

‍