Software development wordt steeds meer software integratie: combineren van standaard pakketten met maatwerk. In theorie wordt het leven van de cio daarmee een stuk simpeler. De governance ligt immers voor een groot deel bij de leverancier. En de dure software development -afdeling kan een stuk slanker worden. Wordt dat ook waargemaakt? Gedeeltelijk wel, maar integratie en (keten)integratietesten is wel heel belangrijk.
Standaardpakketten zijn ‘standaard’ al getest. Implementatie van pakketsoftware verschilt van maatwerksoftware omdat geen uitvoerige ontwikkeltesten en functionele testen meer nodig zijn.
Maar toch, wat zie je in de praktijk: een standaardpakket betekent minder software development en daarom relatief meer testwerk. Want de ketenrisico’s zijn niet minder en ketentesten vergt vaak een aanzienlijke inspanning qua voorbereiding en uitvoering. Dit is een inspanning die de key users uit de business in de regel moeten leveren.
Want het gaat om de integratie in het klantlandschap, met de testsoorten systeemintegratietest (technische ketentest) en acceptatietest (proces ketentest). De acceptatie is gericht op inregelingsaspecten en stelt niet de pakketselectie alsnog ter discussie. Uitzonderingen als gevolg van een slecht selectietraject daargelaten.
Overigens is er ook bij standaardpakketten meestal een stuk maatwerk, waarvoor een ‘gewone’ maar wel slimme testaanpak zoals Smartest nodig is.
Sustainability, Testdata en Migratie
Pakketimplementaties zijn pas succesvol bij stabiel gebruik en beheer. Dat hoeft niet big-bang te gebeuren. De huidige Agile trend biedt extra handvatten om business functionaliteit iteratief en incrementeel beschikbaar te stellen: niet alle functionaliteit is meteen beschikbaar en vaak ook niet voor alle gebruikersgroepen. Een bewezen en herhaalbaar proces komt van pas voor latere releases en toekomstige (wets-)wijzigingen. Want die moeten efficiënt kunnen worden doorgevoerd. Dus een serieus testproces besteedt veel aandacht aan de combinatie people-process-tools.
Testdata voor het testen van standaardpakketten is snel gemaakt met een productiekopie. Deze data is echter snel verouderd en voorziet niet in alle (nieuwe!) testsituaties. Meestal is aanvulling met zelf geconstrueerde testdata noodzakelijk. Een overall testdata management oplossing voor het betreffende standaardpakket zorgt voor de juiste data en kan de data anonimiseren in verband met privacy, indien gewenst.
Conversie- en migratietesten kennen veel onderschatte risico’s en testers hebben de neiging om deze risico’s aan anderen over te laten, bijvoorbeeld aan data- en informatie analisten. Maar testers zouden bij uitstek hier een goede rol kunnen spelen, al was het maar bij het in kaart brengen van de risico’s.
In mijn blog Testen van standaard softwarepakketten: de uitdagingen ga ik dieper op deze materie in.
Standaard proces
Grote erp-implementaties zijn vaak complex, duur en tijdrovend. Die slechte reputatie komt voort uit onhandige inrichting door onbekendheid met het pakket en moeizame integratie met bestaande systemen. Ook hier geldt ‘Just enough process’, maar om grip te houden op je project heb je wel meer proces nodig dan bij kleine pakketten. Scrum en Agile zijn daarbij niet het laatste woord. Want een te simpel proces zonder ‘quality gates’ gaat niet werken in de samenwerking met de leverancier. Onderstaand de stappen die mijns inziens noodzakelijk zijn.
1. Selectie en proof of concept (poc).
Een gedegen pakketselectie lijkt sterk op het testproces. Met de proof of concept (poc) als essentieel onderdeel: aantonen dat de kandidaat functioneert in de omgeving van de klant met real life scenario’s van de klant. Een evenwichtige en onderbouwde keuze is altijd een compromis en het heeft geen zin om later in het project in te zoomen op individuele (vermeende of reële) zwakke punten.
2. Installatie en ontwerp.
Installeer het pakket in een proeftuin-achtige omgeving (een verder uitgebouwde poc-omgeving) en integreer technisch al zoveel mogelijk met het applicatielandschap van de klant. Maak een ontwerp voor inrichting en eventueel maatwerk.
3. Inrichting, maatwerk, conversie, training.
Vul tabellen en parameters en configureer functies, denk aan conversie en training.
4. Integratietest sit/clt.
Testen van pakketimplementaties is – naast het testen van inregeling – vooral het testen van integratie en interfaces.
De systeemintegratietest (sit) ofwel technische ketentest toont aan dat het pakket technisch en functioneel correct functioneert in het it-landschap van de klant. Dit vergt samenwerking tussen experts van klant en leverancier. Het customer location test (clt)-principe houdt in dat de leverancier moet aantonen dat zijn pakket correct functioneert in de klantomgeving.
Overweeg geautomatiseerd regressietesten voor deze en andere testactiviteiten, want updates en nieuwe releases van het pakket zullen opnieuw getest moeten worden. De consensus is dat vanaf 6 tot 8 keer herhalen geautomatiseerd testen rendabel wordt. Met Onno Wasser en Arno Smedema schreef ik hierover het Computable artikel ‘Geautomatiseerd Testen van Pakketsoftware’.
5. Acceptatietest: fat/gat.
Dit is ook het moment van de overgang naar de acceptatie omgeving. Een klassiek ‘Quality Gate’-proces met exit- en entry-criteria kan hier zijn waarde bewijzen. Hoe meer de A-omgeving en de procedures als het ware ‘productie’ zijn, hoe beter de mogelijkheden om hier het go-live draaiboek te beproeven. De ‘gat’ mag het karakter van een (business) ketentest of E2E test hebben.
Meer dan in een klassiek traject ligt de nadruk hierop de gebruikersacceptatietest (gat). De functionele acceptatie (fat) is immers al bij de pakketselectie gedaan.
6. Voorbereiding Go-Live.
Berichtenverkeer: berichten en andere input die tijdens de conversie/deployment binnenkomen moet je tijdelijk parkeren en daarna correct en volledig verwerken.
7. Pvt: Productieverificatietest/pilot.
Aandachtspunt: terwijl software meestal automatisch wordt ‘gepromoot’ naar de P-omgeving, is dit voor inregeling meestal niet het geval. Na het overzetten zijn de inrichtingstabellen leeg en moeten ze handmatig gevuld worden, met alle foutgevoeligheid van dien. Dus wat in de A-omgeving goed was kan in de P-omgeving onjuist zijn.
8. Nazorg.
Overdracht van testware en nog openstaande issues naar de beheerorganisatie. Als het goed is zijn er afspraken met de leverancier over ‘root cause analyse’ en op kosten van de leverancier issues oplossen die niet door de klant(omgeving) zijn veroorzaakt. Het is niet de bedoeling dat de leverancier verdient aan eigen fouten.
Verdieping
In dit blog schets ik hoe zo’n proces voor de selectie, implementatie en invoering van standaard softwarepakketten, er uit kan zien.
