Regressietesten De aanpak en aandachtspunten Algemene informatie voor medewerkers van: SYSQA B.V.
Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING...3 1.1 ALGEMEEN...3 1.2 VERSIEBEHEER...3 2 WAT IS REGRESSIETESTEN?...4 3 WAAROM REGRESSIETESTEN?...4 4 WANNEER REGRESSIETESTEN?...4 5 KOSTEN VAN REGRESSIETESTEN...5 6 RANDVOORWAARDEN VOOR REGRESSIETESTEN...5 7 TESTTOOLS...5 8 AANPAK VOOR REGRESSIETESTEN...6 8.1 INTAKE...6 8.2 OPSTELLEN REGRESSIETESTSTRATEGIE...6 8.3 VOLDOEN AAN RANDVOORWAARDEN...8 8.4 UITVOEREN VAN DE REGRESSIETEST...8
Organisatie SYSQA B.V. Pagina 3 van 8 1 Inleiding 1.1 Algemeen Doel van dit document is de aanpak voor het toepassen van regressietesten vastgelegd. Het document kan gebruikt worden als aanvulling op Tmap bij het voorbereiden en uitvoeren van regressietesten, zowel in onderhouds- als in nieuwbouwtrajecten. 1.2 Versiebeheer Versie Status Datum Opmerkingen 0.1 Concept 16 juni 2000 Eerste concept 1.0 Definitief 30 juni 2000 Aanpassingen en definitief maken
Organisatie SYSQA B.V. Pagina 4 van 8 2 Wat is regressietesten? Regressie is de zekerheid dat de kwaliteit van het systeem niet terugloopt. Bij een regressietest wordt een eerdere test opnieuw uitgevoerd om de gevolgen van een doorgevoerde wijziging of correctie op de rest van het systeem te controleren. Een regressietest stelt vast of het informatiesysteem nog steeds volgens specificaties functioneert. Op het eerste gezicht verschilt regressietesten daarmee niet zoveel van normaal gestructureerd testen. Nog steeds zijn bijvoorbeeld testplanning, fasering en testtechnieken van toepassing. Vanwege het herhalen van de test is er echter een aantal specifieke aspecten waar rekening mee moet worden gehouden. In hoofdstuk 8 treft u deze aspecten aan. Een regressietest vormt integraal onderdeel van een systeem-, integratie of acceptatietest. Naast het testen van nieuwe of gewijzigde functionaliteit wordt in de regressietest het gehele systeem doorgemeten om vast te stellen of het systeem als geheel nog steeds functioneert conform specificaties. 3 Waarom regressietesten? Uit onderzoek is gebleken dat, vergeleken met een nieuw systeem, systemen waarop onderhoud wordt gepleegd 10 maal vaker fouten bevatten (Interface Design Group, 1997). Dit komt omdat het aanpassen van systemen vele malen moeilijker is gebleken dan een nieuw systeem te ontwikkelen. Oorzaak van deze hoge foutscore ligt vermoedelijk in het gegeven dat diegenen die wijzigingen aanbrengen, vaak anderen zijn dan de originele bouwers. Een andere mogelijke oorzaak is het gegeven dat er niet voldoende gedocumenteerd is of dat de documentatie niet meer up-to-date is. Nu hoeft het niet zo te zijn dat die veelvoud van fouten zit in de systeemdelen waar de wijzigingen worden doorgevoerd. Vaak zitten de fouten juist in andere delen van het systeem. Wijzigingen en/of uitbreidingen op een bepaald systeemonderdeel veroorzaken regelmatig fouten in andere systeemonderdelen. Dit geeft aan waarom er te allen tijde een regressietest moet worden uitgevoerd. Als er geen regressietest zou plaatsvinden, dan zouden die nieuwe fouten niet ontdekt worden. Immers, alleen de wijzigingen en/of uitbreidingen worden getest. Door middel van deze regressietest wordt zeker gesteld dat de kwaliteit van het systeem als geheel niet terugloopt. 4 Wanneer regressietesten? Er zijn enkele mogelijkheden om tot regressietesten over te gaan: Systeemaanpassingen in een ander deel van het informatiesysteem. Wijziging in de omgeving (ander platform, hardware componenten worden vervangen, ander ontwikkelplatform). Iedere keer dat er een wijziging en/of uitbreiding op een bestaand systeem plaatsvindt (softwareen/of hardwarematig). Dat kan zowel plaatsvinden als het systeem in productie is als in de préproductiefase. Als het systeem in productie is worden systemen regelmatig aangepast omdat de business dat verlangt, de wetgeving verandert, door technisch vooruitgang of om andere redenen. Elke keer als na een aanpassing het veranderde systeem in productie moet worden genomen, mag de kwaliteit van het systeem als geheel niet zijn teruggelopen. Dat kan alleen gegarandeerd worden door er een regressietest op uit te voeren. In de pré-productiefase worden er ook regelmatig aanpassingen gedaan nadat het leeuwendeel van het nieuwe systeem reeds is voltooid. Dat gebeurt dan omdat het nieuwe systeem nog niet helemaal voldoet aan wat de business verlangt of omdat het nog niet goed aansluit op het administratieve proces of om andere redenen. Ook nu dient er na elke aanpassing een regressietest plaats te vinden, voordat het definitief in produktie gaat.
Organisatie SYSQA B.V. Pagina 5 van 8 Voor zowel de pré-productie- als de productiefase geldt dat er aanpassingen plaats kunnen vinden, omdat er zich fouten bevinden in het systeem. Als dat het geval is, dan dienen de systeemonderdelen waarin de fouten zijn hersteld te worden hertest conform de richtlijnen die daarvoor gelden. Maar ook hierbij dient er nog een regressietest plaats te vinden. Welke systeemdelen in aanmerking komen voor een regressietest wordt per situatie bekeken (zie ook hoofdstuk 7). 5 Kosten van regressietesten Uit het bovenstaande lijkt het elke keer moeten uitvoeren van een regressietest veel extra werk. Toch is dat niet het geval. Het testproces bestaat uit 5 fases: planning en beheer, voorbereiding, specificatie, uitvoering en consolidatie van testware. Ongeveer 60% van de totale testinspanning bij testen wordt besteed in de voorbereidings- en specificatiefase. Wanneer er voor het te testen systeem reeds herbruikbare testware aanwezig is, dan is er voor elke regressietest een minimale inspanning nodig om de voorbereidings- en specificatiefase te voltooien. Er is namelijk al voorbereid en gespecificeerd tijdens de test. Dit betekent dat elke regressietest niet 100% extra testinspanning vergt (zoals deze is gebruikt in de acceptatietest), maar ongeveer 40%. Er kunnen afwijkingen op dit percentage voorkomen als er alleen correctieve aanpassingen hebben plaatsgevonden (het percentage zal dan wellicht iets kleiner worden), of als er sprake is van het toevoegen van nieuwe functionaliteit (het percentage zal dan iets groter zijn, omdat de aanpassingen ook invloed kunnen hebben op de bestaande testware), etc. Het impliceert wel dat in voorgaande testtrajecten aan consolidatie van testware is gedaan. Anders zouden de testscripts voor een regressietest opnieuw moeten opgebouwd, hetgeen leidt tot een hogere opslag dan 40%. Gezien de relatief lage kosten en het realiseren van een hogere betrouwbaarheid van het systeem loont het in de praktijk zeer de moeite om na elke aanpassing een regressietest uit te voeren. 6 Randvoorwaarden voor regressietesten Om een regressietest succesvol en met zo weinig mogelijk inspanning te kunnen uitvoeren, dient aan een aantal voorwaarden te worden voldaan. Dit zijn de randvoorwaarden die in elk testtraject aan de orde zijn (zie Tmap Checklist Randvoorwaarden en uitgangspunten). Daarnaast moet specifieke aandacht geschonken worden aan onderstaande 4 randvoorwaarden. 1. Alle documentatie (zowel testdocumentatie als systeemdocumentatie) moet actueel, volledig en onderling consistent zijn. 2. Er moeten heldere en correcte verwijzingen van de testware naar de systeemdocumentatie (en naar het systeem zelf) zijn. 3. Het te testen systeem moet functioneren conform specificaties en er moet bekend zijn welke veranderingen er hebben plaatsgevonden in het systeem. Tevens moet bekend zijn hoe en waar in andere delen van het systeem deze veranderingen invloed hebben. Er moet inzicht zijn in programmastructuren zowel in technisch als functioneel opzicht. 4. Voor kwalitatief goede testware is correct versiebeheer noodzakelijk. Bij elke (regressie)test dient vastgesteld te worden dat de juiste versies van de bestanden, sources, documentatie, systeemsoftware, hardware componenten e.d. gebruikt worden. 7 Testtools Voor het uitvoeren van regressietesten kan het interessant zijn record & playback testtools in te zetten. Tools bereiken in de regel een hoge mate van betrouwbaarheid van de test.
Organisatie SYSQA B.V. Pagina 6 van 8 Echter, de aanschaf van een testtool en de implementatie ervan nemen relatief hoge kosten met zich mee. De terugverdientijd is uit te drukken in aantallen regressietesten. De ervaring is dat de baten tegen de kosten opwegen indien een regressietest ongeveer 3 tot 5 keer herhaald kan worden (uiteraard ook afhankelijk van de grootte van het systeem, de kenmerken van het informatiesysteem, de data-bestanden, benodigde invoer e.d.). Het informatiesysteem moet stabiel zijn om het meeste effect en efficiency uit de inzet van het record & playback testtool halen. Aanpassingen in het systeem die betrekking hebben op databases en functies grijpen relatief sterk in in de testscripts die worden gebruikt bij het toepassen van testtools. Maar vooral ook in de programma-scripts die met de tool zijn gemaakt. 8 Aanpak voor regressietesten Om tot een regressietest te komen, kunnen we op hoofdlijn vier fases onderscheiden. 1. Intake op huidige situatie met betrekking tot de randvoorwaarden uit hoofdstuk 6. Er wordt bepaald in welke mate voldaan wordt aan de randvoorwaarden. De bevindingen worden gerapporteerd en vormen mede de basis voor het bepalen van de te nemen regressieteststrategie. 2. Opstellen regressieteststrategie. 3. Voldoen aan de randvoorwaarden opdat de teststrategie voor een regressietest uitgevoerd kan worden. 4. Uitvoeren van de regressietest. 8.1 Intake Specifiek voor de regressietest wordt een intake uitgevoerd op onderstaande punten. De status van de test- en systeemdocumentatie. Wat is er aan documentatie, hoe actueel, volledig en onderling consistent is het? In hoeverre staan er verwijzingen in de testware naar de bijbehorende systeemdocumentatie? Gecontroleerd wordt op juistheid en volledigheid van de verwijzingen, en wat de mate van detail is van de verwijzingen. In hoeverre staan er verwijzingen in de testware naar de bijbehorende systeemdelen? In hoeverre sluit de testware aan op de werking van het systeem; hoe juist, volledig en gedetailleerd zijn de verwijzingen naar het systeem? In welke mate functioneert het systeem conform systeemdocumentatie? Welke veranderingen (functioneel en/of correctief) zijn aangebracht in het systeem? In welke delen van het systeem hebben deze veranderingen invloed? In hoeverre en in welke mate zijn de veranderingen in het systeem gedocumenteerd in de systeemdocumentatie? In hoeverre is bekend met welke versies bestanden, sources, documentatie, systeemsoftware, hardware componenten e.d. getest wordt / moet worden? Er ontstaat met de intake inzicht in de mate van samenhang en onderlinge aansluiting van testware, systeemdocumentatie en programmatuur. De bevindingen vormen onderdeel voor het opstellen van een teststrategie. 8.2 Opstellen regressieteststrategie De basis voor het opstellen van een regressieteststrategie wordt gevormd door: Beschikbare budget voor regressietesten. Beschikbare testtijd voor regressietesten.
Organisatie SYSQA B.V. Pagina 7 van 8 Gewenste betrouwbaarheid en andere acceptatiecriteria gesteld aan het systeem of bepaalde systeemdelen (zoals bedrijfskritische processen ondersteunen, die bepaalde kritische bedrijfseigenschappen moeten realiseren, die in het verleden relatief veel problemen in produktie opleverden en/of die cruciale interfaces met omliggende systemen hebben). Bevindingen uit de intake op de randvoorwaarden. Gevolgen uit de intake v.w.b. het kunnen realiseren van de gewenste betrouwbaarheid van het systeem of systeemdelen, alsmede de benodigde tijd en capaciteit om een inhaalslag te doen op de testware en systeemdocumentatie. Per testtraject moet met de betrokkenen (projectleider, testmanager, accountantsdienst/controller, opdrachtgever, lijnmanagement etc.) een afweging gemaakt worden om tot een gewenste strategie te komen. De strategie geeft aan: Wat de acceptatiecriteria zijn voor de regressietest. Hij geeft o.a. inzicht in de gewenste betrouwbaarheid van het systeem/de systeemdelen. De criteria zijn dermate concreet en meetbaar dat ze eensluidend getest kunnen worden. De diepgang en dekkingsgraad van de regressietest. Welke systeemdelen en/of welke functies binnen welke systeemdelen en/of interfaces worden met welke diepgang getest? Welke uitspraken wil men doen op basis van de gekozen diepgang en dekkingsgraad? Welke testtechnieken worden toegepast en welke acceptatiecriteria toetsen ze? De verdeling van testtijd/inspanningen over de systeemdelen, functies, interfaces en acceptatiecriteria. De acties die uitgezet worden om aan de randvoorwaarden voor de gewenste regressietest te voldoen (inhaalslag op de testware en systeemdocumentatie). En vooral de onderbouwing van de regressieteststrategie. Leg de besluitvorming hierover vast, zodat een verantwoording van keuzes later snel en eenvoudig kan worden gemaakt. Voor het kiezen van te testen systeemdelen, functies en interfaces zijn er 4 alternatieven. 1. Men kan een keuze maken om maar één deel van het systeem met een regressietest te raken (krimpen in de breedte). 2. Men kan er ook voor kiezen om elk deel van het systeem te testen, maar niet met dezelfde diepgang als bij de systeem-, integratie- of acceptatietest (krimpen in de diepgang). 3. Men kan de hoeveelheid werk beperken door het zogenaamde steen-in-vijver principe. Stel, de plaats waar de steen het water raakt is de plaats waar de wijziging in het systeem heeft plaatsgevonden. Dan wil het principe zeggen dat hoe verder een bepaalde functie afstaat van de wijziging (qua afhankelijkheid of qua belangrijkheid), hoe minder uitgebreid zo n functie getest hoeft te worden en andersom. Hoe dichterbij een bepaalde functie staat van de wijziging (qua afhankelijkheid of qua belangrijkheid), hoe uitgebreider zo n functie wordt getest. 4. Een vierde optie is om alleen de bedrijfskritische functies te regressietesten. Hierbij wordt geen rekening gehouden met de invloed van wijzigingen op andere delen van het systeem, maar neemt men genoegen met de wetenschap dat alleen de belangrijkste functies foutloos werken. Van de overige functies heeft men dus geen kwaliteitsoordeel en worden er voor die delen risico s genomen. Sterker nog, wanneer sommige bedrijfskritische functies afhankelijk zijn van andere functies, dan loopt hiermee ook het bedrijfskritische proces gevaar. Kortom, de laatste optie is mogelijk, maar dan moet men zeker weten dat er niet te veel risico s voor het bedrijfskritische proces worden gelopen.
Organisatie SYSQA B.V. Pagina 8 van 8 8.3 Voldoen aan randvoorwaarden Indien uit de intake op de randvoorwaarden en de gekozen regressieteststrategie naar voren is gekomen dat invulling aan de randvoorwaarden in bepaalde mate noodzakelijk is, volgt fase 3, het voldoen aan de gewenste randvoorwaarden. Afhankelijk van de strategie spelen onderstaande stappen een rol. 1. Synchronisatie van het systeem en de systeemdocumentatie. De werking van het systeem is hierbij leidend. Dit is geen activiteit van een testteam, maar hoort thuis bij de eenheid die verantwoordelijk is voor de systeemdocumentatie. 2. Opstellen en/of aanvullen van de testware voor het bestaande systeem. Het realiseren van consistentie, correctheid en volledigheid van testware t.o.v. het systeem. Deze stap kan parallel aan stap 1 worden uitgevoerd. Deze stap is wel de verantwoordelijkheid van het testteam. De testware wordt zodanig aangepast dat voldaan wordt aan de keuzes die ten grondslag liggen aan de strategie. De testware moet dienen tot het toetsen van vooraf benoemde acceptatiecriteria en vooraf benoemde systeemdelen, functies en interfaces. 3. Bij het opstellen en verbeteren van de testware wordt aangegeven hoe de testgevallen afgeleid zijn van de logisch testsituaties en die op hun beurt van het systeem. Zo weet je welke systeemfuncties je test met welke logische en fysieke testgevallen. En ben je snel in staat later testware aan te passen als bepaalde systeemfuncties worden gewijzigd of toegevoegd. 4. Zekerstellen dat het systeem, de systeemdocumentatie en de testware onderling consistent zijn. Zekerstellen dat er heldere en correcte verwijzingen van de testware naar de systeemdocumentatie zijn. 5. Aanpassen van de systeemdocumentatie naar aanleiding van de systeemwijzigingen. Dit is geen activiteit van het testteam, maar van de eenheid die verantwoordelijk is voor de systeemdocumentatie. 6. Aanpassen testware op grond van de gewijzigde systeemdocumentatie. Hiervoor geldt de aanpak voor testvoorbereiding en -specificatie die in Tmap wordt beschreven. 8.4 Uitvoeren van de regressietest Voor het uitvoeren van de regressietest gelden dezelfde stappen en aandachtspunten die voor testuitvoering van toepassing zijn, welke uitvoerig in Tmap worden beschreven. Let wel: wanneer er bevindingen zijn als gevolg van de regressietest, zorg eerst dat de gecorrigeerde functionaliteit eerst sec wordt gehertest, totdat hij correct functioneert, voordat weer de regressietest start.