Artikel

Hoe Testers en Auditors elkaar vinden - Zodat u beter slaapt

De manier waarop we anno 2011 architectuurconcepten en IT-systemen valideren kan beter. Als gepassioneerd softwaretester leg ik in dit artikel graag uit waarom ik denk dat testers en auditors dat kunnen door meer bruggen te slaan tussen deze twee vakgebieden en een gemeenschappelijk referentiekader te kiezen. Omdat verbeteren van de wereld bij jezelf begint zal ik om te beginnen uitleggen hoe testers hierop aangesproken en in de goede richting gemasseerd kunnen worden. In de stille hoop op een antwoord uit de auditwereld uiteraard. Ik ben benieuwd!

Testen is de hobby waarmee ik m’n brood verdien, maar ik zou graag architect als nevenfunctie kiezen. Bij ING Bank was ik ooit “test architect” en bij het Kadaster heb ik een aanpak op basis van het TOGAF architectuur raamwerk gemaakt [1], maar dat heeft me allemaal geen officiële status als architect gebracht.

Wel ben ik sinds kort gecertificeerd risico auditor. Voluit: “Certified in Risk and Information Systems Control”, afgekort CRISC. CRISC is een nieuwe loot aan de ISACA stam die eerder al CISA, CISM en CGEIT heeft voortgebracht. En die titels doen het internationaal erg goed. Voorheen was het zo dat een ‘echte’ geregistreerde EDP-auditor (RE) zijn neus optrok voor een CISA. En zeker voor een CGEIT, maar dat heeft meer te maken met een bepaalde klankassociatie vermoed ik. De exclusief Nederlands/Vlaamse RE titel verliest echter terrein en legt het internationaal af tegen de ISACA certificeringen.

Op mijn visitekaartje staat dus niet meer gewoon “Egbert Bouman”, maar “Ing. E. Bouman CRISC”. Wat overigens geheel aansluit op het citaat aan de achterkant: “Doe niet zo bescheiden, zo belangrijk ben je niet”, een uitspraak die aan Golda Meïr wordt toegeschreven.

Het geeft in ieder geval gespreksstof! Na de gebruikelijke 5K fase (kopje, koffie, koetjes, kalfjes, kinderen) van gesprekken met klanten en relaties en het uitwisselen van visitekaartjes volgt regelmatig de vraag “CRISC, wat is dat nou weer?” En dat is een mooie opening voor een verhaal wat ik altijd graag vertel: het vak softwaretesten en het vak auditing groeien naar elkaar toe.

Want met elkaar kunnen we de wereld weer net iets meer vertrouwen en een betere nachtrust bieden!

Testen: concrete stuurinformatie

Zonder testen geen grip op IT

Een tester kan zich moelijk ontworstelen aan de hoek waar gesomberd wordt: het is nooit goed genoeg en ons dagelijks broodbeleg zijn problemen, bugs en risico’s.

Dat is te kort door de bocht natuurlijk, want testen is vooral een bijzonder leuk en boeiend vak en het is een vast en veelal omvangrijk onderdeel van systeemontwikkeling. Of we nu lineair of in agile en Scrum-termen denken, onafhankelijk testen is onmisbaar voor het verkrijgen van inzicht in kwaliteit, voortgang en risico’s. En in de mate waarin het opgeleverde product voldoet aan overeengekomen architectuurafspraken en externe (compliance) regelgeving.

Een goed ingericht testproces kan het verschil maken tussen een mislukt en een geslaagd IT-project. Opdrachtgevers en projectleiders die niet door testers van harde en feitelijke stuurinformatie worden voorzien, varen op hun gevoel en op de adviezen van degene die het hardst schreeuwt. Zij missen het houvast en het inzicht die nodig zijn voor adequaat ‘supplier-management’ en projectbesturing, en zijn niet in staat sluipende rampen aan te zien komen en af te wenden. Kortom, zij zijn niet ‘in control’.

Testen is dus een zeer concrete en operationele activiteit.

Testen is meer: Business IT Optimization

In de huidige architecturen praten we niet slechts over geïsoleerde applicaties, maar over complexe ketens. Een goede opdrachtgever zoekt transparantie in zijn systemen en projecten en wil op elk niveau goed en feitelijk geïnformeerd zijn. Begrippen in dit verband zijn Corporate Governance (ondernemingsbestuur, een onderneming goed, efficiënt en verantwoord leiden) en IT Governance (de IT-kant van Corporate Governance).

