Wanneer een project wordt afgerond gaat het over in de maintenance fase. Het systeem wat projectmatig is geïmplementeerd, zal de nodige jaren gebruikt worden, er zullen nog uit het project resterende defects opgelost worden en nieuwe wensen worden toegevoegd. Het sleutelen aan en daarom testen van het systeem gaat door gedurende de totale levensduur. Dit artikel gaat in op welke aspecten van het testen in de maintenance situatie speciale aandacht vragen
Wees waakzaam voor vooringenomenheid
Stel dat in het project zeer zorgvuldig is getest en het systeem is met alle vertrouwen in productie gebracht. Dan bestaat het gevaar dat het voldoende lijkt om bij een nieuwe release ‘alleen even wat checks te doen op de veranderde onderdelen’. De praktijk is echter weerbarstiger: het testen zal mee moeten bewegen.
Herijk risico’s voor optimale dekking. De context van het systeem in productie is belangrijk: een veranderde context vraagt om een herijking van productrisico’s. In langlopende projecten is het zinvol om de productrisico’s (regelmatig) te evalueren op actualiteit en compleetheid. Is de wet veranderd? Is er een andere leverancier betrokken?
Gebruik diverse bronnen. Neem ‘root causes’ van opgeloste defects door. Hier kunnen aanknopingspunten uitgehaald worden die testen een richting kunnen geven. Dit geldt ook voor de incidenten die in de productie zijn ontstaan; wat lag daar aan ten grondslag? Moet de focus verlegd worden naar andere onderdelen, bijvoorbeeld stabiliteit naast de al afgedekte functionaliteit? Luister mee met de helpdesk. Kijk bij een ander bedrijf die het systeem gebruikt. Recensies op internet..?
Shift in focus. Vanuit de risico’s kan er sprake zijn van een verschuiving van zwaartepunt in de kwaliteitscriteria. Denk aan reliability en compatibility. Het is waarschijnlijk dat er vanuit IT Service Management (ITSM) eisen gesteld worden alvorens een installatie in productie toe te staan. Een beheerafdeling zal vragen hebben als:
• Kan het systeem omgaan met een ‘fail-over’
• Is recovery mogelijk zonder integriteitsproblemen te veroorzaken? (en is het getest..?)
• Hoe gaat het systeem om met eerdere/meerdere versies van zichzelf? Misschien wordt bijvoorbeeld nog niet bij alle gebruikers in één keer dezelfde front end geïnstalleerd.
Nieuwe tijden – maak (nieuwe) proces afspraken
Wanneer een systeem eenmaal in productie is, is het belangrijk de processen goed in te regelen. Daar moet tijdens het project mee gestart worden.
Defect Management. Vaak zit er tijdens het project een vast team bij de ontwikkelende/leverende partij voor de defects: dat schakelt snel. In de maintenance situatie kan men één van meerdere klanten zijn die productieverstoringen zal melden en ook nog releases hanteert om wensen te realiseren. Vragen die daarom gesteld moeten worden hebben betrekking op het proces zelf, maar ook op de known issues:
• Hoe hevelen we known issues over?
• Wie bepaalt hoe known issues in verhouding staan tot nieuwe incidenten?
• Gaat het defect management proces over in een incident management proces en kan laatstgenoemde al eerder aansluiten?
• Welke tools worden er gebruikt?
Het is de praktijk dat men kampt met defects vanuit het project. Als op het eerste oog niet ernstige defects bij elkaar opgeteld worden, kan dat toch resulteren in een kwetsbaar business proces. Defect/incident management kan inzicht geven in hoe zwaar componenten belast zijn met defects. Kan dat gekoppeld worden met vernieuwingen in die gebieden en kan men zo een release samenstellen?
Release Management. Release management implementeert verbeteringen en wensen. Vragen die daarbij spelen zijn:
• Hoe vaak zal er een release op het systeem uitgebracht worden?
• Hoe wordt de release samengesteld?
• Op basis van welke gegevens?
• Hoe wordt vastgelegd welke componenten zullen wijzigen zodat duidelijk is welke onderdelen wijzigen?
Eerder werd aangestipt dat informatie vanuit het testen waardevol is voor het samenstellen van releases. Maar ook vanuit de noodzaak vast te kunnen stellen welke elementen bij een nieuwe release opnieuw bekeken moeten worden. Niet alleen voor de wijzigingen, maar ook vanuit een validatie dat wat niet gewijzigd is, onveranderd blijft werken.
Mocht er een bestaande testset zijn die belangrijke checks uitvoert, vergeet die dan niet te beoordelen: een verandering kan nodig zijn als gevolg van een release. Hier is dan ook weer een relatie met de product risico’s.
De techniek, welke eisen stellen we. Testen in een maintenance situatie vraagt hernieuwd nadenken over het testen, maar ook de (ondersteunende) techniek vraagt speciale aandacht. Hoe gaat men om met:
• Testomgeving
• Testdata
• Tools
Testomgeving. In het project is het al lastig om de juiste testomgeving beschikbaar te hebben. In de maintenance fase is dit vaak nóg complexer: de omgeving moet vaak gedeeld worden voor bijvoorbeeld het debuggen van productie problemen of er lopen projecten die het systeem nodig hebben. Een strakke regie, inclusief inzicht in de software levels en interfaces, is dan noodzakelijk. Enkele voorbeelden van punten waar afspraken over gemaakt moeten worden:
• Wie mag een data dump of roll back doen?
• Wie mag welke data gebruiken?
• Wie mag een systeem datum aanpassen?
Tools. Is de intentie om tools die tijdens het project ontwikkeld zijn daarna ook te gebruiken? Houd daar meteen rekening mee en betrek relevante afdeling(en). Er kunnen regels zijn waar men aan moet voldoen voordat ze eventueel voor een breder publiek beschikbaar gemaakt worden en onderhouden. Denk hierbij aan data creatie/scramble tools.
Datgene wat in het project geregeld was, moet ook geregeld worden in de maintenance situatie en wordt weleens onderschat. De transitie moet tijdig ingezet worden zodat niemand onplezierig verrast wordt. Of nog erger, dat de brand uitbreekt maar niemand weet waar de brandslang hangt, laat staan hoe die werkt en of die nog wel werkt.
Greet Burkels, testadviseur/-manager bij Professional Testing
