Hur kan man kontrollera att ett datasystem fungerar på avsett sätt? Frågan diskuteras här av Tommy Blomberg, verksam vid revisionskontoret vid redovisningsgrupp riksförsäkringsverket, som anser att testdatametoden ej förtjänar den uppmärksamhet den i dag får i utbildningssammanhang.
När jag 1969 började arbeta som revisor vid försvarets civilförvaltning intresserade jag mig för frågan hur man kontrollerar att ett datasystem fungerar på avsett sätt. Några erfarenheter av ADB-revision fanns då knappt inom statsförvaltningen varför jag hänvisades till litteraturstudier och samtal med revisorer som var verksamma inom den privata sektorn. De metoder jag då anvisades var dels att gå igenom programmen, dels att använda testdata.
Med entusiasmen på topp begärde jag att få utskrifter av de program som hanterade försvarets centrala fakturabetalningssystem. Programmen omfattade tillsammans några tusen COBOL-instruktioner. Trots att systemet ej var särskilt komplicerat (närmast löjligt enkelt jämfört med de socialförsäkrings- och skattesystem jag nu reviderar) fungerade ej metoden. Efter två veckors hårt arbete med att bli en mänsklig kompilator gav jag upp. Efter den betan är jag misstänksam mot vissa läroboksmetoder.
Idag är det kanske inte så många som rekommenderar kompilatormetoden även om man ibland hör talas om den. Testdatametoden lever däremot både i läroböcker och i kurssammanhang.
Mina erfarenheter av att med hjälp av testdata verifiera bearbetningen är att det är en metod med mycket begränsat värde. Metoden förutsätter att revisorn skall konstruera mer heltäckande testdata än vad systemmän, användare och eventuellt också revisorn gjort vid systemtesten. Denna bragd kan man bara lyckas med under förutsättning att man antingen har maximal tur eller att systemen testas mycket slarvigt. Den metod vi istället försöker praktisera vid revisionskontoret vid riksförsäkringsverket kan sammanfattas på följande sätt:
Revisorn bör verka för att en bra testorganisation byggs upp. Testning bör ske flera led från programmerarens enkla programtest till en totaltest av hela systemet. Användarna skall självfallet vara med i testverksamheten. Resultatet av testningen skall bedömas av en grupp där systemmännen är i klar minoritet. Revisorn bör följa testningen på nära håll.
Reglerna för testverksamheten skall självfallet även gälla nya versioner av de olika programmen. Åtminstone min erfarenhet säger att detta oftast är den svagaste länken.
Skapa formella rutiner för rapportering av önskemål om systemförändringar och felrapporter. Denna rutin får ej uteslutande ligga i händerna på systemmännen. Med en bra felrapporteringsrutin kan användarna ge revisorn många goda uppslag. Varför inte belöna felrapporter på samma sätt som förslagsärenden?
Försök se sambanden i felrapporterna. Ibland kan felrapporterna klassas efter systemavsnitt vilket kan avslöja mycket intressanta fakta.
Undersök registren eller databasen med hjälp av särskilda program för att se om registeruppgifterna är riktiga. Vid särskilt stora och/eller komplicerade system är det ofta mycket billigare att göra egna program istället för de gängse standardprogrammen. Detta gäller särskilt i de fall när man vill ställa mer sammansatta frågor som t ex berör flera poster samtidigt.
Efter ovanstående bredsida kan man kanske få intrycket att jag helt vill avskriva testdatametoden. Nej avskriva den helt och hållet vill jag inte, däremot förtjänar den ej den uppmärksamhet den idag får i utbildningssammanhang. För mig är testdatametoden ett försök att stämma i ån snarare än i bäcken. För egen del skulle jag bara kunna tänka mig att använda metoden vid små system med få användare eller när jag misslyckats att stämma i bäcken med de andra metoderna.
Tommy Blomberg, verksam vid revisionskontoret vid redovisningsgrupp riksförsäkringsverket