In onze eerdere 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 tip gaat in op het vijfde deelgebied: Keten Acceptatie.
- Inrichting
- Conversie
- Interfaces
- Rapportages
- Keten Acceptatie
- Productie Acceptatie
Keten Acceptatie
Volgens de theorie is de ketentest een vorm van testen binnen de systeem integratietest, functionele- en gebruikersacceptatietest. Daarmee wordt in mijn beleving het belang van de ketentest zwaar onderschat. Gezien het grote belang van de juiste werking van de SAP-ketens is het beter de testvorm ‘ketentesten’ bewust tot een aanvullende alternatieve testsoort te promoveren. Door ketentesten tevens als finale testsoort (ketenacceptatietest) te beschouwen wordt deze explicieter onderdeel van de project- en de testplanning en krijgt daarmee de noodzakelijke aandacht die het verdient.
Dit betekent niet dat de integratie testen binnen de systeemtest en de testvorm ketentesten als onderdeel van de functionele- en gebruikersacceptatietest komen te vervallen. Met name in het deelgebied interfaces is integratie en ketentesten een expliciet onderdeel van deze testen.
De rode stippellijn in bovenstaande figuur symboliseert dat alle voorgaande deelgebieden volledig volgens testplan getest en afgerond moeten zijn voordat met de finale ketenacceptatietest gestart kan worden. Voor de duidelijkheid; alle geplande testsoorten per deelgebied zijn uitgevoerd waarbij er geen blokkerende bevindingen meer open staan. Eventuele openstaande bevindingen zijn als niet blokkerend voor go live beschouwd en worden indien gewenst na go live opgelost.
Het niet hanteren van een freeze tijdens Keten Acceptatie vergroot de kans op de vicieuze cirkel van testen, hertesten en regressietesten.
Het doorvoeren van wijzigingen in deze laatste fase van het SAP-project is vragen om problemen. Het doorvoeren van wijzigingen is alleen nog op basis van een gedegen impactanalyse verantwoord. Bij deze impactanalyse worden de kosten, baten en risico’s goed afgewogen. Baten bestaan vooral uit de business component waardoor de business, functioneel beheer en de procesanalist belangrijke stakeholders zijn bij deze impactanalyse. Wanneer de kosten opwegen tegen de baten en de risico’s acceptabel zijn kan de wijziging gefundeerd doorgevoerd (en getest!) worden. Grootste generieke risico zit in het repeterende effect van de wijziging. Gevolgen van een wijziging in de inrichting kan namelijk direct effect hebben op de migratie/conversie, interfaces en rapportages.
Stel dat op basis van een bevinding toch nog een aanpassing van een invoerveld in een SAP-scherm noodzakelijk is, dan kan dit tevens gevolgen hebben voor:
- Migratie/conversie, mogelijk is de data van het aangepaste invoerveld onderdeel van de migratie.
- Interfaces, het kan zijn dat de data van het aangepaste invoerveld met andere systemen binnen de keten uitgewisseld moet worden.
- Rapportages, mogelijk is de data van het aangepaste invoerveld onderdeel van een rapport.
De impactanalyse van de wijziging moet inzicht geven welke deelgebieden door de wijziging geraakt worden. Wanneer bij de impactanalyse een deelgebied over het hoofd wordt gezien beland je gegarandeerd in de vicieuze cirkel van testen, hertesten en regressietesten. In dit geval komt men er hopelijk bij de test achter dat er ook nog een wijziging in het gemiste deelgebied doorgevoerd moet worden. Vervolgens begint het hele traject van het doorvoeren van de aanpassing, hertesten en regressietesten weer van voor af aan. Je kunt je voorstellen dat wanneer dit pas in productie geconstateerd word je nog veel verder van huis bent.
In het meest ongunstigste geval moet je dus voor één bevinding in alle vier de deelgebieden een aanpassing doorvoeren. Daarbij is de kans op regressie enorm waardoor je niet alleen de wijzigingen op alle vier de deelgebieden moet testen maar tevens een volledige regressietest voor de gehele keten moet uitvoeren.
Terug naar de Keten Acceptatie. In de praktijk blijkt een freeze al snel een utopie en komt het erop neer dat er altijd op het laatste moment nog wijzigingen doorgevoerd moeten worden. Hierdoor bestaat de ketenacceptatietest op voorhand al uit twee vaste onderdelen:
- Keten Regressietestcases.
- Betreft een regressietest die op basis van de Product Risico Analyse is samengesteld.
- Is een aaneenschakeling van de al opgestelde regressietestcases van de voorgaande deelgebieden.
- Keten Specifieke Testcases.
- Betreft een subset van de al uitgevoerde testcases in de voorgaande deelgebieden die binnen de keten aaneengeschakeld worden.
Indien de overall teststrategie juist is opgesteld en uitgevoerd zijn de testcases voor de Ketenacceptatietest al voor vrijwel 80% vanuit de voorgaande testdeelgebieden beschikbaar. De laatste 20% bestaat uit de verrijking Keten Regressietestcases met de keten Specifieke Testcases.
Bij een praktische testmanagementtool zoals Testersuite kan bij elke testcase worden aangevinkt of deze tot de regressietestset behoort. De Keten Regressietestcases zijn op deze manier eenvoudig te filteren. Aansluitend kan men deze testcases als ketentestscenario’s aan elkaar koppelen. In Testersuite kunnen deze testscenario’s eenvoudig uit de testcases worden samengesteld, ingepland en uitgevoerd. Als laatste moeten hieraan de aanvullende keten specifieke testcases toegevoegd worden. Door de Keten Specifieke Testcases en de Keten Regressietestcases op een slimme manier te combineren kan met een minimaal aantal testscenario’s de volledige keten dekkend getest worden. Op deze manier is de ketenacceptatietest een resultante van de voorgaande testdeelgebieden waardoor bij de voorbereiding en uitvoering zeer efficiënt met de altijd schaarse testresources wordt omgegaan.
Bij het afronden van het project wordt deze actuele en representatieve keten regressietestset overgedragen aan beheer zodat deze in de toekomst kan worden hergebruikt.
In de praktijk krijgt de testmanager regelmatig de vraag of er niet ‘even slim’getest kan worden. Hiermee bedoelt men dan; hoe kan er met minimale inzet snel een dekkende test uitgevoerd worden?
De combinatie van voorgaande blogs en deze blog geven hier een antwoord op. Het is hierbij van belang dat de testmanager tijdig bij het project wordt aangehaakt waarbij hij de efficiënte en effectieve teststrategie kan opzetten en over alle deelgebieden kan uitvoeren. Zoals in deze blog duidelijk wordt is de winst aan het einde van het testproject concreet zichtbaar. Het al oude spreekwoord ‘eerst zaaien dan oogsten’ is hier zeker van toepassing.
Deze tips zijn voor PTWEE een middel om een kijkje in de keuken van pragmatisch SAP-Testmanagement te geven. Natuurlijk is dit niet uitputtend; elke klant/project is uniek. Pragmatisch testmanagement is iets anders dan de kaasschaafmethode of ongenuanceerd elimineren van testactiviteiten. Het is zeker geen ‘one size fits all’. Per situatie moet gekeken worden wat de meest efficiënte en praktische teststrategie is. Het op de juiste wijze opzetten van de pragmatische teststrategie en daar sturing aan geven zorgt voor een efficiënt en effectief klant specifiek SAP-testproject. 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 tip wordt het efficiënt testen van het testdeelgebied-6 ‘Productie Acceptatie’ verder uitgediept.
PTWEE helpt SAP gebruikende bedrijven beter en slimmer te testen en hanteert daarbij een pragmatische aanpak. Deze blog 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.
