Dit proces maakt onderdeel uit van het operationele procescluster Functionaliteitenbeheer. De naam van dit proces geeft goed aan wat de doelstelling is; een controle op het resultaat van diverse uitgevoerde activiteiten in andere processen.

Opmerking: hieronder worden doel, activiteiten, resultaten en relaties van dit proces kort samengevat. Deze zijn uitgebreider te vinden in boeken die reeds op dit terrein zijn verschenen. Zie hiervoor de pagina boeken op deze website. Wat u in die boeken niet vindt en hieronder wel, zijn de KPI’s, proces- en procedure schema’s en ervaringen c.q. opmerkingen uit de praktijk.

Doel proces Toetsen en testen

Het proces Toetsen en testen heeft als doelstelling er zorg voor te dragen dat de gewijzigde geautomatiseerde en niet geautomatiseerde informatievoorziening correct functioneert, de bijbehorende hulpmiddelen (handleidingen, procedures, etc.) juist zijn en ook de veranderingen vlekkeloos zullen worden doorgevoerd.

Dit proces heeft natuurlijk sterk te maken met het reduceren van de foutkans in productie tot een aanvaardbaar niveau. Hoewel in theorie een 100% test mogelijk is, is dat in de praktijk niet het geval en daarmee kan dus altijd een afweging worden gemaakt: meer testen = meer werk + kosten, maar verminderde kans op productiefouten c.q. productieverlies, vice versa.

Activiteiten proces Toetsen en testen

Het proces Toetsen en testen kent de volgende activiteiten die overigens vrij nauw samenhangen met de andere processen in het cluster Functionaliteitenbeheer.

1. Het voorbereiden van het toetsen en testen: met name planning van menscapaciteit
2. Uitvoeren acceptatietest; dit is de test die met name binnen BiSL wordt genoemd. Andere tests vinden plaats in de ICT-organisatie
3. Toetsen niet-geautomatiseerde informatievoorziening; de correctheid van de aangepaste handleidingen, procedures, formulieren etc.
4. Toetsen van implementatie- en transitieplan; niet alleen het gewijzigde systeem moet op correctheid worden gecontroleerd, ook de wijze waarop de wijzigingen in productie zullen worden genomen wordt getoetst
5. Bepalen impact toets- en testresultaten, aan de hand van de resultaten kan worden besloten dat een aantal werkzaamheden voor inproductiename opnieuw moeten worden uitgevoerd, ofwel bepaalde zaken moeten worden verbeterd (vlak) na inproductiename, ofwel dat de ernst van de bevindingen zo laag is dat deze kunnen worden geaccepteerd.

Resultaten proces Toetsen en testen

De resultaten van dit proces zijn:
1. Testvoorbereiding: aanpak en opzet, welke (gedeeltelijk) in een volgende testcyclus kan worden hergebruikt
2. Toets- en testresultaten
3. Advies over te ondernemen stappen naar aanleiding van de toets- en test-resultaten
4. Een informatiesysteem dat werkt conform specificaties, eventueel met afwijkingen die zijn overeengekomen
5. Een finale goedkeuring (decharge) aan de IT-leverancier

KPI’s / rapportage items proces Toetsen en testen

Voorbeelden van Key Performance Indicatoren (KPI’s) voor het proces Toetsen en testen zijn:
– Aantal uitgevoerde tests (uitgesplitst naar aantal, uren, soort)
– Aantal bevindingen (uitgesplitst naar systeem, ernst)
– Aantal acties naar aanleiding van bevindingen (uitgesplitst naar ernst)
– Aantal productiefouten die alsnog optreden nadat een goedgekeurd systeem in productie is genomen (geeft een indicatie van de juistheid/volledigheid van het proces Toetsen en testen en mogelijkheden ter verbetering)

Deze KPI’s kunnen als input dienen voor een rapportage.

Relaties met andere processen

