16. TAAKGEBIED TESTEN Testen is een vakgebied dat werkzaamheden omvat die zich uitstrekken van diep in de techniek tot diep in de gebruikersorganisatie. Binnen MCTL wordt uitsluitend het functionele deel in ogenschouw genomen. De invalshoek binnen MCTL is niet het gewijzigde systeem, maar de wijzigingen in het bedrijfsproces. Dit businessperspectief betekent dat er getest wordt vanuit een beoogd gewijzigde werkwijze / bedrijfsproces in samenhang met de daarvoor aangepaste computertechnologie: software, databases en/of hardware. ACHTERGROND Testen kan worden gezien als onzekerheidsreductie. Goed beschouwd zou met precies de juiste input en de precies de juiste uitvoering van de aanpassingen, testen overbodig zijn. Helaas kan vanaf het moment dat een wijziging wordt geïnitieerd tot en met realisatie van alles mis gaan. Via testen is alleen in theorie 100% zekerheid te krijgen dat de gerealiseerde wijziging 100% correct is. Praktisch gesproken is dat niet zo, maar testen kan wel aantonen dat bepaalde aspecten in orde zijn. Hoe beter de testomgeving, hoe beter de testdata, testscript en het testteam, hoe hoger de zekerheid dat de gerealiseerde wijziging ook aan de verwachting voldoet. DEFINITIES Binnen het taakgebied testen worden enige termen gebruikt die ook wel in de praktijk voorkomen. Helaas wil er zeker op het gebied van testen nog wel eens verwarring zijn over welke term waarvoor staat. Daarom worden ze hieronder gedefinieerd: Definitie Toetsen Toetsen is het beoordelen van tussenproducten in het gehele wijzigingstraject Definitie Testen Testen omvat activiteiten die inzicht geven in en adviseren over de kwaliteit van eindproducten en de daaraan gerelateerde risico s Definitie Functionele acceptatietest (FAT) De functionele acceptatietest is een door functioneel specialisten uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de functionele eisen voldoen Definitie Gebruikersacceptatietest (GAT) De gebruikersacceptatietest is een door (een vertegenwoordiging van) de toekomstige gebruikers uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen van de gebruikers voldoen Definitie Productieacceptatietest (PAT) De productieacceptatietest is een door (een vertegenwoordiging van) de toekomstige beheerders uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test V1.0 Pagina 1
moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen vanuit beheer voldoen. Beheer kan hierbij zowel de technische als functionele kant betreffen, hoewel de nadruk vaak sterk op de technische kant ligt. Definitie Acceptatiecriteria Acceptatiecriteria zijn meetbare condities waaraan voldaan moet zijn om een aangepast systeem in productie te nemen. Het opstellen en onderhouden van acceptatiecriteria vindt plaats in kwaliteitsmanagement. Het taakgebied Testen is een belangrijke gebruiker van de acceptatiecriteria. DOEL VAN DIT TAAKGEBIED Testen omvat het controleren of de gerealiseerde wijzigingen aan de gedefinieerde behoefte en specificaties voldoen en daarnaast aan de gestelde kwaliteitsnormen en vanzelfsprekende (dus niet expliciet gedefinieerde) behoeften en specificaties. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel wordt bereikt: Het aantal fouten dat is geconstateerd nadat de wijzingen in productie zijn genomen is < 2 % van het aantal bevindingen dat in de verschillende tests is geconstateerd en verholpen De totaal aan tests bestede tijd / hoeveelheid geld is < 50% van de schade die zou zijn ontstaan in productie indien de bevindingen in test niet al voor productie waren hersteld. (Genoemde percentages zijn uiteraard indicatief) INPUT, ACTIVITEITEN, OUTPUT De activiteiten in dit taakgebied zijn als volgt schematisch weer te geven: V1.0 Pagina 2
Toetsen vind plaats op de diverse tussenproducten en testen op de diverse eindproducten. Hierna worden ze toegelicht. 1. TOETSEN SPECIFICATIES EN OPGELEVERDE ONTWERP-PRODUCTEN Toetsen, het controleren van tussenproducten, kent verschillende technieken. Degenen die het meest bruikbaar zijn in de context van MCTL zijn: 1. Inspecties. Hierbij wordt een product beoordeeld dat 100% gereed is, maar nog niet definitief is vastgesteld. Door een team van mensen wordt vooraf gestructureerd gezocht naar bevindingen in de te inspecteren documenten. Tijdens de inspectiebijeenkomst worden deze bevindingen besproken en dient er overeenstemming over te ontstaan. Ook nieuwe bevindingen, die tijdens de bijeenkomst ontstaan, worden besproken en ook daarover dient overeenstemming te ontstaan. Na de bijeenkomst past de auteur het document aan en kan eventueel een herinspectie plaatsvinden. 2. Reviews. Reviews worden gedaan op producten die nog niet helemaal af zijn (60-80% gereed). Een review richt zich op het vinden van fouten, maar ook op het verbeteren van het document door de kennis en vaardigheden van degenen die de review uitvoeren. Ze mogen zich dus ook met de oplossingsrichtingen bemoeien en voorstellen voor verbetering doen. 3. Walkthrough. Bij een walkthrough wordt het document, dat voor 50-100% gereed is, stapsgewijs doorlopen. Daarbij kan de auteur een toelichting en bijvoorbeeld ook de keuzemogelijkheden en overwegingen daarin geven. De andere deelnemers kunnen direct reageren. Het is een erg interactieve manier van werken, waarbij wel het gevaar van ad-hoc discussies bestaat. Aan de hand van bovenstaande schema zijn de volgende toetsmomenten te definiëren: Requirements management / specificaties Het achterhalen van requirements en vervolgens opstellen van specificaties is het onderdeel waarin het het meest zinvol is om input te krijgen uit zo veel mogelijk relevante bronnen. Ook bij toetsen is het mogelijk via reviewen en walkthroughs niet alleen fouten te achterhalen, maar ook inzichten van degenen die deelnemen aan de review cq. walkthrough mee te nemen. Bovendien kan hier door anderen worden gecheckt of niet te snel naar één bepaalde uitwerking / oplossing is toegewerkt, of consequenties per oplossingsrichting inderdaad allemaal in beeld zijn en afgewogen, en of er ook vanuit de infra en support groep en evt. leverancier voldoende inbreng is geweest. Ontwerp In ontwerp worden een aantal modellen, diagrammen en beschrijvingen bijgewerkt op basis van de in Requirements management opgestelde specificaties. Deze bijgewerkte ontwerp-elementen kunnen via inspectie worden getoetst. Eventueel, indien bijvoorbeeld een onderdeel van het systeem nieuw is of sterk wordt gewijzigd, kan ook via reviews en walkthroughs het toetsteam meer worden betrokken in de oplossingen en worden gevraagd hierin mee te denken. De inhoudelijke controle op juistheid en volledigheid dient echter altijd de overhand te houden. Realisatie Hier kan een check worden uitgevoerd of alle (gewijzigde) configuratie-instellingen en parameters zijn beschreven (volledigheid) en vanzelfsprekend ook juist zijn. Tevens is een check op onderlinge V1.0 Pagina 3
strijdigheid en ook op aannemelijkheid (m.n. als bijv. parameters heel sterk wijzigen, of de onderlinge verhoudingen tussen de parameters sterk wijzigen) een aan te bevelen activiteit. Inspectie is een hiervoor de hand liggende techniek. Transitie In het taakgebied transitie wordt een transitieplan opgesteld. Binnen Testen kan het bijgewerkte transitieplan worden getoetst voordat dit plan binnen Transitie wordt uitgevoerd. Ook hier kan inspectie goede resultaten opleveren. Eindresultaat is steeds een gestructureerde terugkoppeling aan de opstellers van de specificaties, ontwerpen, plannen etc. Afhankelijk van de omvang en aard van de terugkoppeling kan worden afgesproken dat de aanmerkingen worden verwerkt en nogmaals getoetst, of dat een hertoetsing niet nodig is. 2. CHECK OP DOOR DE INFRA EN APPLICATIE SUPPORT EN LEVERANCIERS UITGEVOERDE TESTS Het echte testen start met een check op de door de infra en applicatie support en leveranciers uitgevoerde tests. In TMap termen spreken we dan van de Unittest (UT), de Unitintegratietest (UIT) en de Systeemtest (ST). In het geval er binnen infra en applicatie support een agile-achtige werkwijze wordt gevolgd, zijn de verschillende tests soms wat minder eenvoudig te onderscheiden. Voorop blijft staan dat iemand die iets creëert (in dit geval bijvoorbeeld een programmeur), allereerst ook zijn eigen werk zal moeten controleren. Daarna pas komen degenen in beeld die het resultaat van dit werk uiteindelijk ook zullen gaan gebruiken (gebruikers en de functioneel specialisten). Tevens speelt hier wel mee dat een infra en applicatie support en leveranciers vaak wat andere faciliteiten ter beschikking hebben dan een gebruikersorganisatie. Voorbeelden hiervan zijn tools waarmee rechtstreeks data in een testdatabase kan worden gemanipuleerd en het simuleren van een grote workload op een systeem. Van infra en applicatie support en leveranciers mag worden verwacht dat de unittest, de unitintegratietest en de systeemtest voldoende worden uitgevoerd. Binnen deze testsoorten kunnen verschillende testvormen worden onderscheiden. Uiteraard moeten de wijzigingen op zichzelf, zowel technisch als tot op zekere hoogte functioneel, door infra en applicatie support en leverancier worden getest. Daarnaast zijn nog te noemen: de back-up & restore test, de technische conversietest, de penetratie/beveiligingstest, herstartbaarheidstest, installatietest, de-installatietest en uitwijktest (zie aan het eind van dit taakgebied een uitgebreidere beschrijving van alle testsoorten en testvormen). De scheidslijn van waar de verantwoordelijkheden van infra en applicatie support en leverancier ophoudt en die van de functioneel support cq gebruikersorganisatie begint is nog niet zo heel makkelijk te bepalen. Een aantal voorbeelden ter illustratie: Een softwareleverancier voert regelmatig updates uit op de software die zij levert. Omdat zij niet tot in den treure op de hoogte is van alle specifieke klantomgevingen, hebben zij een interne referentieomgeving opgetuigd. Het zal duidelijk zijn dat deze softwareleverancier wel kan worden aangesproken op het juist functioneren van de software (technisch en functioneel) in die V1.0 Pagina 4
referentieomgeving, maar niet in een klantomgeving die hiervan afwijkt. Een softwareleverancier levert via een cloudoplossing feitelijk geen softwaresysteem meer, maar een werkende functionaliteit. In dit geval kan deze leverancier zeker worden aangesproken op het technisch en functioneel volledig juist functioneren van het geheel. Een klantorganisatie besluit een standaardsoftwarepakket functioneel geheel afwijkend in te zetten in de organisatie. Infra en applicatie support en leverancier doet aanpassingen op het pakket, maar de klantorganisatie zal zelf moeten controleren of de afwijkende werkwijze na die aanpassingen nog steeds wordt ondersteund door het pakket. Om duidelijkheid te scheppen in de scheiding tussen werkzaamheden van infra en applicatie support en leverancier enerzijds en functioneel support en de gebruikersorganisatie anderzijds kan met een zogenaamde intake worden gewerkt. Op het moment dat door de van infra en applicatie support en leveranciers iets wordt opgeleverd, wordt door functioneel support een intake gedaan waarbij een aantal vooraf vastgestelde elementen worden gecheckt. Op die wijze is al snel duidelijk of de oplevering retour afzender kan worden gestuurd, of dat functioneel support met de functionele acceptatietest aan de slag kan gaan. Het is immers niet de bedoeling dat functioneel specialisten en / of gebruikers testen gaan uitvoeren die feitelijk door infra en applicatiesupport of leveranciers hadden moeten worden gedaan. 3. FUNCTIONELE ACCEPTATIETEST In het algemeen wordt de functionele acceptatietest uitgevoerd door functioneel specialisten. De omgeving waarin de test wordt uitgevoerd lijkt zoveel als mogelijk op de uiteindelijke productiesituatie. Er dient een testplan te zijn opgesteld waarin de planning, de te testen onderdelen en een beschrijving van de testscripts en testdata zijn opgenomen. Input voor dit testplan komt uit de taakgebieden Requirements management en Ontwerp. Daarnaast dienen de acceptatiecriteria uit het taakgebied Kwaliteitsmanagement ter beschikking te staan. De functionele acceptatietest moet aantonen dat de uitgevoerde wijzigingen aan de functionele eisen voldoen. Er wordt dus getest ten opzichte van de gedefinieerde en gespecifieerde eisen in Requirements management en Ontwerp. De volgende testvormen komen in de functionele acceptatietest voor: 1. Functionaliteit Een allereerst uit te voeren test is of de functionaliteit overeenstemt met het ontwerp. Specifiek kan hier nog worden gekeken naar een ordentelijke foutafhandeling. 2. Regressietest Bij een regressietest wordt met name aandacht besteed aan de niet gewijzigde onderdelen. Het is een berucht fenomeen bij testen; de wijzigingen zijn in orde, maar uiteindelijk blijkt in productie een niet-gewijzigd onderdeel niet meer te functioneren. Veelal wordt dit veroorzaakt doordat de samenhang van systemen onvoldoende bekend is en daardoor de scope van de te V1.0 Pagina 5
testen onderdelen te nauw wordt genomen. Ook kan nog meespelen dat de aandacht bij de testers wat is verslapt omdat er via deze test betrekkelijk weinig fouten worden gevonden, en het dus minder relevant lijkt te zijn. Tot slot kan ook de motivatie van de testers ook wat lager zijn omdat bijv. basisonderdelen veelvuldig moeten worden getest die maar weinig interessant / uitdagend zijn. 3. Integratie / ketentest Bij een ketentest wordt het systeem in samenhang met andere systemen (de keten ) getest. Daarbij kan het zowel in- als externe andere systemen betreffen. Het opzetten van deze test kan lastig zijn omdat het behoorlijke eisen stelt aan de testomgeving. Bij koppelingen met systemen van externe partijen moet idealiter de totale testomgeving zich ook tot die externe partijen uitstrekken. In het geval een dergelijke testomgeving niet is op te tuigen kunnen de interfaces met bepaalde systemen ook worden gesimuleerd. Simulatie blijft echter feitelijk een suboptimale oplossing omdat de testomgeving als uitgangspunt moet hebben dat deze zoveel mogelijk op de werkelijke productieomgeving moet lijken. Bijzonder aandachtspunten bij de integratie / ketentest zijn de controle op input, output en beveiliging van het systeem en de gegevensstromen; komen geen gegevens op de verkeerde plaats terecht, staan de gegevens juist en tijdig als input ter beschikking, of andersom, worden ze tijdig ter beschikking aan een ander systeem gesteld? Daarnaast kan er ook sprake zijn van functionele integratie, waarbij een bepaalde functionaliteit technisch in samenstelsel van meerdere systemen wordt gerealiseerd. Indien in een deelfunctionaliteit van een van de systemen dan een wijziging plaatsvind, moet vervolgens de gehele functionaliteit worden getest. Een systeemdoorlooptest, waarbij zoals de naam al aangeeft het hele systeem wordt doorlopen, kan hier grote diensten bewijzen. 4. Beschikbaarheidstest Bij een beschikbaarheidstest wordt getest of een systeem langdurig goed blijft werken. Het doet denken aan de duurtests die ook wel worden uitgevoerd op fysieke producten om te zien of materialen langdurig tegen een bepaalde belasting bestand zijn. 5. Conversietest Indien van toepassing kan worden getest of de conversie goed verloopt. Een conversie kan zowel betrekking hebben op het converteren van gegevens in hetzelfde systeem, als het overzetten van gegevens van een oud naar een nieuw systeem. 6. Documentatie Bij deze test wordt specifiek gekeken naar de wijzigingen in de documentatie die voor het gebruik van het systeem bedoeld is. Is de documentatie correct, volledig, begrijpelijk? 7. Limiettest In de limiettest wordt gekeken naar kritische parameters en andere limieten waarbinnen het systeem moet functioneren. Ook het testen van het gedrag van het systeem zodra de limieten worden overschreden wordt in de limiettest meegenomen. Doorgaans moeten hier specifieke testgevallen voor worden gemaakt, omdat als het goed is in de productiedatabase geen gevallen aanwezig zijn die buiten de systeemlimieten vallen. Er kan in dit geval dus niet worden teruggevallen op testgevallen die uit productie zijn overgenomen. V1.0 Pagina 6
8. Muli-user Een test of het systeem toegankelijk is voor meerdere personen tegelijkertijd zonder dat daardoor problemen ontstaan, zoals bijvoorbeeld locking. Niet elke testvorm hoeft elke keer even relevant te zijn. Het is dus mogelijk sommige testvormen te combineren bij een relatief beperkte test, of testvormen geheel weg te laten. Uiteraard, maar dat is wel een open deur, moeten testvormen alleen worden weggelaten in de testfase omdat ze niet nodig zijn, en niet uit tijdgebrek. 4. GEBRUIKERSACCEPTATIETEST In het algemeen wordt de gebruikersacceptatietest uitgevoerd door gebruikers en key-users, met ondersteuning van functioneel specialisten. De omgeving waarin de test wordt uitgevoerd lijkt net zoals bij de functionele acceptatietest zoveel als mogelijk op de uiteindelijke productiesituatie. Eveneens dient, precies zoals ook bij de functionele acceptatietest beschreven, een testplan te zijn opgesteld, waarin de planning, de te testen onderdelen en een beschrijving van de testscripts en testdata zijn opgenomen. Daarnaast dienen ook hier de acceptatiecriteria ter beschikking te staan. De gebruikersacceptatietest moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen van de gebruikers voldoen. Er wordt dus getest ten opzichte van oorspronkelijke behoeften van de gebruikers. Deze behoeften zijn in Requirements management zo goed mogelijk gespecificeerd en daarna ook nog eens gevalideerd. Toch kan ook daar, in die fase, al veel zijn misgelopen. Het probleem van het testen ten opzichte van de oorspronkelijke behoeften is in de praktijk vaak dat die behoeften wat vaag zijn, en niet meetbaar en controleerbaar zijn beschreven. Een voorbeeld ter illustratie: Een manager wil de efficiency van een afdeling graag verhogen. Op de afdeling worden diverse administraties gevoerd, maar er is ook een klein onderdeel advisering. De gedachte is dat door meer inzet van computertechnologie in het onderdeel administratievoering, daar FTE s worden bespaard die in het groeiende onderdeel advisering kunnen worden ingezet. Met als gevolg: met dezelfde personele bezetting kan een hogere output worden bereikt. De administratieve processen worden grondig bekeken en al snel worden diverse oplossingen gedefinieerd waarmee naar verwachting arbeidstijd kan worden bespaard. Te denken is bijv. aan het wegwerken van de laatste papieren formulieren, het beter koppelen van diverse systemen, het verbeteren van user interfaces die veel worden gebruikt en ook sommige handmatige controles kunnen worden geautomatiseerd. Een en ander wordt helder uitgewerkt in requirements en ontwerpdocumenten en ook zonder al te veel problemen gerealiseerd. Tijdens de functionele acceptatietest blijkt ook inderdaad dat alle onderdelen precies conform de functionele eisen zijn aangepast; de koppelingen functioneren, alle formulieren zijn gedigitaliseerd, user interfaces zijn sterk verbeterd en precies op de aangegeven plaatsen zijn handmatige handelingen verdwenen. Helaas blijkt bij het checken op de benodigde doorloop- en werktijd voor een gehele administratieve transactie, dat de gewenste tijdsbesparing (nog) niet wordt behaald. Met andere woorden: het wijzigingstraject op zichzelf loopt helemaal niet slecht, en zouden de wijzigingen op deze manier in V1.0 Pagina 7
productie genomen dan zal er naar verwachting technisch en functioneel niet al te veel fout gaan. Maar het achterliggende doel: arbeidstijd besparen in de administratieve processen, wordt helaas niet behaald. De testvormen die in de functionele acceptatietest zijn beschreven en ook bij de gebruikersacceptatietest voorkomen zijn: 1. Functionaliteit 2. Beschikbaarheid 3. Conversietest 4. Documentatie 5. Keten- cq integratietest 6. Regressietest De testvormen specifiek voor de gebruikersacceptatietest zijn: 1. Usability test Bij de usability test wordt het werkelijke gebruik van het systeem getest door een groep gebruikers. Onder andere kan dan worden gekeken naar de gebruikersvriendelijkheid: schermopbouw, begrijpelijkheid, ondersteuning door aanvullende teksten, etc. Het kan bijvoorbeeld worden uitgevoerd door gebruikers een bepaalde uit te voeren taak te geven en de gebruikers te verzoeken hardop al hun gedachten uit te spreken bij elke handeling die zij doen. Ook wordt wel gebruik gemaakt van eye tracking software, waarbij wordt gevolgd waar iemand precies naar kijkt op het scherm. Ook is het mogelijk de tijd op te nemen, zodat duidelijk wordt waar haperingen optreden en dus kennelijke onduidelijkheden zijn. In het geval een gebruikersgroep niet direct beschikbaar is (bijvoorbeeld bij een website) kan voor remote usability testing worden gekozen, waarbij op afstand gebruikers wordt gevraagd deel te nemen. Ook A/B testen komt dan in beeld, waarbij twee verschillende versies naast elkaar worden getest om te bepalen welke user interface de beste resultaten geeft. 2. Load- / stresstest Bij een load / stresstest wordt het systeem getest of het bestand is tegen grote aantallen medewerkers, gegevens en / of transacties. Natuurlijk moet hier een maximum zijn gedefinieerd en tot het maximum moet het systeem conform verwachting functioneren. Daarboven moet het gecontroleerd stoppen of anderszins reageren (zoals bijv. bij een website, die bij overschrijding van max. aantal bezoekers niet onderuit gaat maar de bezoekers boven de limiet een boodschap voorschotelt). Probleem bij deze test is doorgaans dat deze in een gebruikersacceptatietest omgeving moeilijk is uit te voeren: het benodigde aantal gebruikers is niet voorhanden, en grote aantallen transacties zijn ook moeilijk te forceren. Daarom wordt deze test in de praktijk ook wel door infra en applicatie support en / of leverancier uitgevoerd, waarna de daar genoteerde resultaten tijdens de gebruikersacceptatietest worden gecontroleerd. 3. Scenario testen Hierbij wordt via scenario s het bedrijfsproces gesimuleerd. Aldus is te constateren of niet alleen het gewijzigde systeem, maar ook het bedrijfsproces conform verwachting functioneert. V1.0 Pagina 8
Bij gebruikersacceptatietesten zijn de volgende praktijkopmerkingen te maken: Bij een gebruikersacceptatietest moeten eindgebruikers worden betrokken. Dat lijkt een voor de hand liggende zaak, maar is in de praktijk niet altijd eenvoudig uitvoerbaar. De juiste gebruikers moeten worden betrokken, die dan ook voldoende tijd ter beschikking hebben. Met juist wordt bedoeld dat niet alleen de beste gebruikers uit een gebruikersgroep worden betrokken, maar juist ook gebruikers met een lager kennisniveau en minder computervaardigheden. Dat maakt een test weliswaar lastiger, maar de zekerheid dat het systeem ook in productie zal doen wat het moet doen en zal worden gebruikt zoals het moet worden gebruikt, neemt vanzelfsprekend fors toe. De faciliteiten waarmee gebruikers moeten testen moeten in orde zijn. Niets is zo vervelend en frustrerend als gebrekkige faciliteiten, of omgevingen die afwijken van de uiteindelijke productiesituatie. De verwarring die dat schept kan een test volledig frustreren en de aandacht ook wegzuigen van waar de test eigenlijk werkelijk om draait. De ondersteuning vanuit functioneel specialisten is zonder meer nodig. Het betekent echter niet dat functioneel specialisten de test overnemen! Maar bij problemen met de omgeving waarin wordt getest kan een functioneel specialist doorgaans makkelijker ingrijpen en samen met infra en applicatie support en leverancier een en ander oplossen. Ook bij constatering van fouten kan een Functioneel specialist (beheerder) een oogje in het zeil houden: zijn het echte fouten, of worden zij bijvoorbeeld veroorzaakt door een (oude) werkwijze die niet meer van toepassing is? Voorkom te weinig èn teveel fouten. Het is een lovenswaardig streven om ervoor te zorgen dat tijdens een gebruikersacceptatietest niet te weinig, maar ook niet teveel fouten worden gevonden. Indien elke keer al tijdens eerdere tests zo grondig is getest, dat tijdens de gebruikersacceptatietesten vrijwel niets meer wordt gevonden, zal de gebruikersgroep in reactie daarop steeds minder gaan testen vanwege de zinloosheid ervan. Aan de andere kant, als het aantal fouten bij de gebruikers tijdens het testen erg hoog is, is er het risico van het ontstaan van een negatieve sfeer. Het idee kan ontstaan dat het niets is en ook niet kan worden. Omdat de gebruikers die testen ook gewoon op de werkvloer werken kan dat ook daar al snel gaan rondzingen. Al met al moet dus, hoe gek het ook klinkt, het aantal fouten tijdens de gebruikersacceptatietest worden gedoceerd. Al lijkt het erop dat het aantal fouten toch geheel en al uit de hand loopt, kan desnoods de gebruikersacceptatietest worden afgebroken. Vervolgens worden eerst voorgaande tests beter uitgevoerd en fouten opgelost V1.0 Pagina 9
waarna de gebruikersacceptatietest kan worden herstart. 5. PRODUCTIEACCEPTATIETEST De productieacceptatietest is een door (een vertegenwoordiging van) de toekomstige beheerders uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen vanuit beheer voldoen. De nadruk bij een productieacceptatietest ligt in het algemeen sterk aan de technische kant. Toch dient er vanuit de positie van de functioneel specialisten op twee manieren aandacht binnen deze test te zijn. Ten eerste dienen ook functioneel specialisten hier zichzelf af te vragen, en dus ook te testen, of het systeem functioneel wel te beheren is. Bijvoorbeeld het ontbreken van bijgewerkte handleidingen, rammelende workflows of niet bijgewerkte helpteksten zijn wellicht voor gebruikers nog wel overkomelijk, dat moeten zij in de gebruikersacceptatietest natuurlijk zelf beoordelen. Maar Functioneel specialisten moeten daar vanuit de optiek van het leveren van ondersteuning ook een oordeel over vellen. Bovendien houden functioneel specialisten intern vaak ook documenten en tools bij die gebruikt worden ter ondersteuning. Zijn deze inderdaad ook bijgewerkt en kunnen die ook worden ingezet nadat bij gebruikers het gewijzigde systeem in productie is gekomen? Ten tweede kunnen aan de technische zijde tijdens de productieacceptatietest bevindingen worden gedaan, en daaropvolgend beslissingen worden genomen, die functionele impact hebben. In dit soort situaties is op zijn minst overleg tussen infra, applicatief en functioneel support nodig en moet er gezamenlijk naar de bevindingen worden gekeken. Hoewel technische perikelen roet in het eten kunnen gooien en deze testfase al vlak voor de inproductiename ligt met alle tijdsdruk van dien, moeten ook nu de belangen van de gebruikers blijven prevaleren. De testvormen specifiek voor de productiesacceptatietest zijn: 1. Back-up & restore test Het testen of de back-up en restore nog goed functioneert. De test wordt uitgevoerd door infra support, maar door functioneel specialisten wordt een controle uitgeoefend 2. Herstartbaarheid Is het systeem herstartbaar na (onverwachte) uitval? Uit te voeren door infra support, functioneel is er aandacht voor inconsistentie in gegevens, gegevensverlies en goede foutafhandeling 3. Installatie / de-installatietest Hierbij wordt functioneel gekeken naar de volledigheid en juistheid van de installatie (is niets vergeten, komen alle updates bij precies de juiste gebruikersgroep terecht?) en de-installatie (komt het oude systeem precies zoals het was weer in de lucht? Kunnen we met het oude systeem doorwerken?) V1.0 Pagina 10
4. Load- / stresstest Zie voor toelichting de hiervoor beschreven gebruikersacceptatietest. 5. Performance Voldoet het systeem aan de performance eisen. 6. Uitwijktest Functioneert uitwijk nog conform de afspraken? Ook hier is vooral aandacht voor de functionele aspecten: komt het gewijzigde systeem in geval van uitwijk binnen de gestelde tijd weer beschikbaar, zijn er geen negatieve gevolgen voor andere systemen, is het inderdaad mogelijk in uitwijksituatie met het systeem te werken, is inwijk (terugkeren naar de gewone werksituatie) nog steeds mogelijk? Sommige testvormen komen hier voor terwijl ze ook al bij eerdere testsoorten zijn genoemd. In de PAT ligt de focus vanzelfsprekend anders dan in de FAT of de GAT. 6. OPSTELLEN VRIJGAVE ADVIES / VERBETERPUNTEN Nadat alle tests zijn afgerond wordt een vrijgave advies opgesteld. Het betekent niet dat op dat moment alle geconstateerde bevindingen moeten zijn opgelost. Er kan voor worden gekozen om ondanks het feit dat er nog openstaande bevindingen zijn toch te adviseren de wijzigingen in productie te nemen. In het advies worden de eventueel nog openstaande bevindingen vermeld inclusief de consequenties daarvan voor de productieomgeving. Tevens kunnen in het vrijgave advies afspraken over later op te lossen bevindingen worden vermeld. Tevens kunnen op dit moment de verbeterpunten die in het hele toets- en testtraject zijn geconstateerd bij elkaar worden gebracht en gedocumenteerd voor later gebruik. Ook indien het toetsen testtraject op zichzelf naar volle tevredenheid is verlopen kunnen er vanzelfsprekend nog steeds verbeterpunten zijn. Toch is een waarschuwing wel op zijn plaats: er moet hier niet worden gestreefd naar het perfecte, maar naar het optimale. En die zijn veelal niet gelijk aan elkaar. OPMERKINGEN De volgende opmerkingen zijn te maken over dit taakgebied: 1. TESTSOORTEN EN -VORMEN In de wereld van het testen worden veel termen door elkaar gebruikt. Hieronder worden de testsoorten en -vormen die in TMap worden beschreven opgesomd. De testvormen kunnen binnen de verschillende testsoorten worden gebruikt om deze in te vullen. Doorgaans is een bepaalde testvorm daarom binnen meerdere testsoorten terug te vinden. De testsoorten: - Unittest (UT): Test door ontwikkelaar in ontwikkelomgeving, check op technisch goed functioneren van een unit (individuele wijziging) V1.0 Pagina 11
- Unitintegratietest (UIT): Test door ontwikkelaar in ontwikkelomgeving, check op technisch goed functioneren van een logische groep units (aantal wijzigingen, bijv. in een release) - Systeemtest (ST): Test door leverancier in laboratoriumomgeving uitgevoerde test van het systeem t.o.v. de niet-functionele en functionele specificaties en het technisch ontwerp - Systeemintegratietest (SIT): Een door de toekomstige gebruiker uitgevoerde test op de systeeminterfaces in een zoveel mogelijk op productie gelijkende omgeving - Functionele acceptatietest (FAT): Een door functioneel specialisten uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de functionele eisen voldoen - Gebruikersacceptatietest (GAT): Een door (een vertegenwoordiging van) de toekomstige gebruikers uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen van de gebruikers voldoen - Productieacceptatietest (PAT): Een door (een vertegenwoordiging van) de toekomstige beheerders uitgevoerde test in een zoveel als mogelijk op de productieomgeving gelijkende omgeving. Deze test moet aantonen dat de uitgevoerde wijzigingen aan de wensen / eisen vanuit beheer voldoen. Beheer kan hierbij zowel de technische als functionele kant betreffen, hoewel de nadruk vaak sterk op de technische kant ligt. Een aantal testvormen (niet volledig, de meest voorkomende): - Back-up & restore test: Testen of back-up proces correct functioneert - Beschikbaarheid: Blijft het systeem langdurig correct werken? - Conversietest: Test op conversie van met name gegevens - Documentatie: Controle op volledigheid, juistheid, begrijpelijkheid - Functionaliteit: Is de functionaliteit overeenkomstig het ontwerp? - Hackerstest / penetratietest: Test op mogelijkheid om van buitenaf het systeem oneigenlijk te gebruiken - Herstartbaarheid: Is het systeem bij onverwacht afbreken conform afspraken herstartbaar? - Installatie / de-installatietest: Test of de installatie en de-installatie van de wijzigingen werkt conform afspraken - Interface / ketentest: Tests rondom aansluiting van systeem op andere systemen (technisch en functioneel) - Limiettest: Test op gedefinieerde limieten (functioneel, dus bijv. max. salaris) - Load- / stresstest: Test op verwerken van grote hoeveelheden gegevens / transacties / gebruikers / klanten / bezoekers - Middelengebruik: Test op gebruik van resources - Monkeytest: Test op bestandheid tegen onverwachte handelingen (foolproof) - Mulit-user: kunnen meerdere / het afgesproken aantal gebruikers van het systeem gebruik maken - Performance: Voldoet het systeem aan de performance eisen? - Regressie: Testen op het functioneren van alle onderdelen, met name ook de niet-gewijzigde onderdelen - Rollback: Test of een rollback werkt conform afspraken - Scenario testen: Testen via scenario s, waarbij bedrijfsprocessen worden gesimuleerd - Uitwijktest: Test of uitwijk conform afspraken functioneert V1.0 Pagina 12
- Usability: Test op gebruikersvriendelijkheid, juistheid functioneren user inferface, opbouw user interface conform afspraken 2. TESTEN MET PRODUCTIEDATA Een onderwerp dat al lang veel discussie oproept is of het aan te bevelen, of juist af te raden, is om te testen met productiegegevens. Hierbij wordt de gehele productiedatabase overgezet naar een acceptatietestomgeving, waarna een test plaatsvindt. De voordelen zijn onder andere dat het op deze wijze natuurlijk geen tijd kost om een bestand met testgevallen op te bouwen en bij testen de werkelijke productiesituatie heel goed wordt nagebootst. Toch zijn er ook aanmerkelijke nadelen. Een productiedatabase kan heel groot zijn, waardoor de acceptatietestomgeving ook heel groot wordt en daarmee onhandelbaarder wordt. Een meer principieel punt is in sommige organisaties wel dat productiedata vaak netjes is beschermd tegen verkeerde/verkeerde ogen. In testomgevingen zijn dergelijke waarborgen er vaak niet. Hierdoor kan het zomaar gebeuren dat via deze achterdeur productiegegevens toch beschikbaar komen op plaatsen en bij personen die daar geen toegang toe zouden mogen hebben. Nu is het mogelijk productiegegevens te scrambelen, maar dat heeft weer als nadeel dat bepaalde functionele tests niet meer kunnen worden uitgevoerd. Bijvoorbeeld, indien alle namen zijn gescrambeld, wordt het onmogelijk om een functionaliteit als zoek verwanten op naam nog te gebruiken. Tot slot is ook vanuit functioneel oogpunt een belangrijk punt dat niet alle te testen gevallen ook werkelijk in de productiedatabase hoeven voor te komen. Stel dat er bijv. in de loonadministratie een controle zit op overschrijding max. loon, hoe groot is dan de kans dat in de productiedatabase een persoon is opgenomen die precies op dat maximum zit? Of, als die controle getest moet worden, een persoon met een te hoog salaris in de productiedatabase aanwezig is? Als het goed is, zitten dergelijke gevallen niet in productie. Maar om de controle te testen zou een dergelijk geval wel in een testset moeten zijn opgenomen. Bij elkaar kan het zeker zinvol zijn ook met productiedata te testen. Dan kan nog worden gekozen voor het testen met de volledige productieset, of met een extract daarvan (bijv. 1 op de 100 random selecteren en overzetten naar een testomgeving). Maar het is zeker niet de enige test die zou moeten worden uitgevoerd, het samenstellen van één of meerdere testsets met eigen specifieke testgevallen blijft dus noodzaak. 3. TESTEN IN PRODUCTIE Een absolute no go voor veel bedrijven is testen in productie. Toch is dat principe altijd haalbaar? Er zijn genoeg situaties te bedenken waarin geen representatieve testomgeving is op te bouwen. Denk alleen al aan een productielijn voor veevoer, bier of auto s. Het is volstrekt ondenkbaar een dergelijk productieproces ook in een testomgeving geheel op te bouwen. Weliswaar is een simulatie uit te voeren, maar uiteindelijk zal pas in productie blijken of een en ander geheel juist is. Juist functioneel is het dan noodzaak op een of andere manier de gevolgen van eventuele productiefouten te beperken. Ook kunnen middels pre-productie runs eventuele fouten nog worden opgespoord. In productiebedrijven is het niet vreemd om voordat een productielijn volledig productie gaat draaien een periode te hebben om alles in te laten lopen. V1.0 Pagina 13
4. TESTEN IN PRODUCTIE LOOK-A-LIKE OMGEVINGEN In de functionele acceptatietest en gebruikersacceptatietest is het de bedoeling in een omgeving te testen die zoveel mogelijk gelijk is aan de uiteindelijke productieomgeving. Het brengt het gevaar met zich mee dat Functioneel specialisten/ specialisten en de gebruikers die de tests uitvoeren geheel en al in de war raken. Dat wordt mede veroorzaakt doordat deze mensen geneigd zijn om het gewijzigde systeem in de testomgeving te vergelijken met de werkelijke, huidige productiesituatie. Door maar genoeg schermen open te hebben staan kan uiteindelijk test worden aangezien voor productie en andersom. Op een of andere manier moet dus altijd duidelijk blijven welke omgeving de testomgeving is. Dat kan door het fysiek te maken: bepaalde apparaten / ruimtes geven altijd toegang tot uitsluitend de testomgeving. Of het systeem is zo gemaakt dat met behulp van een indicator op elk scherm is te zien of het een test- dan wel productieomgeving betreft. Een aardige anekdote hierover tot slot: Een fabriek maakt apparaten die tot wel enige miljoenen euro s per stuk kunnen kosten. Bij een aanpassing van het ordersysteem wordt in de acceptatietestomgeving een nieuwe order ingevoerd en goedgekeurd. Vanwege allerlei koppelingen en dashboards gaat al snel bij de directie de champagne open: dergelijke orders komen tenslotte niet elke dag voor. Pas na enige tijd wordt duidelijk dat het helaas geen echte order betreft V1.0 Pagina 14