DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt het testen een vast onderdeel van de werkzaamheden. Aan het begin van het project wordt er tijd voor testen ingepland, waarbij vaak professionele testers het werk uitvoeren. Daarbij worden eisen gesteld aan de manier van testen de kwaliteit van de software en bijbehorende documentatie. In het ideale geval wordt aan het eind van een project de software overgedragen aan de beheerorganisatie, nadat beide partijen aan de hand van acceptatiecriteria vastgesteld hebben dat de software aan de eisen voldoet. In tegenstelling tot projectgroepen hebben veel ICT-beheerorganisaties gemengde gevoelens wanneer het gaat om het testen van software. Een groot deel van de beheerorganisaties besteedt weinig of geen tijd aan het gestructureerd testen van de door hen beheerde applicaties. Dit artikel gaat in op de rol van testen binnen ICT-beheerorganisaties: de oorzaken en gevolgen van de beperkte inzet van testen worden besproken en ook een aantal mogelijke oplossingen. De nadruk ligt daarbij op de rol van testen bij applicatie- en functioneel beheer, maar veel van het besprokene geldt ook voor systeem- en technisch beheer. Redenen om te testen Beheerders kunnen verschillende redenen hebben om software te (laten) testen, de belangrijkste daarvan zijn: - Het in beheer nemen van een nieuwe applicatie of release. - Het vaststellen van Incidents and Problems die door gebruikers worden gemeld. - Het controleren van de correcte werking van een applicatie na een patch. - Het vaststellen van technische en/of performanceproblemen. Bij het in beheer nemen van een applicatie of nieuwe release wordt in de meeste gevallen een aantal testen uitgevoerd om te controleren of de applicatie technisch en functioneel voldoet. Bij Incidents and Problems worden vaak een aantal kleine testen uitgevoerd om te controleren of de klachten terecht zijn. Bij technische en performanceproblemen wordt het vaak al moeilijker om goede testen uit te voeren. Er kunnen meerdere oorzaken zijn voor deze problemen en beheerders ontbreekt het vaak aan tijd en kennis om de exacte redenen vast te stellen. In de praktijk blijkt dat beheerorganisaties vaak niet, of slechts summier testen: medewerkers hebben niet de tijd of de kennis om dit gestructureerd te doen. Er zijn hiervoor verschillende oorzaken aan te wijzen, die hieronder besproken worden. 1
1 Geen goede overdracht naar beheer De hierboven geschetste ideale overdracht van een applicatie van een projectgroep naar de beheerorganisatie komt lang niet altijd voor. Veel voorkomende klachten zijn: wordt betrokken bij de pakketselectie. In het ongunstigste geval bepaalt een groep gebruikers welk pakket ze willen aanschaffen en pas nadat zij hun keuze hebben gemaakt (en het contract is ondertekend) wordt de beheerorganisatie ingelicht. - Technisch en functioneel beheer zijn bij verschillende organisaties ondergebracht. Het komt regelmatig voor dat een externe partij een (web)applicatie bouwt, waarbij wordt afgesproken aan welke functionele eisen moet worden voldaan. Steeds vaker wordt de applicatie geïnstalleerd bij de leverende partij, die het technisch en systeembeheer op zich neemt. Het functioneel beheer wordt door de klant zelf gedaan. Zonder goede acceptatiecriteria en SLA s kan hier een hoop verkeerd gaan. - De acceptatiecriteria zijn onvolledig of op verschillende manieren uit te leggen. Dit geldt zowel voor functionele als technische zaken. - Onvoldoende kwaliteit van meegeleverde documentatie, zoals functionele en technische ontwerpen, gebruikershandleidingen en testscenario s. - Functionaliteit is gewijzigd of weggelaten zonder dat de beheerders hier van op de hoogte zijn gesteld. Bovenstaande zaken kunnen er de oorzaak van zijn dat de kwaliteit van de opgeleverde applicatie te wensen overlaat. Men kan last hebben van technische storingen en performance problemen omdat de applicatie afwijkt van al of niet vastgelegde afspraken. Ook kunnen gebruikers onvoldoende worden ondersteund bij het in gebruik nemen van de nieuwe applicatie en worden er veel incidenten gemeld die in feite te maken hebben met gebrek aan kennis en ervaring bij de gebruikers. - Wanneer software bij een externe leverancier gekocht wordt, dan worden standaardapplicaties vaak aangepast voor een klant. De leverancier kan stellen dat alleen de standaardapplicatie onder hun verantwoording valt, terwijl de beheerders nog geen ervaring hebben met het pakket, laat staan met de klantspecifieke aanpassingen. 2 - Het gebeurt ook dat de beheerorganisatie onvoldoende of te laat
2 Onvoldoende tijd en testkennis Beheerorganisaties ontbreekt het vaak aan kennis en tijd om voldoende en gestructureerd te testen. Daar zijn verschillende reden voor: - Tijdgebrek: De testwerkzaamheden worden niet apart ingepland maar als een onderdeel van het beheerwerk gezien. In de praktijk komt het er vaak op neer dat vóór het in beheer nemen van een applicatie er geen tijd beschikbaar is om uitgebreid te testen. Het wordt belangrijker gevonden dat een incident snel opgepakt wordt. - Gebrek aan testkennis en ervaring: Het is niet voor niets dat het vak softwaretester bestaat. Een ervaren en goed opgeleide tester kan efficiënt test- gevallen en vervolgens testscenario s samenstellen waarbij hij rekening houdt met de gewenste diepgang en zaken als afbreukrisico s. Ook zonder goede documentatie kan een professioneel tester testscenario s leveren die voor beheerders bruikbaar zijn. Beheerders ontbreekt het vaak aan deze kennis en ervaring. - Gebrek aan motivatie: niet iedere beheerder is gemotiveerd om testwerk uit te voeren. Als hij al interesse daarvoor heeft, wordt hij wel door de praktijk beperkt: er is vaak zoveel ander (achterstallig) werk te doen dat het testen niet de hoogste prioriteit krijgt. Ook heeft niet iedereen de gelegenheid om cursussen voor gestructureerd testen te volgen. 3
- Ontbreken van testscenario s: in het ideale geval krijgen de beheerders bij de oplevering van een applicatie een set testgevallen om (regressie)testen uit te voeren maar in de praktijk gebeurt dit zelden. Bovendien zijn na een aantal patches de testgevallen vaak al niet meer actueel. De beheerders zullen daarom vaak zelf de testgevallen moeten opstellen en actueel houden. Gebrek aan tijd, testkennis, ervaring en motivatie zorgen er voor dat de beheerders dit vaak niet doen. Doordat beheerorganisaties onvoldoende en niet gestructureerd (laten) testen lopen ze vaak voortdurend achter de feiten aan. 1 Betrek de beheerafdeling zo vroeg mogelijk bij het project Door al in een heel vroeg stadium zowel de technisch als functioneel beheerders te betrekken bij een software ontwikkelingsproject, voorkomt men veel problemen tijdens de oplevering. De architect, informatie analist en functioneel beheerder moeten weten welke hardware er aanwezig is, welke technische vernieuwingen er voor de komende jaren gepland zijn en hoeveel gebruikers er met de applicatie gaan werken. Deze informatie moet worden verwerkt in de projectdocumenten, waaronder de acceptatiecriteria. Er kunnen ook afspraken worden gemaakt over de kwaliteit en de inhoud van de Door regelmatig en gestructureerd regressietesten uit te voeren worden afwijkingen in de (rand)applicaties sneller opgespoord en kan er sneller worden ingegrepen, soms al voordat de gebruikers deze in de gaten hebben. Verbeteringen Er zijn een aantal mogelijkheden om de kwaliteit van software en documentatie beter te kunnen bewaken. In het algemeen gaat het om bekende oplossingen, maar de praktijk leert dat een organisatie zo in de greep kan zijn van de dagelijkse werkzaamheden dat er geen tijd is om deze oplossingen toe te passen. project-documentatie, inclusief testscenario s; bij de oplevering aan het eind van het project kunnen de beheerders hier dan maximaal gebruik van maken. 2 Zorg voor betrouwbare en bruikbare documentatie Wanneer een beheerorganisatie te maken heeft met onvolledige en/of onbetrouwbare documentatie, is er geen reden om zich hier bij neer te leggen. Het is allereerst belangrijk om een inventarisatie te maken van de beheerde applicaties en de daarbij behorende documentatie en de kwaliteit daarvan. 4
Doordat beheerorganisaties soms onvoldoende en niet gestructureerd (laten) testen kunnen ze voortdurend achter de feiten aan lopen. Vervolgens wordt vastgelegd wat de consequenties van de huidige situatie zijn en wat de gewenste situatie is. De werkzaamheden die nodig zijn om de gewenste situatie te bereiken worden vastgelegd, geprioriteerd en ingepland. Er worden ook afspraken gemaakt voor de toekomst: de eisen waaraan documenten moeten voldoen worden in acceptatiecriteria vastgelegd, evenals de werkzaamheden die de beheerders zelf moeten doen om de documentatie up-to-date te houden. Vaak zal blijken dat er binnen de beheerafdeling onvoldoende tijd, expertise en/of motivatie is om al dit werk zelf te doen. Er kan dan een beroep worden gedaan op deskundigen elders in de organisatie (bijvoorbeeld FO-ers) of op een externe partij. 3 Plan testwerkzaamheden als specifieke taak in. Om er zeker van te zijn dat beheerders de tijd krijgen om gestructureerd en voldoende te kunnen testen is het noodzakelijk om alle testwerkzaamheden als afzonderlijke taken in te plannen. Op deze manier wordt het pas duidelijk hoeveel tijd en mankracht dit kost en kan men dit in de planning en begroting meenemen. 5
Het zal vaak blijken dat dit extra mankracht vergt, maar dit verdient zich snel terug doordat er minder aanloopproblemen zijn bij het in productie nemen van nieuwe releases en doordat Incidents and Problems worden voorkomen of sneller opgelost. 4 Zorg voor voldoende testkennis en ervaring Het is lastig om goed en gemotiveerd te testen als kennis en ervaring ontbreken. Het is daarom nodig dat medewerkers in staat zijn om testopleidingen te volgen. Er zijn organisaties die een opleidingstraject aanbieden waar men via een aantal meerdaagse cursussen leert gestructureerd te testen. Soms is er binnen de beheerorganisatie geen mogelijkheid om nieuwe testers te coachen. Dit kan opgelost worden dit door het inschakelen van testers elders uit de organisatie of via een extern bedrijf. 5 Zorg voor heldere processen rondom Incidents and Problems Rondom het oplossen van Incidents and Problems zijn meestal goede afspraken gemaakt, maar het vastleggen van de hieruit voortvloeiende wijzigingen is vaak minder goed geregeld. Ook voor het verwerken van wijzigingen in handleidingen, functionele en technische ontwerpen en informatie analyses moeten duidelijke werkvoorschriften voorhanden zijn, die bij voorkeur als afzonderlijke activiteiten worden ingepland. Wanneer dit niet gebeurt, dan heeft men binnen de kortste keren te maken met verouderde en onbruikbare documenten die ongeschikt zijn om gebruikers te ondersteunen en om als basis te dienen voor nieuwe releases. De praktijk leert dat een organisatie zo in de greep kan zijn van de dagelijkse werkzaamheden dat er geen tijd is om deze oplossingen toe te passen. 6
6 Onderzoek de mogelijkheid van testautomatisering Wanneer er behoefte is aan het regelmatig uitvoeren van regressietesten, dan is testautomatisering een mogelijkheid om tijd en mankracht te besparen en de kwaliteit van het testproces te verbeteren. Er zijn tegenwoordig zeer betaalbare testautomatiseringsmethoden beschikbaar waar men, met behoud van kwaliteit, tot tientallen procenten op de aanschaf- en licentiekosten kan besparen. Voor het opstellen van de testgevallen kan men bijvoorbeeld deskundigen inhuren; de testuitvoer kan men vaak buiten kantooruren laten draaien, waarbij de volgende ochtend een testrapport klaar staat. Testautomatisering voor beheerorganisaties kan vooral van nut zijn wanneer men één of meer hoofdapplicaties beheert die verbonden zijn met verschillende interne en externe randapplicaties. Van wijzigingen op de hoofdapplicaties is de beheerder meestal goed op de hoogte, maar op wijzigingen van de vele randapplicaties heeft men vaak minder grip. Er zijn tegenwoordig zeer betaalbare testautomatiseringsmethoden beschikbaar waar men, met behoud van kwaliteit, op de aanschaf- en licentiekosten veel kan besparen. 7
Door het regelmatig geautomatiseerd laten uitvoeren van testscenario s vanuit en naar de hoofdapplicaties, kan men de gevolgen van bekende en onbekende wijzigingen goed monitoren. Wanneer men bovenstaande adviezen in de praktijk brengt, zullen veel beheerorganisaties beter gaan presteren. De kwaliteit van de beheerde applicaties en documentatie zal verbeteren, waardoor men meer tevreden gebruikers krijgt. Maar vooral de beheerders zelf zullen hiervan profiteren, omdat het voor meer structuur en rust in het werk en de organisatie zorgt DKTP informatie technologie Veembroederhof 1 1019 HD Amsterdam 020-427 52 21 DKTP Informatie Technologie te Amsterdam heeft veel ervaring met technisch en functioneel beheer, testen en testautomatisering. DKTP s Test & Beheer Service richt zich op beheerorganisaties, met name voor het opstellen en verbeteren van documentatie en acceptatiecriteria, het schrijven en uitvoeren van testscenario s en testautomatisering.