En dat gaat tegenwoordig verder dan slechts het financiële perspectief, traditioneel bewaakt door accountants en controllers. Dat gaat over business-IT alignment van onder af, als organisch onderdeel van systeemontwikkeling en -beheer [2].

In een goed testtraject wordt daarom niet slechts de afwezigheid van fouten in het IT- systeem beoordeeld. Ook de aansluiting bij architectuurprincipes, proces en organisatie wordt actief opgespoord. Dat lijkt misschien een overbodige opmerking, maar in een gemiddeld IT project is er vaak een bepaalde druk om dit soort zaken niet aan de orde te stellen ‘omdat dat niet ons probleem is’. Begrijpelijk, want projectleden hebben dit veelal niet in eigen hand en het proces van analyseren en oplossen van proces- en organisatieverbeterpunten volgt een andere route dan softwarebugs. Maar het gaat vaak wel om de lange termijn stabiliteit van het IT landschap en om cruciale succesfactoren voor de business, dus iemand zal er iets mee moeten doen.

Dit vraagt om een professionele benadering én om samenwerking met aanpalende disciplines, zoals IT architecten en auditors.

Modellen voor testers

Testers hanteren kwaliteitsmodellen zoals het ISO9126 model voor softwarekwaliteit (zie figuur 1). Dit model helpt al enorm om te voorkomen dat er eenzijdige aandacht voor functionaliteit is. De echte risico’s zitten vaak in wat we de “non-functionals” noemen: beheerbaarheid, performance, security, stabiliteit, enzovoort.

Figuur 1: Het ISO9126 model voor softwarekwaliteit

Maar de genoemde aansluiting bij (informatie) architectuur en bedrijfsprocessen vergt een verdere verbreding van het risicoperspectief naar de data- en proceskwaliteit. Zie onderstaand kader “Het IPS model: Informatie-, Proces- en Systeemkwaliteit”.

Rondom het thema kwaliteit en risico’s zijn allerlei denk- en referentiemodellen ontstaan. Een belangrijke categorie vormen de checklistachtige ‘modellen’ die alle kwaliteitsaspecten bevatten. Het SmarTEST IPS-model is zo’n model. Dit soort kwaliteitsmodellen zijn onmisbaar omdat ze een gemeenschappelijke taal en een referentiekader bieden, maar ook omdat ze door hun volledigheid de kans verkleinen dat belangrijke risico’s over het hoofd worden gezien.

 

Het IPS-kwaliteitsmodel kent drie deelmodellen:

Figuur 2 toont per deelmodel de hoofdgroepen, die elk tussen de twee en de tien deelaspecten kennen. Zie SmarTEST [3] voor alle details van het IPS model.

 

Figuur 2: IPS-kwaliteitsmodel

Met deze gewenste verbreding begeeft de tester zich op een terrein waar traditioneel vooral auditors actief zijn. Laten we eens kijken wat we daar mogen verwachten.

Auditing: een onafhankelijk oordeel

Wat is IT-auditing?

Wikipedia verstaat onder ‘auditing’:

  • een (accountants)onderzoek naar een proces/organisatie, of
  • een accountantscontrole van een verantwoordingsstuk, zoals een jaarrekening of (management)rapportage.

Gecertificeerde IT-auditors vervullen functies in interne auditafdelingen of zijn actief als extern ingehuurde consultants. In en vóór organisaties die behoefte hebben aan een onafhankelijke beoordeling, ook van processen en organisaties. De belangrijkste vormen van auditing die een relatie hebben met testen zijn:

  • Operational Auditing: Beoordelen van effectiviteit, efficiëntie en andere aspecten van bedrijfsprocessen, organisatie en ‘Enterprise Governance’.
  • IT-auditing, voorheen EDP-auditing: Beoordelen van IT in relatie tot de bedrijfsprocessen. Het gaat hier vooral om het aantonen dat de functiescheidingen tussen afdelingen ook in het IT-systeem zijn doorgevoerd. En dat in het IT-systeem voldoende controles zijn ingebouwd om foute berekeningen of invoer van foute gegevens vroegtijdig te signaleren.
  • Security Auditing of Forensic Auditing: Beoordelen van de beveiliging en fraudebestendigheid van IT en processen. Welke maatregelen zijn genomen tegen aanvallen van buitenaf? Is het systeem ook nog veilig en fraudebestendig als er onderdelen uitvallen?

Modellen voor auditors

Net als testers hanteren auditors standaarden en modellen, in deze context vaak ‘normenkaders’ genoemd, waarvan CobiT een populaire is. CobiT staat voor Control Objectives for Information and related Technology en is een internationale standaard, gebaseerd op best practices voor IT-beheersing. Auditors gebruiken CobiT om hun werk te structureren en uit te voeren.

