De correcte werking van SAP-software wordt over het algemeen ervaren als een vanzelfsprekendheid. Pas op het moment dat iets niet (goed) werkt, merk je de gevolgen er pas van. Vergelijk het met een auto; zonder na te denken stap je in de auto om boodschappen te doen, de kinderen op te halen of voor een dagje uit. Pas als de auto niet start, of nog erger, je halverwege strandt, word je geconfronteerd met je afhankelijkheid en alle ellende er omheen. Door software (inrichtings!)wijzigingen uitvoerig te testen voorkom je dat bedrijfsprocessen stranden.

Maar ook het testen zelf kan natuurlijk verkeerd gaan. Net als bij autopech zijn hier veel uiteenlopende oorzaken voor te verzinnen. Na een rondgang onder de testconsultants bij PTWEE kwamen de volgende drie topics opvallend vaak naar voren als oorzaak.

Te laat beginnen

Als je ergens te laat aan begint loop je continu achter de feiten aan. Voorbereiden terwijl je al had moeten uitvoeren en uitvoeren terwijl je al had willen afronden. Dit geldt voor alles, maar in de praktijk zien we helaas dat dit op testgebied erg vaak voorkomt. De testwerkzaamheden zitten dan vanaf dag één direct op het kritieke pad. De hoeveelheid testwerk wordt onderschat, testen wordt gezien als nevenactiviteit (“Dat doen we er wel even bij...”) of er wordt pas testexpertise aangehaakt vlak voordat de testfase start. Als je bedenkt dat de uitvoer van testen slechts 40% van alle testactiviteiten omvat, zie je dus 60% van het werk over het hoofd (waaronder de testvoorbereiding en specificatie).

Computerwetenschapper Barry Boehm kwam in de jaren 80 al tot de conclusie dat de kosten om fouten te vinden en op te lossen exponentieel toenemen over tijd. Een fout in productie kost zo een veelvoud van een fout in een requirement, nog voordat überhaupt enige customizing heeft plaatsgevonden. Positief gesteld loont het dus om op tijd het testen ‘aan te haken’, acceptanten te betrekken, ontwerpdocumentatie te reviewen (statisch te testen) en al vooraan in het traject te sturen op QA en kwaliteit.

Een acceptatietest is dan een laatste ‘quality gate’ voor ingebruikname die vertrouwen geeft, in plaats van een spannende fase waarbij het de vraag is hoe het systeem zich houdt.

Regressie: Het geheel in de gaten houden (=onmogelijk)

Een van de grote uitdagingen bij het testen van een groot complex SAP landschap is het afdekken van regressie. Een kleine aanpassing in het ene systeemonderdeel kan grote gevolgen hebben voor een ander groter onderdeel. Als dat andere grotere onderdeel al getest is, bestaat bovendien de kans dat dit pas in productie wordt ontdekt. Bij grote projecten is het gebruikelijk om na een reeks aanpassingen (groot of klein!) een regressietest uit te voeren.

Gezien de omvang van de oplossingen van SAP is het echter onmogelijk om bij iedere wijziging een complete regressietest uit te voeren. Bovendien wordt vaak door meerdere teams gewerkt aan hetzelfde systeem, met onderlinge integraties. Er moeten dus keuzes gemaakt worden. Deze keuzes kunnen worden gemaakt op basis van geschatte impact. Maar wie kan alles van een groot systeem nog goed overzien? Een goed alternatief is om de regressietest op te zetten op basis van risico’s. De onderdelen die bij fouten de grootste problemen veroorzaken voor de business, wil je in ieder geval meenemen in de regressietest.

De product risicoanalyse (PRA) is zeer geschikt om de risico’s in kaart te brengen. Op basis van faalkans en impact beoordelen verschillende stakeholders van SAP waar de grote en waar de kleine risico’s liggen. De onderdelen van het systeem die een hoog risico met zich meedragen, krijgen een plek in de regressietest.

Testautomatisering

Waar de uitkomsten van de PRA ook handig voor zijn: het samenstellen van een geautomatiseerde testsuite. Want alles automatiseren is een megaklus en over het algemeen zeer inefficiënt. Zeker als de suite gebruikt wordt als regressietest.

Maar bij automatiseren van tests speelt een veel groter hangijzer: waarom gaan we automatiseren? Veel organisaties zien het als het ultieme doel voor testen. Zij vergeten gemakshalve dat een geautomatiseerde test niet altijd relevant of gepast is. Als je maar zeer beperkt releases naar productie brengt, moet je nog maar eens goed nadenken of alle investering in tijd en geld (bouw maar vooral ook onderhoud!) de moeite loont. Even zo belangrijk is het antwoord op de vraag: zijn we er als organisatie qua testvolwassenheid wel aan toe? Als het handmatig testen nog in de kinderschoenen staat, is het echt heel onverstandig met automatiseren aan de slag te gaan. Een niet efficiënt proces automatiseren leidt immers tot versnelde inefficiëntie.

Tot slot

Er zijn zoals gezegd veel meer redenen waarom testen niet slaagt. Denk bijvoorbeeld aan uitdagingen op het gebied van testdata waardoor testresultaten minder betrouwbaar zijn. Of aan situaties waarin toch aan een acceptatietest wordt begonnen terwijl nog lang niet aan alle voorwaarden is voldaan. Ook komt vaak voor dat er een grote afhankelijkheid is van de leverancier, waardoor de eigen verantwoordelijkheid niet wordt genomen om het opgeleverde systeem of wijziging goed te accepteren.

Al met al maakt dit testen tot een waanzinnig interessant en uitdagend vakgebied. Sinds 2008 helpt PTWEE bedrijven met SAP om beter en slimmer te testen. Heb je een testuitdaging en wil je graag eens van gedachten wisselen? Benader ons gerust met uw zorgen over de testaanpak. Dan zorgen we samen dat de tests wel slagen!