In de huidige ‘ratrace’ van het ontwikkelen van informatiesystemen, wordt steeds vaker vergeten dat we juist informatiesystemen ontwikkelen en niet alleen maar applicaties, software of programmatuur. Het kenmerkt de nieuwe methoden van software ontwikkeling dat zij het hebben over applicatie- of softwareontwikkeling en niet meer over systeemontwikkeling. Toch heeft dit verschil in benaming van hetgeen wat we realiseren een grote impact op de testbasis.
Tijdens de diverse informatica opleidingen word je al het onderscheid geleerd tussen informatiesystemen, applicaties en software. Voor degenen die het vergeten zijn, onderstaand de verschillende definities nog eens op een rijtje.
Informatiesystemen zijn meer omvattend dan applicaties en software. Het feit dat dit soms vergeten lijkt te worden is zorgwekkend. Zoals men op school leert is een informatiesysteem het geheel van mensen, middelen, procedures en regels dat de informatievoorziening verzorgt. Deze set van componenten heeft als doel informatie te verzamelen (zoeken), verwerken, opslaan en verspreiden ter ondersteuning van de besluitvorming, coördinatie en controle binnen een organisatie (bron: Wikipedia).
Applicaties daarentegen zijn één of meerdere computerprogramma's die bedoeld zijn om door de gebruiker direct te worden gebruikt (bron: Wikipedia). Dit zou al inhouden dat een batchverwerkend programma geen applicatie is, maar dat terzijde.
Software of programmatuur zijn termen voor alle computerprogramma's, bibliotheken en bijbehorende data die niet aanwezig zijn bij het starten van een computer, maar achteraf worden geladen (bron: Wikipedia).
De testbasis is alles dat je als tester nodig hebt voor het voorbereiden van welke test dan ook. Detestbasis bestaat uit die producten op basis waarvan een test wordt voorbereid en ontworpen. Dit zijn bijvoorbeeld een functioneel ontwerp, use case-beschrijvingen, AO-procedures, installatiehandleidingen, productiehandleidingen, producthandleidingen, proces- en procedurebeschrijvingen, et cetera.
Verschillen
Testers moeten zich terdege bewust zijn van dit prominente doch subtiele verschil. Als je er vanuit gaat dat er een informatiesysteem wordt ontwikkeld, dan zul je toch andere eisen aan de testbasis moeten stellen dan wanneer er alleen een applicatie of software wordt ontwikkeld. Ga je er als tester vanuit dat er alleen een applicatie of een stuk software ontwikkeld wordt, dan hoef je voor de testbasis niet te rekenen op proces- of procedurebeschrijvingen. Wordt er echter een informatiesysteem ontwikkeld, dan mag je wel eisen dat er een proces- of procedurebeschrijving aan de testbasis moet worden toegevoegd.
Vaak krijg je dan wel een lijvig pak papier of een link naar een intranetsite waar je de informatie kunt vinden. Echter, het komt ook vaak genoeg voor dat men zegt: ‘daar heb je de use case toch voor?' Laat het duidelijk zijn, een use case-beschrijving, hoe vaak ook ondertekend door de business, is geen proces- of procedurebeschrijving. In een proces- of procedurebeschrijving staat meer informatie dan er in een use case op basis van bedrijfsregels (businessrules) staat beschreven.
Use case versus procedure
Een goede use case is beschreven vanuit OTOPOP (One Time, One Place, One Person)-perspectief en heeft met name het doel om de ontwikkelaars te helpen met het ontwikkelen van functionaliteit. Een proces- of procedurebeschrijving is vaak ook beschreven vanuit het OTOPOP-perspectief, maar heeft als doel inzicht te geven in de verantwoording van de waardekringloop. Toch blijkt vaak tijdens de acceptatietest dat er eigenlijk aanpassingen gedaan moeten worden op de proces- of procedurebeschrijvingen, omdat het allemaal net wat anders werkt dan dat men vanuit deze beschrijving heeft opgemaakt. Daarnaast is de proces- en/of procedurebeschrijving ingebed in de beschrijving van de administratieve-organisatie en een use case beschrijving is dat per definitie niet.
Toch gebeurt het steeds vaker dat de testbasis beperkt wordt tot alleen de use case-beschrijvingen, terwijl de acceptatie plaatsvindt op basis van de proces- en procedurebeschrijvingen. Hierdoor krijg je tijdens de acceptatietest discussies over en interpretatie van de procedures, use cases en het informatiesysteem. Op zich allemaal heel nuttig en leerzaam, maar ten tijde van het uitvoeren van de acceptatietest toch eigenlijk een gepasseerd station.
Conclusie
Proces- en procedurebeschrijvingen zijn nu meer dan ooit van importantie bij het realiseren van informatiesystemen, applicaties of software. Wijzigingen, hoe klein ook van omvang, hebben naast impact op het informatiesysteem ook impact op de processen en de procedure's. Met andere woorden: proces beschrijvingen zijn niet jaren `90, maar juist anno nu!
Beste Tom,
Bravo, goed artikel. Herkenbare situatie en gevolgen. Hier ligt voor ons specialisten/adviseurs nog een grote uitdaging. Zelfs zo groot dat het speciale aandacht verdient. Dit is namelijk geen zeldzaam verschijnsel en zeker niet alleen bij kleine organisaties. Ik hoop dat je artikel kansen biedt om dit breed en goed aan te pakken.
Dag Tom,
Als eerste moet mij van het hart dat over dit artikel meer ‘redactering’ op zijn plaats zou zijn geweest; het barst van de spel- en schrijffouten. Beetje jammer, Computable!
Dan het volgende. Ik begrijp de kern van het probleem dat je beschrijft niet. Iemand heeft er baat bij dat er code wordt ontwikkeld. Jij schaart deze code onder één van drie categorieën.
Vervolgens stel je dat een tester op basis van welke categorie deze code valt de tester verwachtingen mag stellen aan de testbasis. Maar wat is nu het feitelijke probleem? Bedoel je te zeggen dat, ongeacht in welke categorie de code valt, er in het ontwerp van deze code een AO beschrijving (of iets dat daarop lijkt) moet worden opgenomen? Bedoel je te zeggen dat louter een Use Case onvoldoende is om een acceptatietest op te baseren?
Beste jaap, het gaat niet zo zeer om de code, ao, use cases of wat dan ook. Het gaat er om dat we lijken / schijnen te vergeten dat we informatie systemen ontwikkelen en geen applicaties of software. We ontwikkelen dus meer dan alleen een stukje code en te vaak kom ik tegen dat we alleen het stukje code testen en vergeten dat het ook nog ergens op aan moet sluiten. De procedures en de processen in de organisatie.