Figuur 3 is nogal overweldigend, maar laat goed zien dat CobiT inderdaad de volle breedte van IT Governance beslaat en een compleet referentiekader voor IT auditors biedt.

Figuur 3: CobiT 4.0 Framework

CobiT integreert internationale standaarden zoals ISO 9000 en ITIL. Het is een prima basis om aan te tonen of IT-opdrachtgevers ‘in control’ zijn.

De organisatie achter CobiT, ISACA, heeft nog twee modellen ontwikkeld: Val IT en Risk IT. Al deze modellen kunnen op zichzelf worden gehanteerd, maar ook in onderlinge samenhang. Figuur 4 laat zien hoe ze zich tot elkaar verhouden.

Figuur 4: CobiT, Risk IT en Val IT

Het Risk IT model kan een prima gemeenschappelijk referentiekader bieden voor testers en auditors en komt verderop in dit artikel terug.

Relatie testen en auditing

De verschillen

Fundamenteel voor auditing is dat het oordeel van de auditor onafhankelijk van het lijnmanagement is opgesteld. Daarin verschillen auditors van testers, maar die scheidslijn is niet meer zo hard als enkele jaren geleden.

Auditors en testers ontmoeten elkaar

Het doorlichten en beoordelen van een proces of organisatie valt onder de noemer ‘auditing’. Kunnen testers dit niet beter aan die specialisten overlaten? Niet helemaal, want er is een grote overlap tussen testen van informatiesystemen en ‘auditen’ van IT- en business-processen en organisaties. De integratie van testwerkzaamheden in de reguliere audit- en accountantcyclus staat nog in de kinderschoenen, maar samenwerking en afstemming rond het thema risicomanagement is hard nodig!

Het werkterrein van de auditor is de afgelopen jaren namelijk sterk uitgebreid en is inhoudelijk dichter bij het terrein van de tester komen te liggen. Hiervoor zijn twee redenen aan te geven [4].

Ten eerste is de auditor, door de hoge vlucht die de automatisering van financiële processen heeft genomen, gedwongen om IT-architecturen en systemen diepgaand te doorgronden. Het auditvak kent een groeiende IT-component en gaat meer dan voorheen ‘de systemen in’.

Wat voorheen ‘slechts’ een proces was, een werkwijze conform handboeken en voorschriften, is nu hard vastgelegd in de systemen. Het beoordelen van de processen en de verantwoordelijke managers en organisatie kan niet los van een beoordeling van deze systemen gebeuren. Het grootste deel van het werk van de auditor bestaat uit het vaststellen of de door de software uitgevoerde controles leiden tot de juiste financiële berekeningen. Je zou dit de omwenteling van handmatige naar geautomatiseerde controles kunnen noemen.

Ten tweede heeft compliance wetgeving zoals Sarbanes Oxley (voor ondernemingen met een Amerikaanse beursnotering), Basel 2 en 3 (banken) en Solvency 2 (verzekeraars) nieuwe eisen gebracht ten aanzien van beheersing van de risico’s van bedrijfsprocessen en IT-systemen. Een audit op de financiële boekhouding alleen is niet langer voldoende, want de financiële stromen vertakken zich door de hele organisatie en dienen dus allemaal beheerst te worden. Van de front-end systemen zoals de online winkel tot en met het Grootboek in bijvoorbeeld SAP-FICO. Een compliance audit vergt gedetailleerde knowhow van het applicatielandschap en de infrastructuur.

Het raakt zelfs het hele internetkanaal waarin klanten en zakenpartners zélf de transacties doorvoeren die voorheen door gescreende en betrouwbare backoffice-medewerkers werden gedaan. De backoffice van de organisatie raakt gedistribueerd en kleine onvolkomenheden in de complexe beveiliging scheppen kansen voor inbraak en fraude. Dat stelt allemaal hoge eisen aan de beveiliging en de controleerbaarheid.

Compliance wetgeving heeft ertoe geleid dat de auditor in zijn controlewerkzaamheden ook oog moet hebben voor die kwaliteitscriteria waar traditioneel vooral testers zich op concentreren, bijvoorbeeld ISO-standaard 9126, verbreed naar datakwaliteit en proceskwaliteit (zie kader). Figuur 5 laat zien op welke terreinen er overlap is in de werkzaamheden tussen de tester en auditor.

Figuur 5: Overlap tussen testen en auditen