De processen Wijzigingenbeheer en Specificeren zijn uiteraard de processen die de informatie zullen aanleveren over de gewenste wijzigingen. Het proces Niet geautomatiseerde informatievoorziening, Voorbereiden transitie en de IT-leverancier zullen elk concrete aangepaste producten aanleveren ter test / toetsing. Andersom kan afstemming plaatsvinden vanuit Toetsen en testen naar aanleiding van geconstateerde bevindingen.

In de praktijk – Testcriteria

Het is bepaald geen uitzondering dat pas tijdens de test duidelijk wordt waar een gewijzigd systeem eigenlijk aan moet voldoen. Aldus worden de criteria pas dan vastgesteld of erger nog, tijdens de test voortdurend bijgesteld. Het gevolg is uiteraard dat aan de IT-zijde onzekerheid ontstaat over de inhoud en de kwaliteit van de wijzigingen (wanneer is het nu wel goed?). De oplossing is even voor de hand liggend als soms toch lastig te realiseren: Vooraf, eigenlijk al bij de creatie van de specificaties, moeten ook de acceptatiecriteria worden vastgelegd. Wat daarnaast ook wel een mogelijkheid is dat er een aantal algemeen geldende acceptatiecriteria worden vastgesteld, die per wijziging of per release worden aangevuld met specifieke acceptatiecriteria die alleen voor die wijziging of release gelden. Bijvoorbeeld over usability of bedrijfsstijl zijn vrij eenvoudig criteria vast te stellen die bij elke test gelden.

Wat sommige ICT-organisaties wel doen is een wijzigingsverzoek niet accepteren indien er geen acceptatiecriteria voorhanden zijn. En feitelijk terecht: indien niet helder is aan de hand van welke maatstaven zal worden getoetst, wordt het realiseren van een wijziging een moeilijke zaak.

In de praktijk – Termen, termen…

Binnen BiSL wordt binnen het proces Toetsen en Testen gesproken over de acceptatietest. In de praktijk maken veel organisaties onderscheid tussen een gebruikersacceptatietest en een productieacceptatietest. Sommigen gebruiken daarnaast ook nog de termen functionele acceptatietest en beheeracceptatietest. Dat kan nog wel wat verwarring opleveren. Hierna wordt een poging gedaan wat orde in de termen te scheppen, hoewel in de praktijk de invulling aanzienlijk kan verschillen.

De acceptatietest zoals in BiSL bedoeld wordt is in deze termenreeks te vergelijken met de gebruikersacceptatietest: de test die aan de klantzijde wordt uigevoerd om te constateren of de aanpassingen voldoen aan de eerder geformuleerde vraag.

De productieacceptatietest wordt uitgevoerd binnen de IT-organisatie, echter niet door applicatiespecialisten maar door operations; de toekomstig technisch beheerders. Met name het gedrag van de aangepaste software op de hardware is hier aandachtsgebied. Een voorbeeld hiervan zijn de veranderingen in gebruik van resources t.o.v. de oude versie van de software (“meer CPU nodig”). Andere voorbeelden zijn de doorlooptijd van een nachtbatch, of de systeembelasting per transactie overdag. Maar ook de benodigde schijfruimte kan onderwerp zijn van de test.

Wordt een functionele acceptatietest gedaan, dan kan dat de vorm hebben van een test die aan de IT-zijde wordt gedaan. Hierbij wordt dan getest t.o.v. het aangepaste FO. Maar het komt ook wel voor dat onder dezelfde benaming een groep functioneel beheerders aan de klantzijde een test uitvoert, voor de fase waarin een groep echte eindgebruikers een test gaat uitvoeren. En die laatste wordt in dat geval de gebruikersacceptatietest genoemd.

Tot slot de minst voorkomende, maar feitelijk toch ook zeker relevante test; de beheer acceptatietest. Hierin wordt getest of een systeem wel in beheer is te nemen. Logischerwijs wordt deze test geïnitieerd vanuit beheer. Met name voor applicatiebeheer kan dit relevant zijn indien ze in het geheel niet zijn betrokken bij de aanpassingen omdat deze in een ander organisatieonderdeel zoals bijvoorbeeld development of buiten de eigen organisatie zijn gedaan.