Door de wol geverfde testers, met affiniteit voor business en communicatie, zijn in principe prima voorgesorteerd om goede auditors te zijn. Ze hebben de systematische aanpak, de tools en de attitude. Wat zij nog missen zijn de specifieke auditvaardigheden, de opleiding én de officiële erkenning die de audit beroepsgroep kenmerken. Daaraan ontlenen auditors, accountants en controllers een mate van gezag waar testers soms jaloers op zijn.

“Ik probeer altijd eerst de auditor achter mijn (vrijgave)advies te krijgen. Dat is al de helft gewonnen. “
- Martin Kooij, test- en verandermanager

Omgekeerd heeft een goede auditor verstand van IT-systemen en -architecturen. Maar technische en functionele testen en het hele proces van verkrijgen van acceptatie door de gebruikers kan de auditor beter aan testers overlaten.

Wat kunnen testers doen?

“Gewoon goed testen”

Op de volgende manieren kunnen risico’s bij de aansluiting bij bedrijfsprocessen en organisatie heel concreet geadresseerd worden in het kader van het ‘normale’ testproces:

Reviews en inspecties

Reviews en inspecties, ook wel ‘statisch testen’ genoemd, zijn een krachtig middel voor kwaliteitscontrole en risicobeheersing. Neem in reviews en intakes van sleuteldocumenten uitdrukkelijk het aspect ‘aansluiting bij bedrijfsarchitectuur en de bedrijfsprocessen’ mee. Dat kan een aparte reviewrol zijn, die door een architect en business-analist wordt ingevuld.

Rollenspelen, droogoefenen, ‘games’

Probeer een aantal business-scenario’s te definiëren en loop daar in detail doorheen. Creëer een spel-achtige setting, waarin verschillende deelnemers elk een eigen rol spelen. Deze werkvorm levert niet alleen veel op, het is ook erg leuk om te doen.

Systeemtesten

Het doel van systeemtesten is nagaan of het project het systeem als geheel ‘conform specificaties’ oplevert. Het referentiekader wordt veelal gevormd door functionele specificaties. Processchema’s en -beschrijvingen kunnen hier ook goede diensten bewijzen en kunnen in de systeemtest vanuit IT-perspectief worden gevalideerd.

Ketentesten

De ketentest is een test waarbij de IT-systemen als black box worden beschouwd: het gaat erom wat erin gaat en wat eruit komt. Zowel vanuit het technische perspectief (‘werkt de keten?’) als vanuit het bedrijfsperspectief (‘komt eruit wat we nodig hebben en is het ook juist?’). De aansluiting bij bedrijfsprocessen en organisatie is een belangrijk element van ketentesten.

Acceptatietesten

In de acceptatietesten zijn acceptanten, gebruikers en beheerders in de lead. Zij zullen van nature en op verschillende niveaus de aansluiting op proces en organisatie beoordelen. Creëer een cultuur waarin hiervoor ruimte en erkenning is. Het is hét middel om (potentiële) frustraties bij gebruikers positief te kanaliseren: door ze aantoonbaar serieus te nemen.

Operationele pilot

De operationele pilot, productiepilot of productie-(acceptatie)test brengt niet zelden allerlei proces- en organisatieknelpunten aan het licht. Het vervelende is dat deze test per definitie erg laat komt. Daarom zijn aanpakken als Scrum (elke ‘sprint’ levert werkende software) gericht op vroegtijdige operationalisatie: elk increment is een functionerend geheel, dat bij voorkeur daadwerkelijk wordt uitgerold en in gebruik genomen.

Tot zover de bijdragen van het reguliere testproces aan het beoordelen van proces- en organisatiekwaliteit. Maar hoe kunnen we nu de samenwerking met die andere groep risicoprofessionals in het speelveld, de auditors, bevorderen?

Hanteer een gemeenschappelijk normenkader

Om te beginnen: zorg voor een gemeenschappelijk referentiekader en één taal. Het reeds besproken CobiT normenkader biedt concrete, op IT-systemen gerichte normen, waaraan relatief eenvoudig maatregelen en acceptatiecriteria gekoppeld kunnen worden, die vervolgens getest en getoetst kunnen worden. De zogenaamde CobiT-‘Audit Guidelines’ bevatten testprocedures voor elk testdoel, in CobiT ‘Control Objective’ genoemd.

Het aan CobiT gerelateerde Risk IT model heeft minder oude papieren en is minder ingevoerd dan CobiT, maar biedt nog meer perspectief als brug tussen testers en auditors.

Figuur 6 laat zien dat dit model uit drie pijlers bestaat:

  • Risk Governance
  • Risk Evaluation (testen!)
  • Risk Response

Figuur 6: Risk IT model

Het mooie van de CRISC-certificering is de focus op operationele risico’s. Wie zich CRISC mag noemen zou bij uitstek in staat moeten zijn de brug te slaan tussen de auditwereld en de testwereld.

Meer tips voor testers

Hier volgen nog een aantal suggesties voor testers en test managers die toegevoegde waarde willen bieden op het grensvlak tussen testen en auditing:

Start altijd met een risicoanalyse

Testen is altijd risicogebaseerd. Auditing ook. Denken in termen van risico’s is een krachtig bindmiddel tussen beide disciplines. Start altijd met een goede risicoanalyse-workshop en breng de risico’s in kaart met de stakeholders. Gebruik bijvoorbeeld de PRIMA toolkit (deze is te downloaden via http://www.smartest.nl/toolstemplates).

Beschouw architecten, controllers en accountants als stakeholders en acceptanten

Zij zijn serieuze belanghebbenden en kunnen de vrijgave van een project of systeem blokkeren. Het is beter om daar tijdig aandacht aan te besteden. De opdrachtgever zal er blij mee zijn.

Pak een rol bij de voorbereiding op een audit

Audits zullen vanwege hun formele en wettelijk geregelde onafhankelijkheid altijd een eigen plaats houden. De essentie is immers dat ze niet aangestuurd worden door het lijnmanagement. Georges Attaya, hoogleraar en vice president van het IT Governance instituut benadrukt dat het ‘rapportcijfer’ wel sterk beïnvloed kan worden met een gedegen voorbereiding. Testers kunnen een grote rol spelen in de voorbereiding (pre-audits) en het vooraf benoemen van verbeterpunten.

Bedenk waar het uiteindelijk om gaat: een goede nachtrust

Uiteindelijk zoeken alle spelers rondom IT projecten en IT Governance maar één ding: vertrouwen. Testers en auditors mogen waar nodig als luizen in de pels optreden, maar dat heeft een hoger doel! Derk-Jan de Grood noemt ze in zijn nieuwe boekje “De helden die voor uw nachtrust zorgen” [5]. Als we uiteindelijk de erkenning krijgen dat we de wereld meer vertrouwen en een betere nachtrust bezorgen dan doen we het goed!

Conclusies

Drie dingen zijn duidelijk:

  1. De disciplines testen en auditen groeien naar elkaar toe
  2. Verbindende referentiekaders en modellen zijn beschikbaar: CobiT en Risk IT
  3. Als testers de titel CRISC ambiëren dan schept dat verwachtingen en verplichtingen

Waarvan akte, wat mij betreft!

Categorie:   
Auteur(s)
afbeelding van egbertbouman
Egbert Bouman
Valori - Lead Consultant

Egbert Bouman is lead consultant, test manager en product manager testen bij Valori. Hij is auteur van SmarTEST, slim testen van informatiesystemen. Hij heeft ongeveer alles getest, van de Walrus onderzeeërs tot het datawarehouse van ING bank. Hij ontwikkelde het IPS model voor informatie-, proces- en systeemkwaliteit en heeft een breed perspectief op kwaliteitsbewaking en kwaliteitsborging. Maar altijd in dienst van “Business IT Optimization” in de echte wereld. Egbert haalt zijn voldoening uit de implementatie van theorie en modellen in de weerbarstige praktijk. Zijn motto is ‘Make it as simple as possible, but not simpler’ (Einstein).

http://www.smartest.nl/

 
Reacties
Jan op vrijdag 9 maart 2012 11:40

Zeker herkenbaar. Geeft een goede weergave van een ontwikkeling dat auditors voor controle van geautomatiseerde beheersmaatregelen of betrouwbaarheid van allerlei rapportages steeds meer moeten steunen op bewijs zoals dit voortkomt uit het testproces. IT-auditors moeten dan ook vooraf een beeld kunnen vormen over de kwaliteit van het testproces.

De toelichting op de definitie van IT-auditing is dan helaas weer wat kort door de bocht, hoewel het hier 30 jaar geleden dan wel mee is begonnen. En wat betreft het verschil tussen RE en CISA, gaat het toch vooral om wat met kan en doet. Qua titel is er gewoon een verschil dat CISA een examen + aantoonbare ervaring betreft, en de RE een post-doc opleiding van 2 jaar + brede aantoonbare ervaring. Maar is een oude discussie.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.