Uittreksel. Ten geleide

Uittreksel Titel: Testen volgens TMap

Onderwerp: Test Management Approach

Ten geleide TMap®, Test Management Approach, is een aanpak voor het gestructureerd testen van informatiesystemen. Het geeft antwoord op de w at/w anneer, hoe, w aarmee en w ie vragen van het testen. Om de inrichting en uitvoering van testprocessen gestructureerd te laten verlopen, is TMap gebaseerd op vier, aan deze vragen gerelateerde, pijlers. 1. De wat/wanneer vragen worden beantwoord door het faseringsmodel , een aan de ontwikkelingscyclus gerelateerde beschrijving van de testcyclus. 2. Het hoe is verwoord in de beschrijving van de technieken voor het plannen, voorbereiden en uitvoeren van de diverse tests. 3. Op het waarmee wordt ingegaan bij de beschrijving van de infrastructuur en de tools. 4. De beschrijving van de organisatie~aspecten geeft antwoord op de wie vraag. TMap is een generiek model. De theorie is universeel beschreven omdat dé testaanpak nu eenmaal niet bestaat. Testen komt voor in diverse variaties die elk hun eigen toepassing van de standaard vragen. In het boek wordt daarom ruim aandacht besteed aan de wijze waarop de juiste componenten van TMAp, voor welk testproces dan ook, geselecteerd kunnen worden. Het boek is opgebouwd uit vijf delen. Deel 1 beschrijft het fenomeen testen en TMap in het algemeen, terwijl de delen 2, 3, 4 en 5 de respectievelijke pijlers van TMap beschrijven: fasering, technieken, organisatie en infrastructuur. Deel I beschrijft het belang en context van het testen in de informatievoorziening en binnen de kwaliteitszorg in het bijzonder. Het waarom van het testen en de mogelijkheden van een gestructureerde toepassing komen uitvoerig aan de orde. Ter oriëntatie is een hoofdstuk opgenomen waarin de theorie in een notedop is beschreven. In ‘Variaties op het thema’ zijn enkele belangrijke toepassingsgebieden belicht, zoals het tes ten van pakketten, het testen in onderhoudssituaties en het testen in client/server omgevingen. Deel II bevat het faseringsmodel voor de testprocessen. De testactiviteiten worden systematisch beschreven voor zowel de white-box als de black-box tests. De fasering vormt de rode draad van TMap. Vanuit de fasering wordt de relatie gelegd tussen de componenten van de overige pijlers: technieken, organisatie en infrastructuur. In deel III worden de voor het testen beschikbare technieken in detail beschreven. Naast de primaire testspecificatietechnieken voorziet het TMap instrumentarium onder andere in technieken voor het bepalen van de teststrategie en de testbegroting. Dit deel bevat tevens een uitgebreide verzameling checklists. In deel IV komt de organisatie van het testen aan de orde. Hierin worden de testfuncties met de vereiste kennis en vaardigheden, de organisatiestructuur en het aspect testbeheer beschreven. Aan de selectie en de opleiding van testpersoneel is in een apart hoofdstuk aandacht besteed. In het hoofdstuk ‘Structurering’ wordt ingegaan op de implementatie van het gestructureerd testen binnen een organisatie. Hiertoe is een speciaal voor dit doel ontwikkelde leidraad opgenomen. Deel V gaat in op de voor het testen benodigde infrastructuur. Respectievelijk zijn richtlijnen opgenomen voor de testomgeving, de testtools en de kantoor inrichting.

Aangemaakt d.d.

27-12-2011

Pagina 2



Deel I: Algemeen 1. Inleiding Testen is volgens het woordenb oek: “aan een test onderwerpen, b eproeven, toetsen”. Over testen b estaat in de informatica industrie zo langzamerhand een b eeld, maar nog lang geen sluitende definitie waarvan een ieder zich b edient. De vele soorten tests met uiteenlopende doelen, de vage b egrenzingen en de veelal nog informele toepassing van het fenomeen maken het opstellen van een eenduidige b egripsb epaling lastig.

1.1 Wat is testen? Testen is in ieder geval vergelijken. Het vraagt om een te testen object en een referentiekader waaraan dat object moet voldoen.

Definitie van Testen volgens ISO “Activiteiten zoals meten, onderzoeken, beproeven, keuren met kalibers van één of meer kenmerken van een produkt of dienst en het vergelijken van uitkomsten met gestelde eisen om te bepalen of aan deze voorwaarde is voldaan.” Testen geeft inzicht in het verschil tussen de actuele en de vereiste status van een object. Testen behoort tot de detectieve middelen van een kwaliteitssysteem. De diverse detectie-instrumenten worden verdeeld in twee groepen: • toetsen : het inspecteren van tussenprodukten en ontwikkelingsprocessen, ofwel verificatie (wordt er goed gebouwd?) • testen : het inspecteren van de eindprodukten, ofwel de validatie (wordt het goede produkt gebouwd?)

Definitie van Testen Testen is een proces van plannen, voorbereiden en meten, dat tot doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen de actuele en de vereiste status aan te tonen.

1.2 Waarom testen? ISO formuleert: Is vastgesteld of het produkt de eigenschappen en kenmerken bezit om te voldoen aan de vastgestelde of, en dat is nog lastiger; vanzelfsprekende b ehoeften? Eigenlijk luidt de vraag: Welke risico’s worden gelopen, en welke maatregelen zijn eventueel te nemen ter reductie van die risico’s? Om niet pas tijdens de exploitatiefase antwoord op dit soort cruciale vragen te krijgen, is een goed gestructureerd en betrouwbaar testproces vereist. Dat vraagt om een gestructureerde testaanpak en dito organisatie en infrastructuur.

1.3 Waar staat het testen? In de meeste organisaties is het testen onderontwikkeld en bevindt het zich nog vaak in een experimenteel stadium. Men heeft veelal de neiging om de invoering van een gedegen kwaliteitssysteem, waarvan het testen een belangrijk onderdeel vormt, voor zich uit te schuiven. Het ontbreekt meestal aan de vereiste organisatorische basis die waarborgen biedt om kwalitatief te kunnen ontwikkelen en testen. Daar waar men het fenomeen kwaliteit wel serieus neemt, wordt het testen pas als laatste gestructureerd. Overigens blijkt dat in rijpere industrieën, zoals bijvoorbeeld de luchtvaart en hardware industrie, het testen zich ontwikkeld heeft tot een volwaardig (en substantieel) onderdeel van het kwaliteitssysteem.

Aangemaakt d.d.

27-12-2011

Pagina 3



2. Kader en belang U wilt gaan testen. In wezen echter wilt u niet testen, maar u wilt de risico’s b eheersen die verb onden zijn aan het invoeren van een nieuw informatiesysteem. Dit b oek gaat daarom eigenlijk niet over testen, maar over risicob eheersing. Testen is daarb ij slechts een middel. Misschien een paardemiddel, maar voorlopig wel een noodzakelijk middel ...

2.1 Doel van het testen Het ontwikkelen en onderhouden van informatiesystemen vereist bijzondere aandacht voor de kwaliteit ervan, dat wil zeggen het voldoen aan de verwachtingen van de diverse gebruikers. Op basis van het bovenstaande ligt het voor de hand te concluderen dat het blootleggen van kwaliteitsgebrek teneinde die op te kunnen (laten) heffen, de belangrijkste doelstelling van het testen is: “Testen doe je om de fouten eruit te halen”. Hoewel het niet te ontkennen valt dat door middel van testen de kwaliteit verbeterd kan worden, is testen toch niet het geschikte middel om dat te bereiken. Met behulp van testen worden uitsluitend symptomen waargenomen. Het gevaar is daardoor groot dat testen enkel tot symptoombestrijding leidt. Testen zou aanleiding moeten zijn om diagnoses te stellen: het zoeken van de oorzaken achter de problemen. Kwaliteit moet er in worden geb ouwd, niet getest! De waargenomen symptomen stellen de organisatie in staat om een diagnose te stellen en de problemen op te lossen. Maar, minstens even belangrijk, die waargenomen symptomen bieden ook de gelegenheid een uitspraak te doen over de risico’s die gelopen worden als een bepaalde versie van een systeem in gebruik genomen wordt. Op basis van de waarnemingen gedurende het testen kan door middel van ‘extrapolatie’ een voorspelling worden gedaan over het systeemgedrag in produktie.

2.2 Wat is testen niet? Testen is niet: 1. alleen meten, maar ook plannen en voorbereiden: Het testen behelst maar 40%, plannen en voorbereiden, vragen 60% van de testinspanning. 2. het vrijgeven of accepteren: Het testen levert advies over de kwaliteit, de beslissing over vrijgave is aan anderen. 3. foutherstel: Slechts bij de programmatest is het mogelijk het testen en herstellen in één hand te leggen. Bij alle andere tests moet het principe gehanteerd worden, dat er niet getest wordt door de persoon die heeft gebouwd en niet hersteld wordt door de persoon die heeft getest. 4. een fase ná ontwikkeling: Parallel aan het opstellen van de functionele specificaties, moet een testplan worden opgesteld. Direct na het vaststellen van de functionele specificaties wordt dan gestart met de voorbereiding van de tests. 5. het implementeren van een informatiesysteem: In principe zijn testen en implementeren tegengestelde, sterk gerelateerde activiteiten, die organisatorisch goed belegd dienen te worden. 6. bedoeld om het systeem te toetsen op volledigheid en juistheid van de functionaliteit; 7. goedkoop: De testkosten schommelen tussen de 20% en 50 % van de ontwikkelingskosten na de fase functionele specificatie. Daarentegen zal een goede, tijdig uitgevoerde test het ontwikkelingsproces positief beïnvloeden en kan een kwalitatief beter systeem opleveren. Het herstellen van fouten vergt meer inspanning, tijd en geld naarmate het moment van detectie verder afligt van het moment van ontstaan. 8. het opleiden voor gebruik en beheer: Hoewel het de voorkeur geniet het testen en het opleiden te scheiden, is de combinatie onder voorwaarden mogelijk. Goede afspraken moeten voorkomen dat zowel de test als de opleiding van onvoldoende kwaliteit zullen zijn. 9. populair.

2.3 Kwaliteitszorg en Testen Definitie van “Kwaliteit” volgens ISO: Het geheel van eigenschappen en kenmerken van een produkt of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoeften.

Aangemaakt d.d.

27-12-2011

Pagina 4



Wat voor de één vanzelfsprekend is, is dat voor de ander absoluut niet. Vanzelfsprekendheid is bij uitstek een subjectief begrip. Een belangrijk aspect van kwaliteitszorg is daarom het minimaliseren van de vanzelfsprekende behoeften, door deze om te zetten in vastgestelde behoeften en het zichtbaar maken in welke mate aan de vastgestelde behoeften wordt voldaan. Daartoe moeten maatregelen worden getroffen om de eisen vast te stellen en het ontwikkelingsproces beheersbaar te maken.

Definitie van kwaliteitsborging, ‘quality assurance’: Het geheel van alle geplande en systematische acties nodig om in voldoende mate het vertrouwen te geven dat een produkt of dienst voldoet aan de gestelde kwaliteitseisen. Deze maatregelen moeten ertoe leiden dat: • er meetpunten en -grootheden zijn die een indicatie geven van de kwaliteit van de processen (normering). • het voor de individuele medewerker duidelijk is aan welke eisen zijn werk moet voldoen en dat hij aan de hand van bovengenoemde normen kan toetsen. • het voor een onafhankelijke partij mogelijk is de produkten/diensten aan de hand van bovengenoemde normen te toetsen. • het management bij gebleken gebreken in (deel)produkten of diensten kan traceren waardoor dat gebrek is ontstaan en hoe het in de toekomst kan worden voorkomen.. Deze maatregelen zijn te onderscheiden in: • preventieve maatregelen: voorkomen van diskwaliteit; • detectieve maatregelen: ontdekken van diskwaliteit; • correctieve maatregelen: opheffen van diskwaliteit. Het is van wezenlijke belang dat er samenhang bestaat tussen de verschillende maatregelen.

2.4 De kwaliteit van informatiesystemen Wat eigenlijk nodig is, is een aantal (onafhankelijk en meetbare) criteria die gezamenlijk het hele kwaliteitsspectrum van een informatiesysteem afdekken. Per criterium dient de Meeteenheid te worden bepaald. Vervolgens kunnen dan per criterium afspraken worden gemaakt omtrent de mate waarin dat aspect in het produkt aanwezig moet zijn: de normering. Dat is helaas nog niet gerealiseerd. Goede aanzetten zijn: Delen 1991, SERC 1993, NGGO 994. De produktkwaliteit wordt ontleed in twee dimensies: •

Statische dimensie: Beschrijft de beheereigenschappen van een informatiesysteem, ofwel de kwaliteit die wordt ervaren door het systeembeheerder- en onderhoudspersoneel. Het gaat vooral over de aanpasbaarheid van het systeem.

•

Dynamische dimensie: Beschrijft de gebruikseigenschappen van een informatiesysteem, ofwel de kwaliteit van de informatievoorziening in werking. Het gaat over het gebruik van het systeem.

3. Context van het testen 3.1 Dynamisch expliciet testen Het actuele resultaat wordt vergeleken met het verwachte resultaat om zo te bepalen of het systeem zich als vereist gedraagt. De bedoeling is om fouten te vinden.

3.2 Dynamisch impliciet testen Gelijktijdig met het expliciet testen kunnen gegevens over dat testproces worden verzameld. Uit deze gegevens kan informatie worden afgeleid over het wel en wee van het informatiesysteem. Zo kan een uitspraak over de bedrijfszekerheid van het systeem gebaseerd worden op het gedrag van het systeem gedurende de test testperiode: door bij te houden hoe vaak het systeem is geplaagd door storingen en met name trends daarin te zoeken, kan een schatting worden gedaan over de te verwachten storingen gedurende het gebruik.

Aangemaakt d.d.

27-12-2011

Pagina 5



3.3 Statisch testen Een informatiesysteem is meer dan een programma: het is het totaal van structuren en middelen die gebruikt worden om een organisatie van informatie te voorzien. Een aantal van deze aspecten kan niet door middel van dynamische testen gecontroleerd worden. Dit maakt het noodzakelijk andere vormen van testen aan te wenden. Zo’n andere vorm is het controleren en onderzoeken van produkten, zonder dat er sprake is van het uitvoeren van programma’s. Dit heet statisch testen.

3.4 Ontwikkel- en testproces Het ontwikkelen van informatiesystemen gebeurt in de meeste gevallen nog steeds volgens het gangbare faseringsmodel, de waterval-methode: 1. informatiebeleid, informatieplanning: Men begint bedrijfsbreed met het definiëren van de mogelijkheden die de informatietechnologie zoal biedt voor de oplossing van problemen of de optimalisatie van de bedrijfsprocessen en men kent daarin prioriteiten toe; 2. informatie-analyse, definitiestudie: Men stelt globaal vast aan welke eisen de functionaliteit moet gaan voldoen; 3. functioneel ontwerp: Men bepaalt vervolgens wat er aan functionaliteit gemaakt moet worden om die problemen op te lossen; 4. technisch ontwerp: Men gaat zich daarna druk maken over hoe dat dan moet worden opgelost; 5. Men maakt het systeem en gaat het vervolgens testen, invoeren en gebruiken. Een momenteel veel gehanteerde presentatie van het faseringsmodel voor systeemontwikkeling en het testen is het zogenaamde V-model (zie figuur 1). Figuur 1 V-model

3.5 Testsoorten Een testsoort is een groep van testactiviteiten die gezamenlijk worden georganiseerd en aangestuurd. Testsoorten kunnen in eerste instantie worden ingedeeld in de zogenaamde white-box en black-box tests.

White-box testsoorten Zijn gebaseerd op de coding, de programmabeschrijvingen of het technisch ontwerp. Er wordt nadrukkelijk gebruik gemaakt van kennis over de interne bouw van het systeem. Deze worden uitsluitend uitgevoerd door ontwikkelaars. Onderscheid wordt gemaakt tussen: • Programmatest: Een door de ontwikkelaar in de laboratoriumomgeving uitgevoerd test, die moet aantonen dat een programma aan de in de technische specificaties gestelde eisen voldoet. •

Integratietest: Een door de ontwikkelaar in de laboratoriumomgeving uitgevoerd test, die moet aantonen dat een logische serie programma’s aan de in de technische specificaties gestelde eisen voldoet. De nadruk ligt op gegevensdoorvoer en de interface werking.

Black-box testen Zijn gebaseerd op de functionele specificaties en de kwaliteitseisen. Het systeem wordt beschouwd in de verschijningsvorm zoals die ook gedurende het uiteindelijke gebruik zal zijn. Onderscheid wordt gemaakt tussen: •

Systeemtest: Een door de ontwikkelaar in een (goed beheersbare) laboratoriumomgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem of delen daarvan aan de in de functionele- en technische

Aangemaakt d.d.

27-12-2011

Pagina 6



specificaties gestelde eisen voldoen. •

Acceptatietest: Een door de gebruiker(s) en beheerder(s) in een zoveel mogelijk als-het-ware-produktie-omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem aan de functionele en kwalitatieve eisen voldoet. Deze test geeft antwoorden op de vragen als: • •

Welke risico’s worden gelopen bij in gebruikname? Heeft de leverancier aan zijn verplichtingen voldaan?

Acceptatie-test wordt opgedeeld in: •

Functionele acceptatietest: Is gericht op de functionele werking, wordt uitgevoerd door de gebruikers en functioneel beheerders en sluit nauw aan bij de systeemtest.

•

Produktie-acceptatietest: Is gericht op exploitatie-eisen, wordt uitgevoerd door technisch beheerders kort voor de in-produktname.

3.6 Testvormen Een testvorm is een groep activiteiten met het oogmerk het informatiesysteem op een aantal samenhangende kwaliteitsattributen te controleren. Bij de strategiebepaling wordt bepaald op welke manier, dus in welke vorm getest gaat worden. Indien nodig worden nieuwe testvormen bedacht. Op basis van de testvormen kunnen afspraken gemaakt worden over wie welke tests uitvoert. Testvorm Omschrijving Kw aliteitsattribuut o.a. Stress Het laten verwerken van grote hoeveelheden en Bedrijfszekerheid, continuïteit aantallen Middelen gebruik Het meten van de benodigde hoeveelheid middelen Zuinigheid (disk, geheugen, etc.) Herstel Het testen van de herstel en herstart faciliteiten Herstelbaarheid Produktie Het testen van de produktie procedures Juistheid, bedrijfszekerheid Standaards het testen van de standaards Beveiliging, bruikbaarheid Beveiliging Het testen van de beveiliging Beveiliging, geoorloofdheid Functionaliteit Het testen van de functionaliteit (inclusief Juistheid volledigheid foutafhandeling) Regressie Het testen dat alle onderdelen nog correct functioneren Alle na het doorvoeren van een wijziging Handmatige Het testen van de relatie tussen het geautomatiseerde Inpasbaarheid ondersteuning en het handmatige deel van het systeem Interfaces Het testen van aansluitingen met andere systemen Juistheid, volledigheid Controls Het testen van controles, zoals audit-trails, Controleerbaarheid, gegevensvalidaties, enzovoorts beveiliging, juistheid Referentie schaduw Het testen of twee versies van een applicatie een Juistheid, volledigheid draaien identieke interface hebben

4. Gestructureerd testen Uit diverse onderzoek naar het testproces in de afgelopen jaren is de onvolwassenheid van het testen bevestigd. Testen wordt meestal gezien als een noodzakelijk kwaad dat alleen maar geld en vooral veel tijd kost. Veel organisaties zijn, na de zoveelste structureringspoging, nog steeds zoekende. De meeste aanzetten tot het op een hoger plan brengen van het testen zijn gestrand op allerlei, meestal voorspelbare, oorzaken. Naast de toenemende functionele en technische complexiteit van de informatiesystemen en de steeds wijzigende ontwikkelmethoden, technieken en hulpmiddelen vinden deze oorzaken vooral hun oorsprong in de organisatie van het testen; enerzijds en de organisatie van het structureringsproces van het testen, anderzijds in de organisatie en de beheersing van het testproces zelf.

Aangemaakt d.d.

27-12-2011

Pagina 7



4.1 Ongestructureerd testen: de bevindingen Traditionele valkuilen, die de structurering van het testen met zich meebrengen: • Tijdsdruk: Een ongestructureerd testproces verliest het vrijwel altijd van tijdsdruk. •

Wachthouding: Te late start van de voorbereiding.

•

Fasering van de testactiviteiten: Het ontbreekt vaak aan een voorgeschreven aanpak waarin de testactiviteiten minimaal in fasen zijn onderverdeeld en beschreven.

•

Testtechnieken en tools: Hoewel dikwijls wel aanwezig, worden de testtechnieken en tools niet gebruikt.

•

Fixatie van de specificaties: In contracten voor de ontwikkeling of het onderhoud van informatiesystemen wordt het testen als bijzaak gezien en formele gronden voor oplevering en/of niet-acceptatie zijn in de meeste gevallen niet beschikbaar. De specificaties blijken in veel gevallen niet gefixeerd en beheerd te zijn.

•

Beheer: Een testproces strandt nogal eens door het ontbreken van de vereiste beheerfuncties, als configuratie- en wijzigingsbeheer.

•

Kwaliteit van de white-box tests laat in veel gevallen te wensen over.

•

Tegengestelde belangen: • Ontwikkelaars willen zoveel mogelijk tijd om het product te optimaliseren. • Het rekencentrum moet voordat het systeem in produktie gaat inzicht hebben in een groot aantal aspecten. • Testers/gebruikers/beheerders willen de tests conform de testplanning uitvoeren. • De opdrachtgever wil simpelweg tegen de minste kosten en moeite de optimale oplossing voor het probleem.

•

Coördinatie van de testactiviteiten: Het ontbreekt in projecten of in organisaties vaak aan voorschriften over de te hanteren testmethoden en technieken.

4.2 Gestructureerd testen: de aanbevelingen Om het testproces binnen een project of de testprocessen in een organisatie te structureren kunnen de belangrijkste bevindingen uit de diverse onderzoeken als basis dienen. •

Reductie van de tijdsdruk. Dit wordt bereikt door: • tijdige, flexibele planning; • voortgangsbewaking; • een tijdige start; • voldoende en geschikt personeel; • sluitende afspraken.

Reductie van de tijdsdruk wordt bevorderd door tijdig een mastertestplan op te stellen, waarin geregeld is welke partijen, welke tests, op welke momenten uitvoeren. De technieken strategiebepaling en testpuntanalyse (TPA) leveren de daarbij vereiste ondersteuning. • Projectmatige aanpak, los van de “lijnbeslommeringen”: De testactiviteiten moeten op basis van het testplan projectmatig worden aangepakt. De ruis van de lijn, zoals afdelingsoverleg, atv-verplichtingen, nevenactiviteiten en opleidingen, moet daarbij tot het minimum beperkt blijven. Het is raadzaam de testactiviteiten stringent te scheiden van de dagelijkse lijnbeslommeringen. Aangemaakt d.d.

27-12-2011

Pagina 8



•

Fasering van de testactiviteiten, parallel aan de bouwactiviteiten: Testactiviteiten moeten op enig moment tijdens het proces van systeemontwikkeling starten en in onderlinge samenhang met andere activiteiten worden uitgevoerd. Dat vraagt om een zorgvuldige fasering. Een faseringsmodel moet per testsoort fasegewijs de activiteiten beschrijven tot het niveau van ‘wat en wanneer’.

•

Voorschriftgeving en controle op de toepassing: De te gebruiken standaards voor het testen (faseringsmodel, documentatie, technieken, tools, enzovoort) moeten tijdig, eenduidig en centraal worden voorgeschreven.

•

Gestructureerd en passend gebruik van testtools: In theorie kunnen de meeste testactiviteiten geautomatiseerd worden uitgevoerd, dat wil zeggen er zijn testtools voor beschikbaar. Als de vereiste structuur in het testproces is aangebracht kunnen testtools passend worden ingezet. In eerste instantie moet daarbij gedacht worden aan ondersteunende tools voor begroting, planning, voortgangsbewaking, beheer van testdata, coverage analysers en rapportage tools. In tweede instantie aan zogenaamde primaire testtools voor onder andere testontwerp en record & playback.

•

Inrichting beheer: Het gaat hier om het beheer van het testproces zelf; haar omgeving en de testattributen zoals het testobject, de specificaties en de testware.

•

Reductie van tegengestelde belangen en teambuilding: Door het vroegtijdig opstellen van een mastertestplan waarin zoveel mogelijk afspraken tussen de diverse betrokkenen worden vastgelegd, wordt voorkomen dat in een later stadium conflicten de voortgang en het werkklimaat negatief beïnvloeden.

•

Inrichten van een testcoördinatie en/of testhelpdesk functie: Een facilitaire discipline die waar nodig de testactiviteiten coördineert en als helpdesk fungeert.

4.3 De vier pijlers onder een gestructureerde testaanpak De vier pijlers zijn een aan de ontwikkelingscyclus gerelateerde:

Figuur 2 De vier pijlers

•

Fasering (F): Door gebruik van een faseringsmodel wordt het overzicht behouden tijdens het systeemontwikkelingsproces. Door te noteren wat, wanneer, hoe, waar (mee), door wie, enz., moet gebeuren in het stramien van het proces, worden vanzelf de claims op en de relaties met de overige aspecten (pijlers) gelegd.

•

Technieken (T): Er zijn technieken ter ondersteuning van het planningsproces, intake en rapportage technieken. De belangrijkste groep technieken wordt gevormd door de testspecificatietechnieken waarmee bepaalde eigenschappen (kwaliteitsattrib uten) van een informatiesysteem worden gemeten. Er is geen enkele techniek waarmee alle attributen gemeten kunnen worden.

•

Infrastructuur (I): Om tests te kunnen uitvoeren is een testomgeving nodig. Deze omgeving moet stabiel, beheersbaar en representatief zijn. Verder moet deze omgeving zijn afgescheiden van andere omgevingen, zoals de ontwikkelingsomgeving.

•

Organisatie (O): Enerzijds is er de organisatie binnen het testteam, anderzijds is er de inbedding van het testteam in de projectorganisatie. Voor iedere test moet beschreven zijn wie hem uitvoert, wie er verantwoordelijk voor is, wie controleert dat de test goed is uitgevoerd en aan wie de resultaten worden doorgegeven.

Aangemaakt d.d.

27-12-2011

Pagina 9



5. TMap in een notedop 5.1 Testen als proces Voor alle testsoorten en vormen gelden de hoofdactiviteiten plannen, voorbereiden en uitvoeren. In grote lijnen komt het erop neer dat tijdens de creatie of aanpassing van de functionele specificaties een mastertestplan wordt opgesteld, waarin geregeld is wie, wanneer, welke testsoort of testvorm voor zijn rekening neemt. Omdat het testen meerdere disciplines raakt moeten de diverse taken, verantwoordelijkheden, mijlpalen en produkten worden beschreven in een testplan. In grotere projecten wordt de opdracht voor het tot stand komen en coördineren van dat testplan vaak belegd bij het management van een, al dan niet onafhankelijk, testteam. Op basis van het dit (Master)testplan worden vervolgens deeltestplannen gemaakt, meestal: • een White-box testplan; • een Systeem testplan; • een Acceptatie testplan. Na fixatie van de testplannen worden parallel aan de ontwerp- en realisatie-activiteiten de testgevallen en de testinfrastructuur ontwikkeld. Na de oplevering van het testobject wordt dan het daadwerkelijke testen uitgevoerd. Een testproces introduceert naast het systeemontwerp dus een tweede ontwerpproces, het testproces.

5.2 Testfasering In het faseringsmodel van TMap zijn de drie hoofdactiviteiten van het testen verdeeld over een vijftal fasen, te weten: 1. 2. 3. 4. 5.

planning en beheer; voorbereiding; specificatie; uitvoering; afronding.

Het TMap-faseringsmodel is een generiek model. Het is toepasbaar voor alle testsoorten en vormen. Voor de White-box testen bevat het te veel Figuur 3 Het TMap-faseringsmodel activiteiten. Het is aan de testverantwoordelijkheden de passende keuze te maken uit het TMap-arsenaal.

Binnen de hiërarchie van de testplannen zullen in een systeemontwikkelingsproces dus meerdere TMapmodellen functioneren voor de verschillende testsoorten.

5.2.1 De fase Planning en beheer De fase “Planning en beheer” start tijdens de specificatiefase. De uit te voeren activiteiten leggen de basis voor een beheersbaar en kwalitatief testproces. Nadat de testopdracht is gefixeerd wordt globaal kennis gemaakt met de specificaties, de materie en de organisatie (van het project). Het is onmogelijk het systeem volledig te testen. 100% dekkende testtechnieken bestaan alleen in theorie en geen enkele organisatie heeft daar tijd en geld voor. Daarom wordt via risicotaxatie de teststrategie bepaald. Afhankelijk van de risico’s wordt vastgesteld welke systeemdelen de meeste aandacht zullen krijgen en welke wat minder, enz. Een en ander wordt uiteraard nadrukkelijk afgestemd met de opdrachtgever. Testers mogen en kunnen dat niet zelf beslissen. Het doel is: De best haalbare dekkingsgraad op de juiste plaats. Aangemaakt d.d.

27-12-2011

Pagina 10



Het is belangrijk dat gedurende alle fasen van het testproces kwaliteitsindicaties worden afgegeven. Tegen het einde van het testproces wil de opdrachtgever, zo nodig onderbouwd met statistische informatie, weten welke risico’s er gelopen worden en dus welke maatregelen er genomen moeten worden. Er kan bijvoorbeeld worden besloten nog langer te testen of gedeeltelijk in produktie te gaan.

Aangemaakt d.d.

27-12-2011

Pagina 11



5.2.2 Activiteiten “Planning en beheer” • • • • • • • • • • • • • •

opdrachtformulering; globale intake en studie; vaststellen testbasis; bepalen strategie; inrichten organisatie; inrichten testprodukten; definiëren infrastructuur; inrichten beheer; bepalen planning; fixeren testplan; onderhouden testplan; uitvoeren beheer; rapporteren; bepalen detailplanning.

5.2.3 De fase Voorbereiding De fase begint met de detail intake van de specificaties en de overige documentatie die als testbasis dient. Er wordt inzicht in de testbaarheid verkregen door te onderzoeken op bijvoorbeeld uniforme notatie, scheidbaarheid en herkenbaarheid. Naar aanleiding hiervan zal de kwaliteit van de testbasis kunnen toenemen. Na de intake wordt de testbasis (in samenwerking met de bouwers) onderverdeeld in onafhankelijke opleverbare en testbare systeemdelen. Vervolgens wordt aan deze testeenheden de testtechnieken toegewezen en wordt een planning gemaakt van het vervolg van de testactiviteiten.

5.2.4 Activiteiten “Voorbereiding” • • • •

detail intake testbasis; definiëren testeenheden; toewijzen testtechnieken; specificeren infrastructuur.

5.2.5 De fase Specificatie Tijdens de fase Specificatie worden de testgevallen gespecificeerd en de bijbehorende testinfrastructuur gerealiseerd. De creatie van testgevallen wordt in twee stappen uitgevoerd: • het logisch en • het fysiek testontwerp. Op het moment dat de testbasis beschikbaar is, worden op basis daarvan (logische) testgevallen gespecificeerd (testspecificaties). Bij een testgeval moet hierbij worden gedacht aan de beschrijving van de uitgangssituatie, het veranderingsproces en de resultaatvoorspelling. Later als er meer bekend is over de technische realisatie, worden de logische testgevallen vertaald naar fysieke testgevallen (testscripts).

5.2.6 Activiteiten “Specificatie” • • • • • •

opstellen testspecificaties; definiëren uitgangsbestanden; opstellen testscripts; opstellen testdraaiboek; specificeren intake testobject/infrastructuur; realiseren infrastructuur.

5.2.7 De fase Uitvoering De fase Uitvoering start op het moment dat de eerste testbare componenten beschikbaar zijn. Eerst worden de opgeleverde (delen van) applicaties gecontroleerd op volledigheid en in de testomgeving geïnstalleerd. Daarna wordt gecheckt of het samenstel van applicaties en technische infrastructuur überhaupt werken (intake). Om het testen te beginnen moeten de initiële testbestanden gevuld worden. Als zowel de (delen van) de applicaties, de infrastrctuur als de initiële bestanden klaar staan, worden de zogenaamde pretest uitgevoerd met als doel de werking van de hoofdtaken van het te testen object te Aangemaakt d.d.

27-12-2011

Pagina 12



controleren. De pretest geven het antwoord op de vraag: Is de kwaliteit van het testobject van dien aard dat het grondig aan de tand gevoeld kan worden met de daadwerkelijke testuitvoering.

5.2.8 Activiteiten “Uitvoering” • • • • •

intake testobject / infrastructuur; vullen uitgangsbestanden uitvoeren (her)tests; controleren en beoordelen testresultaten; onderhouden testdraaiboek.

5.2.9 De fase Afronding Tijdens de afronding wordt er een selectie gemaakt van de vaak grote hoeveelheid testware, zoals de testgevallen, de testresultaten en ook bijvoorbeeld de beschrijvingen van de testinfrastructuur en de gebruikte tools. Het oogmerk is hierbij dat bij wijzigingen en de bijbehorende onderhoudstests de testware alleen maar aanpassing behoeft en er dus niet opnieuw een complete nieuwe testset moet worden ontworpen (regressietesten).

5.2.10 Activiteiten Afrondingsfase • • • • •

evalueren testobject; evalueren testproces; opstellen evaluatierapport; conserveren testware; decharge testteam.

Figuur 4 Activiteiten in de TMap-fasering

5.3 Testtechnieken Testtechnieken per TMap fase •

•

• • •

Planning en beheer • Strategiebepaling; • Testpuntanalyse (TPA); • Diverse checklists. Voorbereiding • Detail intake testbasis; • Fagan inspection. Specificatie • Testspecificatietechnieken Uitvoering • Checklists kwaliteitsattributen Afronding • Diverse checklists

5.3.1 Strategiebepaling Het bepalen van een expliciete teststrategie is een instrument om met de opdrachtgever (van de test) te communiceren over de organisatie en de strategische keuzen van het testen. De opdrachtgever van een test verwacht bepaalde kwaliteiten van het op te leveren systeem die van geval tot geval heel verschillend zijn. Het is van groot belang in staat te zijn daarover met de opdrachtgever te kunnen communiceren, en afhankelijk van de wensen van de opdrachtgever een vertaling te maken naar de manier waarop getest zal worden. Een risicotaxatie vormt de basis voor de teststrategie, omdat het van belang is de testinspanning (testdekking) optimaal in te zetten. Met de techniek voor strategiebepaling wordt geanalyseerd hoeveel in een test moet worden geïnvesteerd om de optimale balans te vinden tussen de gewenste kwaliteit en de hoeveelheid tijd c.q. geld die daarvoor nodig is.

Aangemaakt d.d.

27-12-2011

Pagina 13



5.3.2 Testpuntanalyse (TPA) TPA is geschikt voor het begroten van de black-box testsoorten, systeem- en acceptatietest. TPA herleidt de Functie-Punt-Analyse (FPA) punten naar testpunten op basis waarvan vervolgens het aantal testuren berekend wordt. De TPA-techniek analyseert de impact van specifieke testbeïnvloedingsfactoren, zoals bijvoorbeeld de kwaliteitseisen, de omvang en de complexiteit van het systeem, maar ook de kwaliteit van de testbasis of de mate waarin testtools worden gebruikt.

5.3.3 Detail intake testbasis De testbasis wordt gevormd door de documentatie op basis waarvan de tests worden voorbereid. De intake is in wezen een audit van de testbasis waarbij gekeken wordt of de documentatie voldoende compleet, accuraat en consistent is om als uitgangspunt voor de test te dienen.

5.3.4 Testspecificatietechniek Op basis van de ‘uitgangsinformatie’ moeten testgevallen worden bepaald. Een elementair testgeval bestaat uit: • de uitgangssituatie; • het veranderingsproces en; • een resultaatvoorspelling. Een testspecificatietechniek Is een gestandaardiseerde manier om vanuit uitgangsinformatie testgevallen af te leiden.

5.3.5 Checklists Tmap biedt een groot aantal checklists (zie bijlage B - Checklists).

5.4 Infrastructuur en tools De infrastructuur voor het testen bevat alle faciliteiten en middelen die nodig zijn om naar behoren te kunnen testen: • testomgevingen: Testomgevingen worden ingericht op basis van de testsoort en testvorm. • laboratorium omgeving voor White-box testen; • beheersbare systeemtestomgeving; • de ‘als het ware’ omgeving voor acceptatietesten. •

testtools: • record & playback: Het kunnen ‘opnemen’ van een testsessie om die naderhand automatisch te kunnen spelen. • comparators: Het automatisch vergelijken van testresultaten met resultaten van voorgaande sessies. • testdrivers: Een vervanging van een aansturingsprogramma dat nog niet is opgeleverd, om toch de onderliggende delen al te kunnen testen. • simulators: Tools waarmee de ‘life-omgeving’ kan worden nagebootst voor het testen van bijvoorbeeld de performance. • coverage analysers: Daarmee wordt gemeten in hoeverre het testobject door testgevallen is gedekt.

•

werkplekken (kantoorinrichting)

5.5 Organisatie De organisatie van gestructureerd testen vraagt aandacht op de volgende aspectgebieden: • • • •

het operationele testproces; de structurele testorganisatie; testbeheer; personeel & opleidingen;

Aangemaakt d.d.

27-12-2011

Pagina 14

Uittreksel Titel: Testen volgens TMap •


structurering van het testproces.

Aangemaakt d.d.

27-12-2011

Pagina 15



5.5.1 Het operationele testproces De belangrijkste functies zijn: • testen; • testmanagement; • beheer. Kennis dient aanwezig te zijn op het gebied van: • testen; • het testobject; • gebruik en beheer; • infrastructuur en tools.

5.5.2 De structurele testorganisatie Kent twee functies: • voorwaarde scheppende • testvoorschriftgeving • coördinatie van testprocessen • testbeheer • methodische en technische ondersteuning • operationele

5.5.3 Testbeheer Het in bedwang houden van: • het testproces; • de testinfrastructuur; • de testprodukten.

5.5.4 Structurering van het testproces Teststructurering vindt meestal haar oorsprong in een of andere kostbare fout of, zo u wilt, ramp. Het management besluit dan ‘dat er nu maar eindelijk eens iets moet gebeuren’. Er wordt iemand belast met de structurering en er wordt alvast een project of een systeem als pilot geselecteerd, waarmee die structurering zich moet bewijzen. Dat gaat nogal eens mis. Een structureringsproces vraagt een strategie en know-how op zowel het gebied van organisatieverandering als van testen. Na inventarisatie van de actuele testpraktijk en de mogelijkheden voor het structureringsproces moet stapsgewijs getransformeerd worden van ist naar soll. Tijd en tact spelen daarbij een belangrijke rol.

6. Variaties op het thema 6.1 Inleiding TMap is een generiek model. De oorspronkelijk voor het black-box testen in nieuwbouw situaties ontworpen aanpak is geëvalueerd tot een werkbasis voor vrijwel alle testsoorten en testactiviteiten in de informatievoorziening. De TMap-pijlers fasering, technieken, infrastructuur en organisatie kunnen voor andere testvormen worden gehanteerd. Dit vraagt het een en ander van zowel de samenstellers van de TMap-standaard als van de gebruikers daarvan. Primair staat een verantwoord testproces, niet onderbelicht maar vooral ook niet overdone. Soms vraagt een testproces extra’s in de vorm van speciale technieken of een afwijkende organisatiestructuur. Die kunnen dan meestal gemakkelijk van de standaard worden afgeleid. Vanwege verscheidenheid in aanbod en gebruiksvormen is het uiteraard onmogelijk dé standaard testinfrastructuur te beschrijven. TMap biedt een referentiekader op basis waarvan de testinfrastuctuur kan worden gedefinieerd.

Aangemaakt d.d.

27-12-2011

Pagina 16



6.2 Variaties Bij elke standaard aanpak ontstaan in het gebruik variaties die zich min of meer als een specifieke subset van de standaard ontwikkelen. Hierna wordt ingegaan op enkele gebieden waarin dit fenomeen zich met betrekking tot TMap voordoet.

6.3 Testen in de onderhoudssituatie TMap kan zowel worden gebruikt bij nieuwbouw als bij het onderhoud van informatiesystemen. Er is slechts sprake van een benadering vanuit een ander perspectief, hetgeen een aantal accentverschuivingen veroorzaakt (zie figuur 5).

Figuur 5 Systeemonderhoud in het V-model

In grote lijnen kun echter gesteld worden dat het onderhoudstesten op dezelfde ‘manier kan worden aangepakt als b ij nieuwb ouw.

6.3.1 Ontwikkel- en testproces Het ontwikkelen testproces, dat geldt in nieuwbouwsituaties, verandert voor onderhoud in principe niet. Er is sprake van een white-box programma- en integratietest en van een black-box systeem- en acceptatietest. Een onderhoudstestproces start meestal bij de ontvangst van een wijzigingsaanvraag of een releaseplan.

6.3.2 Soorten onderhoud Met betrekking tot het soort onderhoud is uit het oogpunt van het testen een tweedeling te maken: •

planbaar onderhoud: Tot deze categorie behoren: • perfectief onderhoud (aanpassen van de programmatuur aan nieuwe wensen) • adaptief onderhoud (aanpassen van programmatuur aan veranderingen in de omgeving) • correctief planbaar onderhoud (uitstelbaar herstel van fouten of tekortkomingen)

•

ad-hoc correctief onderhoud: Ad-hoc correctief onderhoud heeft te maken met storingen die onmiddellijk om een oplossing vragen. Het zal niet mogelijk zijn de benodigde stappen van een gestructureerde testaanpak uit te voeren. Ook ten aanzien van ad-hoc onderhoud is het mogelijk om door middel van een bepaalde testaanpak een kwaliteitsverbetering te realiseren. Belangrijk is het uitvoeren van een goede risico-analyse met betrekking tot het informatiesysteem en op basis van de uitkomsten ervan, het definiëren van een aantal standaard tests.

6.4 Geïntegreerde testaanpak In veel organisaties worden de systeemtest en de acceptatietest geheel of gedeeltelijk samengevoegd. Dit verschijnsel wordt de ‘Geïntegreerde testaanpak’ genoemd. Bij toepassing van een geïntegreerde test wordt tevoren tussen de partijen afgesproken welke aspecten bij welke test en tot welk niveau aan de orde komen. Doorgaans door het toewijzen van kwaliteitsattributen en daaraan gekoppeld de testvormen en de te gebruiken technieken of een te realiseren dekkingsgraad. De ontwikkelaars en de gebruikers specificeren ieder hun eigen testgevallen, zoveel mogelijk onafhankelijk van elkaar, parallel aan de technisch ontwerpfase en de systeemrealisatie. Een geïntegreerde test wordt voorafgegaan door een (gereduceerde) systeemtest. De overeengekomen aspecten worden tot het afgesproken niveau door de ontwikkelaars aan een systeemtest onderworpen. De gebruikers spelen daarbij geen rol. Na uitvoering van het systeemtestdeel wordt in samenwerking tussen de ontwikkelaars en de gebruikers het systeem geconfronteerd met de voor het geïntegreerde deel overeengekomen testgevallen. Aangemaakt d.d.

27-12-2011

Pagina 17



Ten aanzien van de verantwoordelijkheden moet worden opgemerkt dat de ontwikkelaar onverminderd verantwoordelijk blijft voor het ter acceptatie aan te bieden produkt. De participatie van de gebruiker bij de geïntegreerde test moet uitsluitend gekenschetst worden als ondersteuning van het ontwikkelproces. De gebruiker accepteert het systeem door het uitvoeren van een acceptatietest.

6.4.1 Risico’s, maatregelen en overwegingen •

De geïntegreerde testaanpak kan slechts worden toegepast nadat vooraf eenduidige afspraken gemaakt zijn over een groot aantal aspecten.

•

Een belangrijk risico van de geïntegreerde testaanpak is de verminderde onafhankelijkheid van de betrokkenen. Hoewel formeel goede afspraken te maken zijn, kunnen conflicten ontstaan over allerlei onderwerpen.

•

Een risico bij de geïntegreerde test is de late constatering dat één van de partijen geen goede test heeft voorbereid. Het is dan vaak niet meer mogelijk om die schade te herstellen.

•

Een maatregel ter voorkoming van conflicten en of te late constatering van onvoldoende voorbereiding voor het testen, is het inschakelen van een controlerende derde partij. Deze taak kan bijvoorbeeld worden ingevuld door een kwaliteitszorg medewerker.

6.5 Client/Server, GUI’s, OO, RAD, CASE en CAST Steeds meer informatiesystemen worden geëxploiteerd in andere dan de klassieke mainframe infrastructuur. De beperkingen van de mainframe omgevingen remmen organisaties snel te kunnen inspelen op veranderende wensen uit de markt. Diensten en produkten moeten met concurrerende snelheid in exploitatie kunnen worden gebracht. Time-to-market is de slogan van de jaren negentig. Om in dat kader doeltreffend te kunnen opereren wil de gebruiker tijdig en snel over betrouwbare informatie beschikken. Hij wil daarvoor een flexibele informatie infrastructuur. Om zijn doel te bereiken wil de gebruiker vanaf zijn werkplek alle beschikbare applicaties en gegevens kunnen aanwenden. Dat vraagt integratie van hardware en applicaties, van hulpmiddelen en (lokale) netwerken, open systemen, enzovoort. Deze mogelijkheden worden in het algemeen geboden door de zogenaamde client/server technologie.

6.5.1 Client/Server De client/server technologie bestaat uit een groot aantal componenten voor zowel Figuur 6 De vijf Client/Server architecturen (Gartner Group) ontwikkeling als exploitatie. Vooralsnog kan het fenomeen client/server worden beschreven als een technologie waarin informatiesystemen in onafhankelijke processen worden onderverdeeld, die door clients worden geïnitieerd en door servers worden uitgevoerd. Het gebruik van een standaard communicatie taal is daarbij essentieel. Voor het testen is het van belang over de logische inrichting van applicaties duidelijkheid te verkrijgen. Informatiesystemen zijn in het algemeen onderverdeeld in 3 logische onderdelen: • presentatie; • toepassing; • gegevens. Dit onderscheid speelt een belangrijke rol bij het distribueren van delen van een applicatie over meerdere hardwareplatforms. In samenhang hiermee heeft de Gartner Group vijf client/server architecturen (zie figuur 6) vastgesteld, waarbinnen de logische applicatieonderdelen over client en server verspreid zijn. Deze verdeling van de applicatie-onderdelen is van grote invloed op het testen, in het bijzonder op de toe te passen teststrategie en testspecificatietechnieken. Er is sprake van dislocatie van functionaliteit en gegevens en een veelheid aan nieuwe c.q. afwijkende situaties voor de tester in de client/server omgeving.

6.5.2 Graphical User Interfaces (GUI’s) De transformatie van karakter-georiënteerde naar grafisch georiënteerde software voor gebruikersinterfaces (GUl’s) vraagt ook een transformatie van de testwijze en voorlopig meer testinspanning.

Aangemaakt d.d.

27-12-2011

Pagina 18



Voor het testen geldt dat er een aantal testniveaus te onderscheiden is: • individuele vensters • interactie tussen vensters • individuele applicaties • interfaces tussen applicaties. Daarbinnen vragen de verschillende schermattributen hun eigen aandacht. Het is van belang de GUl-tests in de aangegeven niveaus te organiseren. De tests worden dakpansgewijs opgezet, waarbij na elke test weer de werking van een attribuut of een component wordt goedgekeurd, tot en met de integrale werking van de totale interface. Wellicht nog sterker dan bij andere tests is het aantal mogelijke testsituaties bij GUl-tests vrijwel onbeperkt. Het gebruik van testtools is bij het testen van GUl’s sterk aan te raden. Zeker record & playback tools die de vele scherminteracties nauwkeurig en snel kunnen (her) testen zijn zeer bruikbaar, of eigenlijk een must.

6.5.3 Object Oriented Development (OO) Voor wat betreft het testen is OO alleen een (gestructureerde) stap meer in de goede richting. De werkwijze bij het ontwerp (onderkennen, beschrijven, classificeren en structureren van objecten) en de realisatie (specificeren, bouwen en implementeren van methods) bieden testers de vereiste structuur. Zowel de white-box als de black-box tests, en daarbinnen zowel de intake van de testbasis als de statische en de dynamische tests, kunnen conform de TMap-bouwstenen worden uitgevoerd. De mogelijkheden van parallellisatie van tests en de integratie van testspecificaties van ontwikkelaars en gebruikers zullen door OO toenemen. Zoals altijd geldt ook hier dat testers optimaal van de voordelen kunnen profiteren bij consequente toepassing van de ontwikkelstandaards en standaard functionaliteit. Hoe meer daarvan wordt afgeweken, hoe meer testinspanning vereist is!

6.5.4 RAD, Evolutionaire systeemontwikkeling In grote lijnen komt het er op neer dat bij RAD de nadruk ligt op het specificeren, ‘prototypen’ en realiseren van systeemdelen in kleine teams van gebruikers en ontwikkelaars, waarbij gebruik gemaakt wordt van de meest geavanceerde hulpmiddelen. De evolutionaire aanpak kan in principe RAD impliceren, maar legt meer nadruk op het stapsgewijs ontwikkelen c.q. aanpassen van kleine systeemdelen naar de uiteindelijke gewenste totaaloplossing. Het testen bij dit soort ontwikkelingsprocessen is bij consequente toepassing van de overeengekomen werkwijze gemakkelijker. De deelontwikkelingen kunnen als dakpannen worden beschouwd, die alle hun eigen testproces kunnen doorlopen. Zowel de testbasis (de specificaties) als het testobject komt dakpansgewijs tot stand en kan als zodanig als invoer dienen voor specificatie en de uitvoering van de respectievelijke white-box en black-box tests.

6.5.5 CASE en CAST “Computer Aided Software Engineering en Testing stellen een verzameling hulpmiddelen voor waarmee in theorie systemen vanaf de specificaties geheel geautomatiseerd gerealiseerd en getest kunnen worden. Zowel de software als de testware worden vanaf de Specificaties gerealiseerd en vervolgens met elkaar geconfronteerd. De resultaten worden automatisch vergeleken en wellicht automatisch hersteld. “Een kind kan de was doen. “De systeemontwikkeling beperkt zich tot de selectie en toepassing van tools!”

6.5.6 Impact algemeen In het algemeen concentreert de impact van client/server en gerelateerde technologieën en ontwikkelingsmethoden op het testen zich vooralsnog op de volgende aspecten: • Toepasbaarheid van TMap: Tmap biedt voldoende bouwstenen voor de inrichting en uitvoering van testprocessen. •

Meer aandacht voor het ontwikkelingsproces en de gebruikte hulpmiddelen: De aandacht zal verschuiven van het testobject naar het ontwikkelingsproces en de consequente toepassing van de gebruikte hulpmiddelen.

•

Uitgaan van consequent gebruik van ontwikkelstandaards: Tests zullen worden afgestemd op strikte toepassing van de standaards voor bijvoorbeeld modulariteit,

Aangemaakt d.d.

27-12-2011

Pagina 19



object oriëntatie en het gebruik van hulpmiddelen. •

Nieuwe testvormen: Voor sommige aspecten zullen nieuwe of afwijkende testnormen ontstaan.

•

Technology-push: De tester wordt voortdurend geconfronteerd met een niet aflatende technology-push en het kost veel tijd en inlevingsvermogen van het testpersoneel om bij te blijven.

Aangemaakt d.d.

27-12-2011

Pagina 20



•

Onvolwassenheid technologie: De veelheid, de complexiteit en het innovatieve karakter van de toegepaste technologische hulpmiddelen is op zichzelf een bron van fouten. Bij het bepalen van de teststrategie moet dit fenomeen aandacht krijgen.

•

Verhouding bouwen testinspanning: De ervaring leert dat de technologische ontwikkelingen zich het eerst richten op de technische infrastructuur; daarna op de ontwikkelings- en beheeraspecten en vervolgens pas op het voorzien in passende testinstrumenten. Hierdoor dreigt de verhouding testinspanning ten opzichte van bouwinspanning onevenwichtig te worden. Door toepassing van evolutionaire en ‘rapid’ ontwikkelingsmethoden wordt de tester in dit kader ook nog geconfronteerd met een latere beschikbaarheid van de testbasis (de specificerende documentatie). De structureel bij het testen aanwezige tijdsdruk zal voorlopig dus toenemen. Daarom moet gezocht worden naar een nog betere balans tussen: • tijd en kwaliteit van het testproces; • testen en toetsen (meer toetsen dan voorheen); • white-box en black-box tests (meer integratie).

6.6 Testen van pakketten 6.6.1 Inleiding Het aanschaffen van een pakket in plaats van het zelf ontwikkelen van software is iets wat steeds vaker voorkomt. Het aantal beschikbare pakketten, alsmede de goede kwaliteit ervan, is hier vooral debet aan. Wat zijn echter de gevolgen van deze ontwikkeling voor het testen? De doelstelling van testen is het verkrijgen van een bepaalde mate van inzicht in de kwaliteit. In dit kader is bij het testen van pakketten een drietal vragen van belang:

1. Voldoet het pakket aan de leveranciersspecificaties?

beantwoorden d.m.v. de Innametest 2. Voldoet het pakket aan de wensen en eisen van de Organisatie? beantwoorden d.m.v. de Functietest 3. Kan het pakket in produktie worden genomen? beantwoorden d.m.v. de Acceptatietest De eerste twee vragen dienen in principe te worden beantwoord tijdens het proces van pakketselectie (dus voordat het pakket is aangeschaft!) en de laatste vraag tijdens het implementatieproces.

6.6.2 De Innametest Het vaststellen of het pakket voldoet aan de leveranciersspecificatie is het eerste aspect dat moet worden beoordeeld. De leveranciersspecificaties vormen dus de testbasis voor de innametest. Voor het uitvoeren van de innametest zijn er verschillende mogelijkheden: • uitvoeren en beoordelen bijgeleverde testset; • zelf testen van kritieke functies; • statisch testen, door analyse van ervaringen van bestaande gebruikers en beoordeling van tests en de kwaliteitszorg van de leverancier.

6.6.3 De Functietest Nadat is vastgesteld dat het pakket voldoet aan de leveranciersspecificatie, moet worden beoordeeld of het pakket voldoet aan de wensen en eisen van de organisatie. Dit is het moeilijkste, maar ook het belangrijkste onderdeel van pakkettesten. De volgende TMap-activiteiten worden in het kader van de functietest minimaal onderkend: • bepalen teststrategie • fixeren testplan • detail intake testbasis • opstellen testspecificaties • opstellen testdraaiboek • uitvoeren (her) tests • controleren en beoordelen testresultaten • rapporteren Aangemaakt d.d.

27-12-2011

Pagina 21



conserveren testware.

6.6.4 De Acceptatietest De acceptatietest moet antwoord geven op de vraag: ‘Kan het pakket in produktie worden genomen?”

6.6.5 Overall-aanpak pakkettesten •

•

•

Voor de aanschaf: - opstellen testplan - uitvoeren statische innametest (ervaring van andere gebruikers) - uitvoeren van functietest (detail intake testbasis, specificatie testgevallen) Voor de aanschaf en ná ontvangst van pakket: - update testplan, indien noodzakelijk - uitvoeren innametest (uitvoeren en beoordelen bijgeleverde testsets; zelf testen, statisch) - uitvoeren functietest (specificatie testgevallen, uitvoeren en beoordelen functietest) Nadat het pakket is aangeschaft: - test aanpassingen (ontwikkeltests, programma-, integratie- en systeemtests) - uitvoeren acceptatietest volgens TMap.

Deel II: Fasering 7. Inleiding Fasering 7.1 De pijlers Figuur 7 De fasering als centrale pijlers

7.2 Testsoorten 1. 2. 3. 4.

Het testproces begint met het opstellen van het mastertestplan. Vervolgens wordt een start gemaakt met de activiteiten van zowel de acceptatietest als de systeemtest. Tijdens de technische ontwerp-fase wordt gestart met de eerste activiteiten van de integratietest Gelijktijdig met de programmeringsfase wordt tenslotte gestart met de activiteiten van de programmatest.

Het opstellen van het Mastertestplan is uitgewerkt in hoofdstuk 8 ‘Mastertestplanning’. De systeemtest en de acceptatietest zijn black-box tests en worden op soortgelijke wijze uitgevoerd. De fasering is uitgewerkt in hoofdstuk 9 ‘Fasering Black-box testen. De programmatest en de integratietest zijn beide white-box tests en worden op soortgelijke wijze uitgevoerd. De fasering is uitgewerkt in hoofdstuk 10 ‘Fasering White-box testen’.

Aangemaakt d.d.

27-12-2011

Pagina 22



8. Mastertestplanning 8.1 Inleiding Het mastertestplan heeft tot doel de verschillende testprocessen binnen het systeemontwikkelingsproces op elkaar af te stemmen. Alle eisen met betrekking tot de functionaliteit en de kwaliteit die van belang zijn voor het juist functioneren van het systeem worden verdeeld over de verschillende testsoorten om onnodige redundantie te voorkomen en het rendement van de testinspanning te optimaliseren.

8.2 Randvoorwaarden Voorwaarden waaraan moet zijn voldaan alvorens kan worden gestart met het opstellen van het mastertestplan: • • • • • • •

Een beschrijving van de organisatie van het systeemontwikkelingsproces. Inzicht in de globale (oplever)planning van het systeemontwikkelingsproces. Inzicht in de ontwikkelingsomgeving. Ten behoeve van het definiëren van de testomgeving inzicht in de toekomstige produktieomgeving. Inzicht in de werkwijze met betrekking tot het opstellen van de testbasis (systeemontwikkelingsmethode). Inzicht in de systeemeisen op globaal niveau. Bereidheid en contractueel de mogelijkheid tot algemene afspraken op het gebied van testen.

8.3 Werkwijze Gestart wordt met het formuleren van de testopdracht om het beschouwingsgebied van het mastertestplan en de daarin te betrekken testsoorten vast te stellen. Vervolgens wordt een oriëntatie uitgevoerd om de kennis op te doen van het systeemontwikkelingsproces en het project. Door middel van de strategiebepaling wordt de plaats van het testen binnen het totale scala van kwaliteitszorgmaatregelen bepaald. Vastgelegd wordt welke kwaliteitsaspecten van het systeem worden getest en met welke diepgang. Vervolgens vindt een verdeling van de geselecteerde kwaliteitsaspecten plaats over de onderkende testsoorten en wordt een globale begroting opgesteld. Tevens vindt een inventarisatie plaats van de benodigde testorganisatie en infrastructuur, over de diverse testsoorten heen. Met name het op projectniveau regelen van een aantal testfuncties en afspraken met betrekking tot de infrastructuur kunnen leiden tot kostenbesparing. Tenslotte wordt een globale planning opgesteld voor het totale testproces. Op basis van het voorgaande wordt het mastertestplan samengesteld en gefixeerd.

8.4 Activiteiten •

Opdrachtformulering: Doel: vastleggen van: • opdrachtgever • opdrachtnemer • testsoorten • beschouwingsgebied • doel Produkten: opdrachtformulering, vastgelegd in het mastertestplan.

•

Oriëntatie: Doel: inzicht verkrijgen in • de organisatie; • de doelstelling van het systeemontwikkelingsproces, het te ontwikkelen informatiesysteem

Aangemaakt d.d.

27-12-2011

Pagina 23



de eisen waaraan het systeem moet voldoen

Aangemaakt d.d.

27-12-2011

Pagina 24



Werkwijze: • het bestuderen van de beschikbare documentatie. • het afnemen van interviews Technieken: Checklist ‘Globale bestudering informatiesysteem’ (hoofdstuk 18). •

Bepalen teststrategie: Doel: welke kwaliteitsaspecten worden getest bij welke testsoort Werkwijze: • Verkrijgen inzicht kwaliteitszorgmaatregelen; • Strategiebepaling; - bepalen kwaliteitsattributen; - bepalen relatief belang kwaliteitsattributen; toewijzen kwaliteitsattributen testsoorten • Opstellen (globale) begroting testsoorten Produkten: teststrategie inclusief een globale begroting, vastgelegd in het mastertestplan. Technieken: • strategiebepaling (hoofdstuk 12) • Testpuntanalyse (hoofdstuk 13)

•

Definiëren organisatie: Doel: functies, taken, verantwoordelijkheden en bevoegdheden definiëren voor totale testproces over de testsoorten heen. Werkwijze: • bepalen benodigde functies; • 2. toewijzen taken, bevoegdheden en verantwoordelijkheden Produkten: testorganisatie vastgelegd in het mastertestplan

•

Definiëren infrastructuur: Doel: vaststellen van de voor het testproces benodigde infrastructuur. Werkwijze: • definiëren testomgeving; • definiëren testtools; • vaststellen infrastructuurplanning. Produkten: beschrijving infrastructuur, inclusief planning, vastgelegd in mastertestplan. Technieken: Checklist ‘Testfaciliteiten’ (hoofdstuk 18).

•

Bepalen planning: Doel: opstellen globale planning voor het totale testproces. Werkwijze: vaststellen en vastleggen van: • uit te voeren activiteiten; • relaties met en afhankelijkheden van andere activiteiten; • te besteden tijd per testsoort; • benodigde en beschikbare doorlooptijd; • op te leveren produkten. Produkten: globale planning vastgelegd in het mastertestplan.

Aangemaakt d.d.

27-12-2011

Pagina 25



Fixeren mastertestplan: Doel: • vastleggen van de resultaten van alle tot nu toe uitgevoerde actviteiten; • verkrijgen van goedkeuring van de gekozen aanpak door opdrachtgever. Werkwijze: • vaststellen risico’s en bedreigingen met betrekking tot: - haalbaarheid; - testbaarheid; - stabiliteit; ervaring. • opstellen mastertestplan • fixeren mastertestplan (ondertekenen door opdrachtgever) Produkten: Mastertestplan. Technieken: Checklist ‘Risico’s testproject’ (hoofdstuk 18).

9. Fasering Black-box testen 9.1 Inleiding Zowel de systeemtest als de acceptatietest zijn black-box tests. Zij zijn feitelijk te beschouwen (en daarmee ook te organiseren) als op zich zelf staande processen, elk met hun eigen faseringsmodel. Het zijn processen, parallel aan het ontwikkelingsproces, die dienen te starten tijdens het opstellen van de functionele specificaties. De leverancier voert de systeemtest uit om vast te stellen of het systeem aan de functionele en technische eisen voldoet. Nadat de leverancier de systeemtest heeft uitgevoerd en de aangetroffen fouten heeft hersteld en aan een hertest onderworpen, wordt het systeem ter acceptatie aan de opdrachtgever aangeboden. De acceptatietest moet antwoord geven op vragen als: “Kan het systeem (op nieuw) in produktie en beheer genomen worden?” en “Heeft de leverancier aan zijn verplichtingen voldaan?”. De uitvoering van de acceptatietest vraagt een testomgeving die zoveel mogelijk representatief is voor de produktie-omgeving (‘alshet-ware-produktie’).

9.2 Fase Planning en beheer 9.2.1 Inleiding In een testplan wordt vastgelegd hoe, door wie, waarmee, en wanneer de testactiviteiten uitgevoerd gaan worden. Daarna zijn de activiteiten gericht op de coördinatie, de bewaking en het beheer van het testproces en het verschaffen van inzicht in de kwaliteit van het testobject. Door middel van periodieke en ad hoc rapportages wordt de opdrachtgever geïnformeerd.

9.2.2 Randvoorwaarden Aan de volgende voorwaarden dient te zijn voldaan alvorens kan worden gestart met de fase ‘Planning en beheer’: • • • • • •

een ingerichte organisatie voor het systeemontwikkelingsproces; in die gevallen waar voor het totale testproces een mastertestplan is opgesteld, dient dat te zijn gefixeerd; inzicht in de (oplever) planning van het systeemontwikkelingsproces; inzicht in de ontwikkelomgeving; ten behoeve van het definiëren van de testomgeving inzicht in de toekomstige produktie-omgeving; inzicht in de werkwijze met betrekking tot het opstellen van de ontwerp documentatie (systeemontwikkelmethode).

9.2.3 Werkwijze De fase ‘Planning en beheer’ start tijdens de specificatie- of functioneel ontwerp-fase. Door middel van het testplan wordt het fundament gelegd voor een gestructureerd testproces.

Aangemaakt d.d.

27-12-2011

Pagina 26



Na het vaststellen van de testopdracht wordt globaal kennis genomen van de beschikbare systeem- en projectdocumentatie, de aan het systeem gestelde eisen met betrekking tot functionaliteit en kwaliteit en de organisatie van het systeemontwikkelingsproces. Vervolgens wordt een teststrategie bepaald waarin wordt vastgesteld welke eigenschappen van het informatiesysteem met welke diepgang worden beoordeeld. Tevens wordt de testorganisatie ingericht, worden de (op te leveren) testprodukten gedefinieerd en worden aspecten met betrekking tot de infrastructuur en het beheer geregeld. Tenslotte wordt een (globale) planning opgesteld. Op basis van de voorgaande activiteiten wordt het testplan samengesteld en gefixeerd. De overige activiteiten van deze fase worden gedurende het hele testproces uitgevoerd en zijn gericht op de coördinatie, de bewaking en het beheer van het testproces en het verschaffen van inzicht in de kwaliteit van het testobject. Tijdens het testproces wordt voor elke testfase een detailplanning opgesteld en onderhouden. Conform de in het testplan vastgelegde vorm en frequentie, en op verzoek ad hoc, wordt over de voortgang van het testproces en de kwaliteit van het testobject gerapporteerd aan de opdrachtgever.

9.2.4 Activiteiten De fase ‘Planning en beheer’ bestaat uit de volgende activiteiten in het kader van het opstellen van het testplan: 1. Opdrachtformulering 2. Globale intake en studie 3. Vaststellen testbasis 4. Bepalen teststrategie 5. Inrichten organisatie 6. Inrichten testprodukten 7. Definiëren infrastructuur 8. Inrichten beheer 9. Bepalen planning 10. Fixeren testplan. De volgende activiteiten worden onderkend in het kader van de coördinatie, de bewaking en het beheer van het testproces: 11. Onderhouden testplan 12. Uitvoeren beheer 13. Rapporteren 14. Bepalen detailplanning.

Figuur 8 Fase Planning en beheer Onderstaand schema geeft de volgorde en de afhankelijkheden aan tussen de verschillende activiteiten:

9.3 Fase Voorbereiding 9.3.1 Inleiding De belangrijkste doelstelling van de fase Voorbereiding is het vaststellen of de testbasis voldoende kwaliteit bevat voor het specificeren en uitvoeren van de testgevallen (testbaarheid).

9.3.2 Randvoorwaarden Aan de volgende voorwaarde dient te zijn voldaan alvorens kan worden gestart met de fase Voorbereiding: • de testbasis dient beschikbaar en gefixeerd te zijn.

9.3.3 Werkwijze Nadat de testbasis beschikbaar is gesteld, wordt gestart met de detail in take van de testbasis. Er wordt inzicht in de testbaarheid verkregen door te onderzoeken op bijvoorbeeld uniforme notatie, consistentie en volledigheid. Na de intake wordt het informatiesysteem verdeeld in testbare eenheden (testeenheden) en Aangemaakt d.d.

27-12-2011

Pagina 27



worden aan de onderkende testeenheden testtechnieken toegewezen. Dit alles met de reeds eerder gedefinieerde teststrategie als uitgangspunt. Tenslotte wordt de definitie van de infrastructuur, zoals vastgelegd in het testplan, indien noodzakelijk omgezet in een detailspecificatie.

9.3.4 Activiteiten Binnen de fase Voorbereiding worden de volgende activiteiten onderkend: 1. detail intake testbasis 2. definiëren testeenheden 3. toewijzen testtechnieken 4. specificeren infrastructuur. Het volgende schema geeft de volgorde en de afhankelijkheden aan tussen de verschillende activiteiten.

Figuur 9 Fase Voorbereiding

9.4 Fase Specificatie 9.4.1 Inleiding Tijdens de fase Specificatie wordende testgevallen voorbereid. Daarnaast wordt gezorgd voor de realisatie van de benodigde infrastructuur.

9.4.2 Randvoorwaarden Aan de volgende voorwaarden dient te zijn voldaan alvorens kan worden gestart met de fase Specificatie: • • • •

de testbasis dient beschikbaar en gefixeerd te zijn; de testbasisbevindingen uit de detail intake testbasis dienen te zijn verwerkt; een beschrijving van de fysieke realisatie (fysieke tabellen) is beschikbaar ten behoeve van het definiëren van de uitgangsbestanden; het opleverschema van het testobject en de infrastructuur zijn beschikbaar ten behoeve van het opstellen van het testdraaiboek.

9.4.3 Werkwijze Tijdens de specificatiefase worden de testgevallen gespecificeerd en wordt de bijbehorende infrastructuur gerealiseerd. De creatie van testgevallen vindt plaats per testeenheid aan de hand van de toegewezen testtechnieken. Op het moment dat de testbasisbevindingen uit de detail in take zijn verwerkt, worden de testgevallen afgeleid en vastgelegd in testspecificaties. Tijdens dit proces wordt ook de inhoud van de diverse initiële gegevensverzamelingen gedefinieerd. Later, als er meer bekend is over de technische realisatie, worden deze situaties in de vorm van testscripts vertaald naar (fysieke) testgevallen. Tenslotte worden de in de testspecificaties onderkende testgevallen vertaald in concrete, uitvoerbare testacties en in een uitvoerbare volgorde in de testscripts geplaatst. Ten behoeve van de testuitvoering wordt een testdraaiboek opgesteld waarin de testscripts in onderlinge samenhang zijn weergegeven. De infrastructuur, zoals beschreven in de detail specificatie infrastructuur; wordt parallel aan het creëren van de testgevallen gerealiseerd.

9.4.4 Activiteiten Binnen de fase Specificatie worden de volgende activiteiten onderkend: 1. 2. 3. 4. 5. 6.

Opstellen testspecificaties Definiëren uitgangsbestanden Opstellen testscripts Opstellen testdraaiboek Specificeren intake testobject/infrastructuur Realiseren infrastructuur.

Aangemaakt d.d.

27-12-2011

Pagina 28



Het volgende schema geeft de volgorde en de afhankelijkheden aan tussen de verschillende activiteiten: Figuur 10 Fase Specificatie

9.5 Fase Uitvoering 9.5.1 Inleiding Het doel van de fase Uitvoering is het uitvoeren van de gespecificeerde tests om inzicht te krijgen in de kwaliteit van het testobject.

9.5.2 Randvoorwaarden Aan de volgende voorwaarde dient te zijn voldaan alvorens kan worden gestart met de fase Uitvoering: • het testobject en de bijbehorende infrastructuur dienen te zijn gerealiseerd c.q. opgeleverd.

9.5.3 Werkwijze De daadwerkelijke uitvoering van de test begint op het moment dat de eerste testbare testeenheden worden opgeleverd. Eerst worden de opgeleverde testeenheden gecontroleerd op volledigheid en in de testomgeving geïnstalleerd om te kunnen beoordelen of het geheel naar behoren functioneert. De eerste test die wordt uitgevoerd is de zogenaamde pretest. In deze test wordt globaal getest, met als doel te onderzoeken of het te testen informatiesysteem in samenhang met de testinfrastructuur van voldoende kwaliteit is om uitgebreid getest te kunnen worden. Als het geheel van voldoende kwaliteit is, worden de initiële gegevensverzamelingen met hun initiële waarden gevuld. Vervolgens worden de testscripts uit het testdraaiboek uitgevoerd. Tijdens de activiteit ‘Controleren en beoordelen testresultaten’ wordt onderzocht wat de oorzaak van de eventuele verschillen is tussen de voorberekende en de verkregen testresultaten. De oorzaak kan gelegen zijn in een programmafout. Er zijn echter ook andere oorzaken mogelijk: onduidelijkheden in de testbasis, fouten in de testomgeving, maar ook fouten in de testgevallen. Na herstel van een bevinding worden de betreffende tests opnieuw uitgevoerd en beoordeeld, in principe totdat alle tests zijn uitgevoerd en er geen openstaande bevindingen meer aanwezig zijn.

9.5.4 Activiteiten Binnen de fase Uitvoering worden de volgende activiteiten onderkend: 1. 2. 3. 4. 5.

Intake testobject/infrastructuur Vullen uitgangsbestanden Uitvoeren (her) tests Controleren en beoordelen testresultaten Onderhouden testdraaiboek.

Het volgende schema geeft de volgorde en de afhankelijkheden aan tussen de verschillende activiteiten.

Figuur 11Fase Uitvoering

9.6 Fase Afronding 9.6.1 Inleiding Het doel van de fase Afronding valt in een aantal delen uiteen, namelijk: • • •

het conserveren van de testware zodat deze kan worden hergebruikt bij een volgende test; het verkrijgen van ervaringscijfers ten behoeve van een betere beheersing van de toekomstige testtrajecten; het opstellen van een eindrapport zodat de opdrachtgever wordt geïnformeerd over het verloop van de test en décharge kan worden verleend aan het testteam.

Aangemaakt d.d.

27-12-2011

Pagina 29



9.6.2 Randvoorwaarden Aan de volgende voorwaarde dient te zijn voldaan alvorens kan worden gestart met de fase Afronding: • de testuitvoering is afgerond; er is besloten geen (her) tests meer uit te voeren.

9.6.3 Werkwijze Er wordt een selectie gemaakt van de vaak grote hoeveelheid testware, zoals de testgevallen, de testresultaten, de beschrijvingen van de infrastructuur en de gebruikte tools. De testware wordt vervolgens geconserveerd met als doelstelling dat bij wijzigingen en de bijbehorende onderhoudstests de testware alleen maar aanpassing behoeft en er dus niet compleet nieuwe tests moeten worden ontworpen. Tijdens het testproces is getracht de testgevallen in overeenstemming te houden met de specificaties en het ontwikkelde systeem. Als dit is gelukt mag men spreken van zogenaamde regressieve testware. Het is de bedoeling dat tijdens de onderhoudsfase deze regressiviteit bewaard blijft. Tijdens de fase Afronding wordt het testproces geëvalueerd. Onderwerp van evaluatie is niet alleen het testproces maar ook de produktkwaliteit. Het is aan te bevelen ook een kosten/baten verantwoording van het testproces op te stellen, een lastige maar tevens zeer boeiende en vooral leerzame activiteit. Het vaak grote aantal statistieken dat beschikbaar komt, is onmisbaar voor het plannen van toekomstige testprocessen, systeemontwikkelingsprocessen en het inrichten van kwaliteitssystemen. Na de conservering, de evaluatie en het aanbieden van het evaluatierapport kan de opdrachtgever aan het testteam décharge verlenen.

9.6.4 Activiteiten De fase Afronding bestaat uit de volgende activiteiten: 1. 2. 3. 4. 5.

Evaluatie testobject Evaluatie testproces Opstellen evaluatierapport Conserveren testware Décharge testteam.


Figuur 12 Fase Afronding

10. Fasering White-box testen 10.1 Inleiding White-box tests worden meestal uitgevoerd door de ontwikkelaars. Vanaf het ontstaan van de eerste bouwstenen van het systeem worden er programmatests uitgevoerd. Het is afhankelijk van de gebruikte ontwikkelomgeving in welke mate er sprake is van afzonderlijke tests voor programma’s. Gecontroleerd moet worden of de meest elementaire delen of verzamelingen daarvan zijn gecodeerd conform de technische specificaties. Nadat is vastgesteld dat de meest elementaire delen van het systeem van goede kwaliteit zijn, worden tijdens de integratietest grotere delen van het systeem integraal getest. Hierbij ligt de nadruk op de gegevensdoorvoer en de interface werking. De integratietest is als het ware een soort assemblage test. In tegenstelling tot de black-box tests, maken de white-box tests veelal integraal onderdeel uit van het systeemontwikkelingsproces. De fasering van de testactiviteiten moet dan ook, meer dan bij de black-box tests, worden verweven en geïntegreerd met de activiteiten van systeemontwikkeling.

10.2 Fase Planning en beheer 10.2.1 Inleiding In een testplan wordt vastgelegd hoe, door wie, waarmee en wanneer de testactiviteiten uitgevoerd gaan worden. Daarna zijn de activiteiten gericht op de coördinatie, de bewaking en het beheer van het testproces en Aangemaakt d.d.

27-12-2011

Pagina 30



het verschaffen van inzicht in de kwaliteit van het testobject. Door middel van periodieke rapportages wordt de opdrachtgever geïnformeerd.

10.2.2 Randvoorwaarden Aan de volgende voorwaarden dient te zijn voldaan alvorens kan worden gestart met de fase ‘Planning en beheer’: • • • • • •

een ingerichte Organisatie voor het systeemontwikkelingsproces; de functioneel ontwerp-fase dient te zijn afgerond, en de technische specificaties zijn reeds in een vergevorderd stadium; in die gevallen waar voor het totale testproces een mastertestplan is opgesteld, moet dat zijn gefixeerd; inzicht in de (oplever) planning van het systeemontwikkelingsproces; inzicht in de technische systeemarchitectuur en ontwikkelomgeving; inzicht in de werkwijze met betrekking tot het opstellen van de ontwerpdo cumentatie (systeemontwikkelmethode).

10.2.3 Werkwijze De fase ‘Planning en beheer’ start voor de integratietest tijdens de fase technisch-ontwerp en start voor de programmatest tijdens het programma-ontwerp. Door middel van het testplan wordt het fundament gelegd voor een gestructureerd testproces. De planning voor zowel de programmatest als de integratietest moeten worden geïntegreerd in de totale planning voor de realisatie van het informatiesysteem. Deze activiteiten maken hiervan immers integraal deel uit! Na het vaststellen van de testopdracht wordt door middel van de teststrategie bepaald hoe en met welke diepgang de white-box tests worden uitgevoerd. Daarnaast wordt een aanzet gegeven tot de inrichting van de Organisatie, de (op te leveren) testprodukten, de infrastructuur en het beheer; tevens wordt de planning opgesteld Op basis van de resultaten van deze activiteiten wordt een testplan samengesteld en gefixeerd. De overige activiteiten van deze fase worden gedurende het hele testproces uitgevoerd en zijn gericht op de coördinatie, de bewaking en liet beheer van het testproces en het verschaffen van inzicht in de kwaliteit van het testobject. Conform de in het testplan vastgelegde vorm en frequentie wordt over de voortgang van het testproces en de kwaliteit van het testobject gerapporteerd aan de opdrachtgever.

10.2.4 Activiteiten De fase Planning en beheer bestaat uit de volgende activiteiten in het kader van het opstellen van het testplan: 1. Opdrachtformulering 2. Vaststellen testbasis 3. Bepalen teststrategie 4. Inrichten Organisatie 5. Inrichten testprodukten 6. Definiëren infrastructuur 7. Inrichten beheer 8. Bepalen planning 9. Fixeren testplan. De volgende activiteiten worden onderkend in het kader van de coördinatie, de bewaking en het beheer van het testproces: 10. Onderhouden testplan 11. Uitvoeren beheer 12. Rapporteren. Onderstaand schema geeft de volgorde en de afhankelijkheden aan tussen de verschillende activiteiten.

Figuur 13 Fase Planning en beheer

Aangemaakt d.d.

27-12-2011

Pagina 31



10.3 Fase Voorbereiding 10.3.1 Inleiding Het doel van de fase Voorbereiding is het vaststellen of de testbasis voldoende kwaliteit bevat voor het specificeren en uitvoeren van de testgevallen (testbaarheid).

10.3.2 Randvoorwaarden Aan de volgende voorwaarde dient te zijn voldaan alvorens kan worden gestart met de fase Voorbereiding: • de testbasis dient beschikbaar en gefixeerd te zijn.

10.3.3 Werkwijze Nadat de testbasis beschikbaar is gesteld, wordt gestart met de detail in take van de testbasis. Er wordt inzicht in de testbaarheid verkregen door de testbasis te beoordelen op bijvoorbeeld uniforme notatie, consistentie en volledigheid. In de testbasis is de technische oplossing voor de realisatie van het informatiesysteem beschreven. Door middel van de white-box tests dient te worden vastgesteld of het systeem conform de technische specificaties functioneert.

10.3.4 Activiteiten De fase Voorbereiding bestaat voor de white-box tests uit één activiteit: Detail intake testbasis.

10.4 Fase Specificatie 10.4.1 Inleiding Tijdens de fase Specificatie worden per programma respectievelijk integratiestap de testgevallen voorbereid. Daarnaast wordt gezorgd voor het realiseren van de benodigde infrastructuur.

10.4.2 Randvoorwaarden Aan de volgende voorwaarden dient te zijn voldaan alvorens kan worden gestart met de fase Specificatie: • • • •

de testbasis dient beschikbaar en gefixeerd te zijn; de testbasisbevindingen uit de detail in take testbasis dienen te zijn verwerkt; een beschrijving van de fysieke realisatie (fysieke tabellen) is beschikbaar ten behoeve van het definiëren van de uitgangsbestanden; het opleverschema van het testobject en de infrastructuur is beschikbaar ten behoeve van het opstellen van het testdraaiboek.

10.4.3 Werkwijze Tijdens de specificatiefase worden de testgevallen gespecificeerd en wordt de bijbehorende infrastructuur gerealiseerd. De creatie van testgevallen vindt plaats per programma respectievelijk integratiestap met behulp van de geselecteerde testspecificatietechnieken. Op het moment dat de testbasisbevindingen uit de detail in take zijn verwerkt, worden de testgevallen afgeleid en vastgelegd in testspecificaties. Tijdens dit proces wordt ook de inhoud van de diverse initiële gegevensverzamelingen gedefinieerd. Tenslotte worden de in de testspecificaties onderkende testgevallen vertaald in concrete, uitvoerbare testacties en in een uitvoerbare volgorde geplaatst in de testscripts. Ten behoeve van een integratietest wordt een testdraaiboek vervaardigd op basis van o.a. de integratiestrategie. De infrastructuur, zoals beschreven in het testplan, wordt parallel aan het creëren van de testgevallen gerealiseerd.

10.4.4 Activiteiten Binnen de fase Specificatie worden de volgende activiteiten onderkend: 1. 2. 3. 4. 5.

Opstellen testspecificaties Definiëren uitgangsbestanden Opstellen testscripts Opstellen testdraaiboek Realisatie infrastructuur.

Aangemaakt d.d.

27-12-2011

Pagina 32




Figuur 14 Fase Specificatie

10.5 Fase Uitvoering 10.5.1 Inleiding Het doel van de fase Uitvoering is het uitvoeren van de gespecificeerde tests om inzicht te krijgen in de kwaliteit van het testobject.

10.5.2 Randvoorwaarden Aan de volgende voorwaarde dient te zijn voldaan alvorens kan worden gestart met de fase Uitvoering: • het testobject en de bijbehorende infrastructuur dienen te zijn gerealiseerd c.q. opgeleverd.

10.5.3 Werkwijze De fase Uitvoering start op het moment dat de testomgeving is gerealiseerd, de testtools beschikbaar zijn en het testobject is opgeleverd. Eerst worden de uitgangsbestanden gevuld met de gespecificeerde initièle gegevensverzamelingen. Vervolgens worden de testscripts conform de in het testdraaiboek vastgestelde volgorde uitgevoerd. Tijdens het beoordelen van de testresultaten worden de eventuele verschillen tussen de voorspelde resultaten en de daadwerkelijke resultaten onderzocht. De oorzaak kan gelegen zijn in een programmafout. Er zijn echter ook andere oorzaken mogelijk: onduidelijkheden in de testbasis, fouten in de testomgeving, maar ook fouten in de testgevallen. Na herstel van een bevinding worden de betreffende tests opnieuw uitgevoerd en beoordeeld. In principe totdat alle tests zijn uitgevoerd en geen openstaande bevindingen meer aanwezig zijn.

10.5.4 Activiteiten Binnen de fase Uitvoering worden de volgende activiteiten onderkend: 1. 2. 3. 4. 5.

Vullen uitgangsbestanden Vervaardigen hulpprogrammatuur Uitvoeren (her)tests Controleren en beoordelen testresultaten Onderhouden testdraaiboek

Het volgende schema geeft de volgorde en de afhankelijkheden aan tussen de verschillende activiteiten. Figuur 15 Fase Uitvoering

10.6 Fase Afronding 10.6.1 Inleiding Het doel van de fase Afronding valt in een aantal delen uiteen, namelijk: • •

het conserveren van de testware, zodat deze kan worden hergebruikt bij een volgende test; het opstellen van een evaluatierapport en het verkrijgen van ervaringscijfers ten behoeve van een betere beheersing van de toekomstige testtrajecten.

10.6.2 Randvoorwaarden Aan de volgende voorwaarde dient te zijn voldaan alvorens kan worden gestart met de fase Afronding: • de testuitvoering is voor de betreffende testsoort afgerond; er is besloten geen (her) tests meer uit te voeren. Aangemaakt d.d.

27-12-2011

Pagina 33



10.6.3 Werkwijze Er wordt een selectie gemaakt van de vaak grote hoeveelheid testware, zoals de testgevallen, de testresultaten, de beschrijvingen van de testomgeving en (le gebruikte tools. De testware wordt vervolgens geconserveerd met als doelstelling dat bij wijzigingen en de bijbehorende onderhoudstests de testware alleen maar aanpassing behoeft en er dus niet compleet opnieuw moet worden ontworpen. Tijdens het testproces is getracht de testgevallen in overeenstemming te houden met de ontwerp-specificaties en het ontwikkelde systeem. Als dit is gelukt mag men spreken van zogenaamde regressieve testware. Het is uiteraard de bedoeling dat tijdens de onderhoudsfase deze regressiviteit bewaard blijft. Tijdens de afrondingsfase wordt tevens het testproces geëvalueerd. Onderwerp van evaluatie is niet alleen het testproces, maar ook de produktkwaliteit. Het vaak grote aantal statistieken dat beschikbaar komt, is onmisbaar voor het plannen van toekomstige testprocessen, systemen ontwikkelingsprocessen en het inrichten van kwaliteitssystemen.

10.6.4 Activiteiten De fase Afronding bestaat uit de volgende activiteiten: 1. evaluatie testproces 2. conserveren testware. Onderstaand schema geeft de volgorde en de afhankelijkheden aan tussen de verschillende activiteiten:

Figuur 16 Fase Afronding

Aangemaakt d.d.

27-12-2011

Pagina 34



Deel III: Technieken 11. Inleiding technieken 11.1 De pijlers Zoals reeds eerder is aangegeven zijn de vier pijlers onder een gestructureerde testaanpak een aan de ontwikkelingscyclus gerelateerde: • • • •

fasering van de testactiviteiten, een goede organisatorische inbedding, de juiste infrastructuur en tools en bruikbare technieken ter uitvoering van de activiteiten.

11.2 Fase Planning en beheer Ter ondersteuning van deze fase is een tweetal technieken beschikbaar: 1. strategiebepaling en 2. testpuntanalyse. (TPA) Bij het opstellen van het testplan kunnen de volgende checklists behulpzaam zijn: 1. 2. 3. 4.

Globale bestudering informatiesysteem, Randvoorwaarden en uitgangspunten, Risico’s testproject en Testfaciliteiten.

11.3 Fase Voorbereiding De testbasis wordt gevormd door de documentatie op basis waarvan de tests worden voorbereid en gespecificeerd. Voor het uitvoeren van de intake is een tweetal technieken beschikbaar, namelijk: 1. detail intake testbasis en 2. Fagan inspection.

11.4 Fase Specificatie Wellicht de belangrijkste technieken, zijn de technieken waarmee op een eenduidige en reproduceerbare wijze testgevallen worden afgeleid uit de testbasis, de zogenaamde specificatietechnieken. Op basis van “uitgangsinformatie” moeten testgevallen worden bepaald. Een testgeval bestaat uit: • • •

een uitgangssituatie, een veranderingsproces en een resultaatvoorspelling.

Een testgeval test één of meer kwaliteitsaspecten van één of meer functies van het te testen informatiesysteem. Voor het afleiden van de testgevallen uit de uitgangsinformatie worden testspecificatietechnieken gebruikt. Voor het testen van diverse kwaliteitsaspecten binnen de onderscheiden testsoorten is een veelheid aan de testspecificatietechnieken beschikbaar.

11.5 Fase Uitvoering Ten behoeve van de indirect meetbare kwaliteitsattributen, de kwaliteitsattributen die worden beoordeeld d.m.v. statisch testen, zijn checklists beschikbaar. Tevens is een checklist gebruikersvriendelijkheid opgenomen die kan worden gebruikt tijdens het dynamisch impliciet testen van gebruikersvriendelijkheid en een checklist Vrijgave produktie voor een ‘definitief’ vrijgaveadvies.

Aangemaakt d.d.

27-12-2011

Pagina 35



11.6 Fase Afronding Ter ondersteuning van het opstellen van een eindrapport en het evalueren van het testproject is een tweetal checklists beschikbaar, te weten: 1. checklist Evaluatie testproject en 2. checklist Testmetrieken testproces.

12. Strategiebepaling 12.1 Inleiding De strategie geeft aan op welke wijze getest gaat worden. Om optimaal gebruik te maken van de beschikbare mensencapaciteit en tijd wordt bepaald op welke systeemdelen en aspecten de nadruk dient te liggen. De strategie is een belangrijke basis voor een gestructureerd testaanpak en draagt in belangrijke mate bij tot een beheersbaar proces. De strategie moet er zich op richten het totale gewicht van de niet gevonden fouten te optimaliseren: de testinspanning dient zodanig te worden georganiseerd en verdeeld dat het vinden van de volgende fout meer kost dan het optreden van die fout in produktie. De basis van de strategie wordt gevormd door een risicotaxatie. Hierbij worden de risico’s getaxeerd van de gevolgen van fouten, die bij het in produktie gaan niet zijn gevonden en in produktie wel optreden. Door de complexiteit van de materie is het niet mogelijk deze risicotaxatie volledig objectief en gedetailleerd uit te voeren: het zijn globale inschattingen. Het is daarom van belang dat de verschillende betrokkenen, zoals de opdrachtgever, de gebruiker, het bouwteam, enz., daaraan een bijdrage leveren. De taxatie richt zich op: • het (relatieve) belang van de verschillende systeemdelen. • het (relatieve) belang van de verschillende kwaliteitsattributen.

12.2 Kwaliteitsattributen 12.2.1 Dynamische kwaliteitsattributen Hierbij gaat het om het functioneren van het informatiesysteem gezien vanuit het standpunt van de gebruiker ofwel aspecten die van belang zijn voor de gebruiker. Onderstaande aspecten (kwaliteitsattributen) worden meestal dynamisch getest: • Beveiliging: zekerheid dat raadpleging of mutatie van gegevens uitsluitend mogelijk is door daartoe bevoegden. •

Bruikbaarheid: • mate waarin het informatiesysteem is toegesneden op de organisatie en het profiel van de eindgebruikers en • mate waarin het informatiesysteem bijdraagt aan het bereiken van de bedrijfsdoelstellingen.

•

Continuïteit: onderverdeeld in: • bedrijfszekerheid: mate waarin gegevensverwerking vrij blijft van storingen • robuustheid: mate waarin de informatievoorziening ook na een storing door kan gaan • herstelbaarheid: gemak en snelheid waarmee de informatievoorziening na een storing hersteld kan worden • degradatiemogelijkheid: gemak waarmee de kern van informatievoorziening kan worden voortgezet nadat een deel is uitgevallen • uitwijkmogelijkheid: gemak waarmee de informatievoorziening op een andere locatie kan worden voortgezet

•

Controleerbaarheid: gemak waarmee de juistheid en volledigheid van informatie gecontroleerd kan worden.

Aangemaakt d.d.

27-12-2011

Pagina 36



•

Functionaliteit: zekerheid dat de verwerking van gegevens juist en volledig geschiedt, conform de functionele specificaties.

•

Gebruiksvriendelijkheid: het bedieningsgemak voor de eindgebruikers.

•

Inpasbaarheid: • mate waarin handmatige procedures aansluiten op het geautomatiseerde informatiesysteem • werkbaarheid van deze handmatige procedures voor de organisatie

•

Performance: snelheid waarmee het informatiesysteem interactieve en batch-transacties afhandelt.

•

Zuinigheid: verhouding tussen prestatieniveau van het systeem en de hoeveelheid resources die daarvoor gebruikt worden.

12.2.2 Statische kwaliteitsattributen Hierbij gaat het om de intrinsieke eigenschappen van het informatiesysteem en de documentatie gezien vanuit het standpunt van de ontwikkelaar en van de toekomstige beheerder. De volgende attributen worden meestal statisch getest: • Beheerbaarheid: het gemak waarmee het informatiesysteem in operationele staat kan worden gebracht en gehouden. •

Connectiviteit: gemak waarmee een koppeling met een ander informatiesysteem of binnen het informatiesysteem tot stand kan worden gebracht en kan worden gewijzigd.

•

(Geschiktheid) Infrastructuur: geschiktheid van de infrastructuur en de mate waarin element op elkaar aansluiten.

•

Flexibiliteit: mate waarin de gebruiker zelf uitbreidingen of variaties op het systeem kan aanbrengen zonder dat de programmatuur wordt aangepast.

•

Herbruikbaarheid: mate waarin delen van het systeem, of van het ontwerp, opnieuw gebruikt kunnen worden voor de ontwikkeling van andere toepassingen.

•

Onderhoudbaarheid: gemak waarmee het systeem kan worden aangepast aan nieuwe wensen, veranderende omgeving of om fouten te herstellen.

•

Portabiliteit: • diversiteit van het hardware- en software-platform waarin het systeem kan draaien en • gemak waarmee het systeem kan worden overgebracht van de ene naar een andere omgeving.

•

Testbaarheid: gemak en snelheid waarmee de functionaliteit en het prestatieniveau van het systeem getest kan worden.

12.3 Werkwijze Het bepalen van een teststrategie is niet iets dat zuiver methodisch kan gebeuren. De stappen die hierna zijn beschreven zijn hulpmiddelen en geven de richting aan. Ervaring en kennis van de uitvoerder van deze activiteit met betrekking tot het testen is een belangrijke succesfactor voor een goede strategiebepaling.

12.3.1 Strategiebepaling Mastertestplan De stappen die ondernomen moeten worden om tot een teststrategie, in het kader van een mastertestplan, te komen zijn: • Bepalen van de kwaliteitsattributen: In overleg met de opdrachtgever en indien mogelijk met andere betrokkenen worden de kwaliteitsattributen vastgesteld waarop de test dient te zijn gebaseerd. •

Bepalen relatief belang kwaliteitsattributen: Op basis van de resultaten uit stap 1 dient te worden aangegeven hoe de testinspanning zou moeten verdeeld over de geselecteerde kwaliteitsattributen met als uitgangspunt dat het testen van ieder kwaliteitsattribuut even tijdsintensief is. Dit gebeurt door in een gewichtenmatrix het relatieve belang (in %)

Aangemaakt d.d.

27-12-2011

Pagina 37



aan te geven met betrekking tot de geselecteerde kwaliteitsattributen. •

Toewijzen kwaliteitsattributen testsoorten: Met als doelstelling de totale testinspanning zo efficiënt te benutten, wordt tijdens het opstellen van de teststrategie aangegeven m.b.v. welke testsoort(en) de diverse geselecteerde kwaliteitsattributen worden getest. Door middel van “+”, “++”, “+++”-tekens wordt in de matrix aangegeven of een bepaald kwaliteitsattribuut onderdeel uitmaakt van de teststrategie van een bepaalde testsoort

Aangemaakt d.d.

27-12-2011

Pagina 38



Voorbeeld van een strategiematrix van testsoorten: Programma Integratie test test Beheerbaarheid Beveiliging Bruikbaarheid Connectiviteit + Continuïteit Controleerbaarheid Flexibiliteit Functionaliteit + + Gebruikersvriendelijkhei d Herbruikbaarheid Infrastructuur Inpasbaarheid Onderhoudbaarheid Performance Portabiliteit Testbaarheid Zuinigheid

Systeem Functionele Produktie Relatief test Acceptatietest Acceptatietest belang ++ 5 + ++ 5 ++ 10 +++ + 35 ++ 5 5 10 15 5 5 100%

+ ++ + +

++

+

++

+

12.3.2 Strategiebepaling Testsoort De strategiebepaling voor een specifieke testsoort heeft uiteraard de eventueel aanwezige startegiebepaling uit het mastertestplan als randvoorwaarde en startpositie. De stappen die ondernomen moeten worden om te komen tot een teststrategie voor een specifieke testsoort zijn: • Bepalen kwaliteitsattributen (zie paragraaf 12.3.1) •

Bepalen relatief belang kwaliteitsattributen (zie paragraaf 12.3.2)

•

Onderverdelen in deelsystemen: Tijdens deze en de volgende stap wordt de teststrategie verder verfijnd. Dit betekent dat de kwaliteitsattributen en het relatieve belang uit de voorafgaande gewichtenmatrix moeten worden verdeeld tot op de combinaties testtechnieken/deelsystemen en later zelfs testtechnieken/testeenheid.

•

Bepalen relatief belang deelsystemen: Op basis van het resultaat uit de vorige stap moet nu worden aangegeven hoe de testinspanning verdeeld wordt. Dit gebeurt door in de gewichtenmatrix het relatieve belang aan te geven m.b.t. de onderkende deelsystemen. Per deelsysteem wordt bepaald wat het relatieve belang is binnen het informatiesysteem.

Beveiliging Bruikbaarheid Continuïteit Controleerbaarheid Functionaliteit Gebruikersvriendelijkhe id Performance Inpasbaarheid Zuinigheid Relatief belang

Aangemaakt d.d.

Deelsystee m1 ++

27-12-2011

Deelsystee m2 +

Deelsystee m3 +

Conversie

Totaal systeem

+ ++ ++

+ +

+

+ +

+ +

+

35

30

20

++

5

+

10

Relatief belang 10 5 50 10 5 20 100%

Pagina 39



Bepalen te gebruiken testtechnieken: Als laatste stap binnen de teststrategie dienen testtechnieken te worden geselecteerd waarmee de geselecteerde kwaliteitsattributen getest gaan worden. Er zijn drie vormen van testtechnieken: • dynamisch expliciet testen: testen d.m.v. gerichte invoer (testgevallen); • dynamisch impliciet testen: testen d.m.v. het opbouwen van statistieken tijdens het ontwikkelen testproces; • statisch testen: testen d.m.v. een beoordeling van de genomen maatregelen op basis van een checklist. Testtechnieken Kwaliteitsattribuut AGT BTT BS CKL DIT DFT EVT EG PIT PCT RLT SEM STAT SYN Beheerbaarheid X Beveiliging X X X X X Bruikbaarheid X X Connectiviteit X Continuïteit X X X Controleerbaarheid X X X X X Flexibiliteit X Functionaliteit X X X X X X X X Gebruikersvriendelijkheid X X X X X X X Herbruikbaarheid X Infrastructuur X X Inpasbaarheid X X X Onderhoudbaarheid X X X Performance X X X Portabiliteit X Testbaarheid X X Zuinigheid X X X Toelichting gebruikte afkortingen: AGT : Algoritmetest BTT : Beslissingstabellentest BS : Bedrijfssimulatie CKL : Beoordelen door middel van een Checklist DFT : Dataflowtest DIT : Detail Intake Testbasis EG : Error Guessing EVT : Elementaire vergelijkingstest PCT : Procescyclustest PIT : Programma Interface Test RLT : Real-life test SEM : Semantische test STAT: Beoordelen door middel van het opbouwen van statistieken SYN : Syntactische test

13. Testpuntanalyse 13.1 Inleiding Met behulp van Testpuntanalyse na op een objectieve wijze een begroting worden gemaakt voor een systeemtest of een acceptatietest. De scope van testpuntanalyse beperkt zich tot het zogenaamde black-box testen. De begroting van de voorliggende testactiviteiten (white-box tests) is reeds opgenomen in de begroting die voorkomt uit functiepuntanalyse. De produktiviteitsfactor omvat bij functiepuntanalyse dus wel de white-box tests, maar niet de black-box tests, systeemtest en acceptatietest. Testpuntanalyse kan tevens worden toegepast indien het aantal te besteden testuren van tevoren reeds is vastgesteld. Door het uitvoeren van een Testpuntanalyse kunnen de eventuele risico’s die worden gelopen duidelijk worden aangetoond door de objectieve testpuntanalyse-begroting te vergelijken met het van tevoren vastgestelde aantal testuren. Aangemaakt d.d.

27-12-2011

Pagina 40



Tevens is het mogelijk met behulp van Testpuntanalyse het relatieve belang tussen de diverse functies te bepalen c.q. te herkennen, op basis waarvan de beschikbare testtijd zo optimaal mogelijk kan worden besteed.

13.2 Filosofie Drie aspecten spelen een rol: 1. De omvang van het informatiesysteem 2. De teststrategie 3. De produktiviteit De eerste twee aspecten bepalen samen de omvang van de uit te voeren test (in testpunten). Vermenigvuldiging hiervan met de produktiviteit (de hoeveelheid tijd nodig voor het uitvoeren van een test) levert een testbegroting in uren.

13.2.1 Omvang De omvang is met name gebaseerd op het aantal functiepunten. Echter de volgende factoren moeten daaraan worden toegevoegd: •

Complexiteit: Hoeveel condities zijn er aanwezig in een functie. Meer condities betekent vrijwel automatisch meer testgevallen en dus meer testinspanning.

•

Systeemdoorverwerking: Hoeveel gegevensverzamelingen worden door de functie onderhouden en hoeveel andere functies maken hiervan gebruik. De andere functies dienen tevens te worden getest indien deze onderhoudsfunctie wordt aangepast.

•

Uniformiteit: Is de structuur van een functie van dien aard dat reeds bestaande testspecificaties met slechts een geringe aanpassing hergebruikt kunnen worden. Met andere woorden bestaan binnen het informatiesysteem meerdere functies met dezelfde structuur.

13.2.2 Teststrategie De teststrategie geeft aan: • welke kwaliteitsattributen moeten worden getest in combinatie met • welke deelsystemen c.q. functies en met • welke diepgang. Testpuntanalyse en teststrategie zijn nauw met elkaar verbonden en worden in de praktijk veelal grotendeels gelijktijdig uitgevoerd.

13.2.3 Produktiviteit De produktiviteit legt bij functiepuntanalyse de relatie tussen inspanningsuren en het gemeten aantal functiepunten. Voor Testpuntanalyse betekent produktiviteit de tijd die nodig is om een testpunt, bepaald door de omvang van het informatiesysteem en de teststrategie, te realiseren. De produktiviteit is opgebouwd uit twee onderdelen: het produktiviteitscijfer en de omgevingsfactor. Het produktiviteitscijfer is gebaseerd op de kennis en kunde van het testteam en daardoor specifiek voor de organisatie. De omgevingsfactor geeft aan in welke mate de omgeving van invloed is op de testactiviteiten waaraan de produktiviteit is gerelateerd. Het gaat hierbij om aspecten zoals de beschikbaarheid van testtools, de ervaring met de betreffende testomgeving, de kwaliteit van de testbasis en de beschikbaarheid van de testware.

Aangemaakt d.d.

27-12-2011

Pagina 41



13.3 Globale werking De werking van testpuntanalyse is schematisch als volgt weer te geven: Figuur 17 Schematische w eergave Testpuntanalyse

13.4 Uitgangspunten •

Testpuntanalyse beperkt zich tot de kwaliteitsattributen die tot de scope van een acceptatietest en of systeemtest behoren en bovendien meetbaar zijn.

•

Meetbaar betekent in deze dat voor het betreffende kwaliteitsattribuut binnen TMap een testtechniek beschikbaar is. Tevens dient met betrekking tot deze testtechniek in relatie tot het betreffende kwaliteitsattribuut voldoende praktijkervaring te zijn opgedaan om concrete uitspraken te kunnen doen over de benodigde tijd.

•

In relatie tot het voorgaande uitgangspunt kan worden vastgesteld dat niet alle mogelijke kwaliteitsattributen die kunnen voorkomen bij een acceptatietest en of systeemtest zijn opgenomen in de huidige versie van testpuntanalyse. Dit heeft als reden dat er (nog) geen concrete testtechniek beschikbaar is of dat met een beschikbare testtechniek nog te weinig praktijkervaring is opgedaan.

•

Testpuntanalyse is in beginsel persoonsonafhankelijk. Met andere woorden verschillende personen die een testpuntanalyse uitvoeren op hetzelfde informatiesysteem moeten in principe tot dezelfde begroting komen. Dit wordt bereikt door alle factoren die niet objectief zijn te classificeren door de opdrachtgever te laten bepalen en voor alle factoren waarvoor dat wel mogelijk is een eenduidige klasse-indeling te hanteren.

•

Testpuntanalyse kan worden uitgevoerd als er een functiepuntentelling conform Nefpug, Ifpug of IFPA beschikbaar is. Ingeval van Nefpug of Ifpug worden de bruto functiepunten als uitgangspunt genomen.

•

Materiekennis wordt binnen testpuntanalyse niet gezien als een factor die van invloed is op de benodigde testinspanning. Het is uiteraard wel van belang dat een bepaalde hoeveelheid materiekennis binnen het testteam aanwezig is. Materiekennis is in deze optiek een randvoorwaarde die dient te worden ingevuld tijdens het opstellen van een testplan.

•

Binnen testpuntanalyse wordt bij het bepalen van de begroting uitgegaan van gemiddeld een algehele hertest. Dit gemiddelde is een gewogen gemiddelde op basis van omvang van de functies, uitgedrukt in testpunten.

Aangemaakt d.d.

27-12-2011

Pagina 42



13.5 TPA, de techniek in detail 13.5.1 Invoer en startvoorwaarden Om een testpuntanalyse uit te kunnen voeren, dient men te beschikken over: • een functioneel ontwerp: Dit functioneel ontwerp dient gedetailleerde procesbeschrijvingen alsmede een logisch datamodel te omvatten. •

een functiepunttelling. Als er geen functiepunttelling aanwezig is en het wenselijk is deze alsnog uit te voeren, kan voor het bepalen van de benodigde tijd voor het uitvoeren van de functiepunttelling de volgende richtlijnen worden gehanteerd: • tel het aantal logische gegevensverzamelingen en vermenigvuldig dit met 30; • deel de uitkomst door 400 om het aantal dagen benodigd om de fucntiepunten te tellen te verkrijgen.

13.5.2 Directe testpunten (TPf) Het aantal directe testpunten is een optelling van het aantal testpunten per functie. Voor het berekenen van het aantal testpunten per functie zijn de beïnvloedingsvariabelen c.q. -factoren in twee categoriën ingedeeld.

13.5.2.1 Functie-afhanklijke factoren (Af)

Gebruikersbelang (Gb): Is het relatieve belang dat de gebruiker aan een bepaalde functie hecht in relatie tot de overige binnen het systeem aanwezige functies. •

Weging: belang betreffende functie t.o.v. overige functie: - laag :3 - neutraal :6 (nominale waarde) - hoog : 12

Systeemdoorwerking (Sd): Is de mate waarin een mutatie die plaatsvindt binnen de betreffende functie doorwerkt in het systeem. De mate van doorwerking wordt bepaald door: 1. logische gegevensverzamelingen (LGV’s) waarop de betreffende functie mutaties kan uitvoeren te bepalen 2. het aantal andere functies (binnen de systeemgrenzen) te bepalen die de betreffende LGV benaderen •

De waardering vindt plaats m.b.v. een matrix waarbij: • verticaal : het aantal LGV’s is aangegeven dat gemuteerd wordt door de functie • horizontaal : het aantal andere functies dat de betreffende LGV benaderd

Indien een functie geen LGV muteert, valt deze functie in de categorie lage doorwerking •

Weging: de functie heeft een: - lage doorwerking :2 - gemiddelde doorwerking :4 - hoge doorwerking :8

(nominale waarde)

Complexiteit ( C ): De Complexiteit wordt bepaald door het aantal verwerkingscondities binnen het algoritme van de betreffende functie vast te stellen (condities die het gevolg zijn database-controles niet meetellen). Enkele regels: • samengestelde condities (IF a AND b THEN) dienen dubbel geteld te worden (2 x een IF statements); • CASE-statements met “n” cases dienen als “n-1” geteld te worden (“n-1” IF statements). • Samengevat: Tel de enkelvoudige condities; niet de operatoren. •

Weging: aantal condities binnen de functie aanwezig: -≤5 :3

Aangemaakt d.d.

27-12-2011

Pagina 43

Uittreksel Titel: Testen volgens TMap - ≥ 6; ≤ 11 - ≥ 11

Aangemaakt d.d.

:6 : 12


(nominale waarde)

27-12-2011

Pagina 44



Uniformiteit (U): Drietal situaties waarbij een functie slechts voor 60% meegeteld dient te worden: 1. bij een tweede voorkomen van een bijna unieke functie; 2. bij klonen; 3. bij dummies, als er al testspecificaties zijn opgesteld. Als aan één van deze voorwaarden voldaan is krijgt de factor uniformiteit de waarde 0,6 en anders waarde 1.

Berekeningswijze voor de factor (Af):

Af = ( ( Gb + Sd + C ) / 16) * U

Standaard functies: Indien binnen de functiepuntentelling de volgende functies voorkomen dienen deze als volgt gewaardeerd te worden: Functie FP’en Gb Sd C U Af Foutmeldingen 4 6 4 3 1 0,81 Helpschermen 4 6 4 3 1 0,81 Menustructuur 4 6 4 3 1 0,81

13.5.2.2 Direct meetbare kwaliteitsattributen (Qd) Hierbij wordt onderscheid gemaakt tussen: •

direct expliciet meetbare kwaliteitsattributen, te weten: 1. functionaliteit 2. beveiliging 3. inpasbaarheid 4. performance

•

Waardering: 0 : niet van belang, wordt derhalve niet gemeten. 3 : lage kwaliteitseisen, er dient in de test wel aandacht aan besteed te worden. 4 : normale kwaliteitseisen (informatiesysteem heeft betrekking op ondersteunend proces). (nominaal) 5 : hoge kwaliteitseisen (informatiesysteem heeft betrekking op primaire proces). 6 : extreem hoge kwaliteitseisen.

•

Weging per kwaliteitsattribuut: 1. Functionaliteit : 0,75 2. Beveiliging : 0,05 3. Inpasbaarheid : 0,10 4. Performance : 0,10 Waardering Functionaliteit: - Verwerking

4 Dataflow

Aangemaakt d.d.

Error Guessing

27-12-2011

steekproef Semantisch & Error Guessing Semantisch steekproef gebruikersprofielen

5 Elementair vergelijk & Dataflow

6 Elementair vergelijk

Semantisch & Syntactisch Error Guessing Semantisch Beveiliging gebruikersprofielen & totale systeem Inpasbaarheid Geen formele Procescyclus testmaat Procescyclus Procescyclus testspecificaties 1 steekproef testmaat 1 testmaat 2 Performance De diepgang van Real-life test is variabel en wordt bepaald door de waardering en dus de hoeveelheid uren die als gevolg daarvan beschikbaar komen direct impliciet meetbare kwaliteitsattributen, te weten: Schermcontroles

•

3 Dataflow & Error Guessing

steekproef Semantisch & Syntactisch Semantisch gebruikersprofielen

Pagina 45


•


1. Gebruikersvriendelijkheid (weging 0,02) waardering: van belang? J /N 2. Zuinigheid (weging 0,02) waardering: van belang? J /N 3. Performance (weging 0,02) waardering: van belang? J /N 4. Onderhoudbaarheid (weging 0,04) waardering: van belang? J /N Berekeningswijze voor de factor Qd: •

per direct expliciet meetbaar kwaliteitsattribuut

•

resultaten voor de vier direct expliciet meetbar attributen bij elkaar optellen

•

Indien er voor gekozen is bepaalde direct impliciet meetbare attributen mee te nemen bij de test, dient de betreffende weging opgeteld te worden bij de bovenstaande waarde.

•

Qd = ( Qd direct expliciet meetbaar ) + (Qd direct impliciet meetbaar )

:

Qd = ( waardering / 4 ) * wegingsfactor

De factor Qd wordt in principe eenmalig berekend voor het totale systeem. Indien de strategie per deelsysteem afwijkend is, wordt de factor Qd per deelsysteem bepaald. •

Formule directe testpunten:

TPf = FPf * Af * Qd TPf FPf Af Qd

= het aantal testpunten per functie = aantal functiepunten per functie = wegingsfactor van de functie-afhanelijke factoren = wegingsfactor van de direct meetbare kwaliteitsattributen

13.5.3 Indirecte testpunten (Qi) Van de indirect meetbare kwaliteitsattributen dient te worden vastgesteld of zij al dan niet van belang zijn binnen de test. Een uitspraak over deze kwaliteitsattributen wordt gegeven door het toepassen van een checklist. Het betreft de volgende kwaliteitsattributen: • Flexibiliteit : van belang? J/N • Testbaarheid : van belang? J/N • Beveiliging : van belang? J/N • Continuïteit : van belang? J/N • Controleerbaarheid : van belang? J/N

waardering: 8 waardering: 8 waardering: 8 waardering: 8 waardering: 8

Qi wordt berekend door de afzonderlijke waarderingen bij elkaar op te tellen.

13.5.4 Totaal aantal testpunten (TP)

TP = ∑ TPf + ( FP * Qi ) / 500 TP ∑ TPf FP Qi

= het aantal testpunten voor het totale systeem = de som van het aantal testpunten per functie (directe testpunten) = aantal functiepunten van het totale systeem (of minimaal 500) = wegingsfactor van de indirect meetbare kwaliteitsattributen

13.5.5 Primaire testuren Het aantal primaire testuren is de tijd die nodig is om de testactiviteiten van de fase Voorbereiding, Specificatie, Uitvoering en Afronding van TMap uit te voeren.

13.5.5.1 Produktiefactor (P) Deze factor geeft aan hoeveel uren testen per testpunt nodig zijn. Deze factor is een maat voor de ‘kennis en kunde’ van het testteam en kan verkregen worden door een analyse van reeds gerealiseerde testprojecten. Het is noodzakelijk om te beschikken over ervaringscijfers van de gerealiseerde testprojecten.

13.5.5.2 Omgevingsfactor (O) Voor het berekenen van de omgevingsfactor zijn een aantal omgevingsvariabelen onderkend. Aangemaakt d.d.

27-12-2011

Pagina 46



Testtools: de mate waarin het testen is geautomatiseerd c.q. e mate waarin gebruik gemaakt kan worden van geautomatiseerde hulpmiddelen.

Aangemaakt d.d.

27-12-2011

Pagina 47


•

Weging: - 4 GL-taal met geïntegreerde DBMS waarin een veelheid aan constraints is vastgelegd : 2 - 4 GL-taal, eventueel in combinatie met 3 GL-taal : 4 (nominaal) - 3 GL-taal :8

Weging: - omgeving is reeds meerdere malen gebruikt voor uitvoeren van tests (nominaal) - er is een nieuwe ruimte ingericht én er is ruime ervaring met soortgelijke omgevingen : 2 - er is een nieuwe ruimte ingericht die voor de organisatie experimenteel is

:1

:4

Testware: De mate waarin tijdens het testen gebruik gemaakt kan worden van reeds aanwezig testware. •

•

Weging: vraag 1: wordt er bij de systeemontwikkeling gebruik gemaakt van een specifieke ontwikkelmethode? Vraag 2: heeft er t.a.v. alle produkten een formele controle op naleving plaastgevonden (kwaliteitsborging)? - antwoord op vraag 1 = Ja én antwoord op vraag 2 = Ja : waardering = 3 - antwoord op vraag 1 = Ja én antwoord op vraag 2 = Nee : waardering = 6 (nominale waarde) - antwoord op vraag 1 = Nee : waardering = 12

Testomgeving: De mate waarin de fysieke testomgeving beproefd is. •

•

Weging: In het kader van ontwikkeltest(s) is: - 2: een testplan aanwezig én het testteam heeft inzicht in concrete testgevallen en -resultaten - 4: een testplan aanwezig (nominale waarde) - 8: geen testplan aanwezig

Ontwikkelomgeving: Met name is hierbij van belang in hoeverre de ontwikkelomgeving reeds het maken van fouten voorkomt c.q. een bepaalde werkwijze afdwingt. •

•

:2

Testbasis: De kwaliteit van de (systeem) documentatie de uit te voeren test dient te zijn gebaseerd. •

•

Weging: - er wordt gebruik gemaakt van een query-taal én er is een tool t.b.v. ‘record & playback’ : 1 - er wordt gebruik gemaakt van een query-taal én er is geen ‘record & playback’ mogelijk (nominaal) - er zijn geen testtools aanwezig :4

Ontwikkeltest: De kwaliteit van eerder uitgevoerde test is van belang. Bij het begroten van: • een acceptatietest betreft dit een systeemtest; • een systeemtest betreft dit een white-box test. •

•


Weging: - algemene initiële gegevensverzameling én gespecificeerde testgevallen aanwezig - algemene initiële gegevensverzameling aanwezig - er is geen bruikbare testware beschikbaar

:1 :2 : 4 (nominaal)

Berekeningswijze voor factor O: • tel de waarden van de omgevingsvariabelen op • deel het resultaat door 21 (de som van nominale waarden)

13.5.5.3 Formule primaire testuren

PT = TP * P * O Aangemaakt d.d.

27-12-2011

Pagina 48

Uittreksel Titel: Testen volgens TMap PT TP P O


= het totaal aantal primaire testuren = het aantal testuren van het totale systeem = produktiviteitsfactor = omgevingsfactor

Aangemaakt d.d.

27-12-2011

Pagina 49



13.5.6 Totaal aantal testuren Aangezien in elk testproces activiteiten worden uitgevoerd die kunnen worden samengevat onder de noemer ‘planning en beheer’ dient er een opslag plaats te vinden op de primaire testuren. Standaard is dit 10%, echter in twee gevallen wordt dit percentage hoger of lager. •

Teamgrootte: •

•

:6

(nominale waarde)

Beheersinstrumenten: •

•

Weging: - het testteam bestaat uit maximaal 4 personen :3 - het testteam bestaat uit min. 5 en max. 10 personen - het testteam bestaat uit meer dan 10 personen : 12

Weging: - aanwezig zijn: geautomatiseerd tijdregistratie- én bevindingenbeheersysteem - aanwezig is: geautomatiseerd tijdregistratie óf bevindingenbeheersysteem :4 - geen (beheer) hulpmiddelen aanwezig :8

:2 (nominaal)

Berekeningswijze voor opslag (in uren): • tel de waarden (in procenten) van de beïnvloedingsfactoren bij elkaar op • vermenigvuldig de primaire testuren met het berekende percentage

13.5.7 Verdeling over de fasen TPA geeft een begroting voor het gehele testproces exclusief het opstellen van het testplan. Per TMap-fase geldt de volgende begrotingen: • “Planning en beheer” : aantal primaire testuren * opslagpercentage • “Voorbereiding” : 10% van de primaire testuren • “Specificatie” : 40% van de primaire testuren • “Uitvoering” : 45% van de primaire testuren • “Afronding” : 5% van de primaire testuren

13.6 TPA in een vroegtijdig stadium Veel al moet in een vroegtijdig stadium een projectbegroting voor het testen worden gemaakt. Het is dan niet mogelijk om factoren zoals complexiteit, doorverwerking en dergelijke te bepalen als gevolg van het ontbreken van gedetailleerde functionele specificaties. Vaak is het wel mogelijk om op basis van zeer globale specificaties een zogenaamde globale functiepuntanalyse uit te voeren en kan tevens een globale testpuntanalyse worden uitgevoerd. In het kader van een globale testpuntanalyse wordt 1 functie gedefinieerd die de omvang heeft van het totaal aantal vastgestelde (bruto) functiepunten. Alle functie-afhankelijke factoren (gebruikersbelang, complexiteit, doorverwerking en uniformiteit) krijgen in principe de neutrale waarde, waardoor A(f) de waarde 1 krijgt. Vervolgens kan een testpuntanalyse op normale wijze worden uitgevoerd. Bij het vaststellen van de omgevingsfactor zullen veelal aannames moeten worden gedaan, die tijdens de presentatie zeer duidelijk als zodanig moeten worden aangegeven.

13.7 Voorbeeldberekening volgens TPA Een uitgewerkt voorbeeld voor het berekening van de testinspanning in uren treft u aan in bijlage A.

14. Detail intake testbasis 14.1 Inleiding Tijdens de planningsfase is bepaald welke documentatie als testbasis gebruikt gaat worden. Tijdens de fase Voorbereiding wordt met behulp van de testtechniek Detail Intake Testbasis de testbaarheid van de testbasis beoordeeld. Hiermee wordt bedoeld de volledigheid, eenduidigheid en consistentie van de documentatie, waarop de test is gebaseerd. Aangemaakt d.d.

27-12-2011

Pagina 50



14.2 Werkwijze Stappen: •

Bepalen relevante documentatie: Is in principe reeds in het testplan uitgevoerd. Hier worden dan ook nog eventuele wijzigingen van de documentatie verwerkt. Daadwerkelijk verzamelen van de documentatie.

•

Opstellen checklist: Afhankelijk van de geselecteerde testspecificatietechnieken, de documentatievorm en te testen kwaliteitsattributen dient een checklist te worden opgesteld met daarin de specifieke controle-aspecten die bij de intake een rol kunnen spelen.

•

Documentatie beoordelen op testbaarheid: Op basis van de checklist wordt de documentatie beoordeeld en worden de bevindingen gedocumenteerd.

•

Rapporteren: Op basis van de individuele testbasis bevindingen wordt een rapport testbaarheid opgesteld, waarin opgenomen wordt.

•

Opdrachtformulering

•

Conclusie

•

Aanbevelingen

•

Bevindingen

•

Bijlage (de gebruikte checklist)

14.3 Checklist testspecificatietechnieken Zie bijlage B Checklists.

14.4 Checklist black-box test Zie bijlage B Checklists.

14.5 Checklist white-box test Zie bijlage B Checklists.

15. Fagan inspection 15.1 Inleiding Een goede en veel gebruikte techniek om het aspect testbaarheid van de ontwerpspecificatie te toetsen is de zogenaamde Fagan indpection. Deze inspectietechniek behelst feitelijk het in teamverband beoordelen van een (tussen) produkt door middel van het opsporen van fouten, met als doel om zowel incidenteel als structureel kwaliteitsverbetering van produkten te realiseren. Tijdens de Voorbereiding wordt door de teamleden individueel gezocht naar unieke fouten, d.w.z. fouten die door een andere deelnemer niet worden gevonden. Dit wordt bereikt door aan iedere deelnemer één of meer rollen toe te wijzen. De toegevoegde waarde van Fagan inspection kan worden verhoogd door het organiseren van een ‘causal analysis meeting’. Het doel van deze meeting is om de oorzaken van de geconstateerde fouten in de toekomst te voorkomen. De organisator van de meeting, ‘moderator’ genoemd, dient een onafhankelijke rol t.o.v. het ontwikkelproces te vervullen.

Aangemaakt d.d.

27-12-2011

Pagina 51



15.2 Voordelen Concluderend kan gesteld worden dat Fagan inspection een zeer geschikte techniek is om kwaliteitsverbeteringen van produkten te realiseren. Dit geldt in eerste instantie voor de beoordeelde produkten zelf. Belangrijker is echter dat de kwaliteit van produkten verbeterd kan worden, voordat deze beoordeeld worden, omdat door terugkoppeling vanuit het inspectieproces naar de ontwikkelprocessen structurele verbeteringen aangebracht kunnen worden. Deze verberingen zorgen ervoor dat eenmaal gemaakte fouten in de toekomst zoveel mogelijk worden vermeden.

15.3 Werkwijze Stappen binnen een Fagan inspection: • Toetsing aan entry criteria = een verzameling criteria, waaraan een produkt moet voldoen, voordat het getoets wordt; • Organiseren van de inspectie: indelen team en toekennen van rollen binnen het team; • Kick-off; • Voorbereiding: zoeken naar unieke fouten; • Foutregistratie-meeting: inventarisatie van door de deelnemers gevonden fouten; • Discussie-meeting: discussiëren over oplossingsalternatieven van een beperkt aantal gevonden fouten; • Causal analysis meeting: analyseren van de oorzaken van de belangrijkste fouten; • Uitvoeren rework: aanpassen van het beoordeelde produkt a.d.h.v. de gevonden fouten, oorzaken en oplossingen; • Follow-up: controle op het uitgevoerde rework (aanpassingen) • Toetsen exit criteria: voordat een produkt het inspectieproces verlaat worden eerst getoetst of het produkt aan de vastgelegde exit criteria voldoet. Op het verschillende momenten in het proces worden door de moderator gegevens verzameld m.b.t. de effectiviteit en de efficiency van de inspectie. Deze gegevens worden geregistreerd op een inspectieformulier. De gegevens van meerdere sessies worden geanalyseerd door de afdeling kwaliteitszorg en op basis daarvan kunnen structurele verbeteringen in het ontwikkelproces worden aangebracht.

16. Specificatietechnieken 16.1 Algoritmetest 16.1.1 Algemeen De test heeft tot doel de structuur van een programma te testen. De test is dan ook een structuurtest; de testgevallen komen voort uit de structuur van een algoritme c.q. programma en niet uit de bijbehorende verwerking. Ieder testgeval bestaat derhalve uit een groep opeenvolgende acties die te zamen een pad door het algoritme doorlopen. Het is bij uitstek een White-box testtechniek die wordt gebruikt bij de programmatest en of integratietest.

16.1.2 Werkwijze (zie bijlage D - Voorbeelden specificatietechnieken) 1. Inventariseren van beslispunten; 2. Bepalen testpaden; 3. Specificeren van testgevallen: Per logisch testpad fysieke testgevallen opstellen en een uitvoervoorspelling doen; 4. Vaststellen initiële gegevensverzameling: Indien noodzakelijk, beknopte beschrijving maken; 5. Opstellen testscript.

Aangemaakt d.d.

27-12-2011

Pagina 52



16.2 Beslissingstabellentest 16.2.1 Algemeen De test is een uiterst formele testtechniek. Testgevallen worden volgens vaste regels uit de testbasis afgeleid. De test is afhankelijk van twee parameters. De ene parameter (testmaat) geeft aan in hoeverre afhankelijkheden tussen verschillende b eslissingspunten worden getest, de andere parameter (detailleringsmaat) geeft aan in hoeverre afhankelijkheden binnen b eslispunten worden getest. Afhankelijk van de keuze van deze parameters levert de techniek veel of weinig testgevallen en een hogere of lagere dekkingsgraad op. Een sterk punt van de techniek is dat met behulp van de parameters de test kan worden afgestemd op de teststrategie. Zodra de parameters zijn bepaald, ligt de werkwijze voor de test eenduidig vast. De test richt zich op de volledigheid en juistheid van de verwerking en daarmee op het kwaliteitsattribuut functionaliteit. Deze techniek is in principe ontwikkeld voor white-box testen, maar kan tevens worden toegepast bij een black-box test.

16.2.2 Werkwijze (zie bijlage B - Voorbeelden Specificatietechnieken) 1. 2. 3. 4. 5.

Definiëren logische testkolommen; Specificeren logische testgevallen; Specificeren fysieke testgevallen; Vaststellen initiële gegevensverzameling; Opstellen testscript.

16.3 Dataflowtest 16.3.1 Algemeen Het uitgangspunt bij deze test zijn, de gegevensstromen en de verwerking daarvan. Het is een test waarbij de verwerking door functies en de relaties tussen functies worden getest. De test is een Testspecificatietechniek die wordt gebruikt bij het testen van de functionaliteit c.q. de juistheid en de volledigheid van de verwerking in het kader van een Black-box test, met name bij de acceptatietest. De test is een semi-formele testtechniek. Hoewel er duidelijke richtlijnen zijn hoe testgevallen geselecteerd moeten worden, is de basis van het selecteren van de testgevallen de intuïtie van de tester en zijn begrip van het testobject. Dit heeft als voordeel dat: • Niet-automatiseerders vanuit hun begrip van het informatiesysteem gemakkelijk een goede test kunnen samenstellen. • De kwaliteit van de testbasis van minder belang is. • Er met relatief weinig inspanning goede testspecificaties en testscripts kunnen worden gemaakt. Het nadeel is echter de relatieve onvolledigheid van de test. Als gevolg van het informele karakter hangt e kwaliteit van een uitgevoerde Dataflowtest mede af van de kwaliteit van de tester. Voor een meer formele en meer volledige test is de elementaire vergelijkingen-testtechniek beschikbaar. Gestart wordt bij de Dataflowtest met een inventarisatie, per hoofdfunctie, van de invoergegevens. Per gegeven wordt vervolgens bepaald welke waarden de procesfflow beïnvloeden. Op basis hiervan wordt een beperkt aantal testgevallen samengesteld. Daarmee wordt vervolgens per (deel)functie bepaald welke testgevallen van belang zijn en welke verwerking getest dient te worden. Hiermee is de basis voor de test gelegd. Door de testgevallen en controles in een uit te voeren volgorde te zetten en er eventuele voorbereidende acties aan toe te voegen wordt een testscript verkregen. Met behulp van deze techniek kunnen ook de functionaliteiten met betrekking tot applicatiebeheer en systeembeheer worden getest. Aangemaakt d.d.

27-12-2011

Pagina 53



De Dataflowtest geeft een goede dekking van de functies voor wat betreft het gebruik van de functie(s) zoals die in de praktijk wordt verwacht. Fouten die met de Dataflowtest worden gevonden, zijn met name fouten in verwerking: worden de gegevens goed gemanipuleerd, worden berekeningen goed uitgevoerd en sluiten de verschillende functies goed op elkaar aan.

Aangemaakt d.d.

27-12-2011

Pagina 54



16.3.2 Werkwijze (zie bijlage B - Voorbeelden Specificatietechnieken) •

• •

Specificeren testgevallen: • Bepalen testsituaties; • Bepalen testgevallen; • Bepalen testacties; • Bepalen controles. Vaststellen initiële gegevensverzameling; Opstellen testscript.

16.4 Elementaire vergelijkingentest 16.4.1 Algemeen Bij deze test wordt de verwerking gedetailleerd getest. De test verifieert alle functionele paden van een functie. Dit wordt gedaan door eerst alle functionele condities te inventariseren en te ontleden tot vergelijkingen in pseudo-code. Vervolgens worden door de verschillende functionele condities, die worden onderscheiden binnen de vergelijkingen, testgevallen gedefinieerd. De elementaire vergelijkingentest garandeert een redelijke volledigheid en is daardoor tijdsintensief. Hij zal vooral moeten worden gebruikt bij het testen van zeer belangrijk geachte functies en of complexe berekeningen. Deze techniek kan zowel in een batch als in een on-line omgeving worden toegepast. De techniek is in principe ontwikkeld voor het black-box testen, maar kan tevens worden gebruikt bij een white-box test. De techniek richt zich op het kwaliteitsaspect functionaliteit.

16.4.2 Werkwijze (zie bijlage B - Voorbeelden Specificatietechnieken) •

• •

Specificeren testgevallen: • Analyse functiebeschrijving; • Bepalen testsituaties; • Bepalen testgevallen; • Vervaardigen testgeval / testsituatie matrix; • Bepalen testacties • Bepalen controles. Vaststellen initiële gegevensverzameling; Opstellen testscript.

16.5 Error Guessing 16.5.1 Algemeen Is in wezen ongestructureerd testen, het gissen naar fouten. De waarde ervan ligt in het onverwachte: er worden tests uitgevoerd die anders niet aan bod komen. Het is een waardevolle aanvulling op de gestructureerde testspecificatietechnieken. De techniek wordt met name gebruikt bij black-box testen en kan zich in principe richten op alle mogelijke kwaliteitsattributen. De ervaring van de tester speelt een belangrijke rol. De tester heeft de volledige vrijheid ter lekke testgevallen te verzinnen en uit te proberen. De essentie is dat de tester op zoek gaat naar die gevallen die altijd moeilijkheden veroorzaken. Door die gevallen te proberen, wordt er getest. In principe is de enige startvoorwaarde voor deze techniek dat een goed begrip moet bestaan van het te testen systeem, maar ook enige mate van stabiliteit van het testen systeem is gewenst. De techniek is dan ook bij uitstek geschikt voor de eindfase van het testproces. Hij mag niet als enige techniek worden gebruikt. Het nut van gestructureerd testen is de relatieve volledigheid die ermee wordt bereikt. Het is evenmin aan te bevelen de techniek toe te passen op een relatief instabiel systeem: door de aard van de techniek is de herhaalbaarheid zeer gering en daarmee de reproduceerbaarheid van de gedane bevindingen.

Aangemaakt d.d.

27-12-2011

Pagina 55



16.5.2 Werkwijze Ter voorbereiding op de testuitvoering wordt in het kader van error guessing de activiteit ‘identificeren van de zwakke plaatsen’ uitgevoerd.

16.6 Gegevenscyclustest 16.6.1 Algemeen Is een techniek die wordt gebruikt om de levensloop van gegevens te testen. Gegevens ontstaan, worden geraadpleegd en gewijzigd en worden uiteindelijk veelal verwijderd. Tijdens de test wordt geverifieerd of de gegevens door de functies correct worden verwerkt en of aan de referentiële relatiehouders (consistentiecontroles van het gegevensmodel) wordt voldaan. Het doel van de techniek is dus niet het testen van de functionele controles zoals beschreven in de functiebeschrijving. Een en ander betekent dat niet alleen met de on-line raadpleegfunctie wordt gecontroleerd of de gegevens correct zijn verwerkt, maar dat ook de beperkingen die het gegevensmodel stelt tijdens het invoeren, wijzigen en of verwijderen worden opgespoord en getest. Tevens wordt gecontroleerd of alle functies die volgens de CRUD-matrix van de gegevens gebruik maken, daadwerkelijk kunnen worden uitgevoerd. Een CRUD-matrix is een matrix waarbij op de assen horizontaal en verticaal de functies staan weergegeven. Door middel van de letters C(reate), R(ead), U(pdate) en D(elete) wordt de matrix ‘ingevuld’. Daar waar namelijk een functie een bepaalde actie met betrekking tot een entiteit uitvoert, wordt dit in de matrix aangegeven door middel van een C, R, U en of D. op deze wijze wordt inzicht verkregen in de (volledigheid van de) levensloop van de gegevens c.q. entiteiten. Het is een Black-box testtechniek die met name wordt gebruikt tijdens de acceptatietest. Bij het toepassen van deze test wordt veelal het bijna gehele informatiesysteem geraakt. De techniek wordt dan ook vaak gebruikt tijdens een van de laatste fasen van de acceptatietest: de integrale test. Er bestaan twee varianten. Een die zich richt op de beheersfuncties van stamgegevens c.q. basistabellen. Een beheersfunctie is in dit verband gedefinieerd als een functie die alle elementaire acties (invoeren, raadplegen, wijzigen en verwijderen) uitvoert. De overige functies van het informatiesysteem raadplegen in principe slechts de betreffende gegevensverzameling. Soms wordt voor een enkel attribuut van de gegevensverzameling bijgewerkt door een andere functie, bijvoorbeeld het bijwerken van het laatste factuurnummer. Beheersfuncties worden vaak als een geheel gebouwd en opgeleverd aan het testteam. Het is derhalve mogelijk en verstandig alle aspecten van een dergelijke functie in een test te verenigen. Voor deze variant is een CRUD-matrix wenselijk, doch niet noodzakelijk. Voor de tweede variant die zich op systeemniveau richt, is de matrix onmisbaar. Deze variant is veelal een test die meerdere onderdelen van het informatiesysteem raakt. De levensloop van de betreffende gegevens (vaak de kerngegevens) wordt door een veelheid aan functies bepaald.

16.6.2 Werkwijze • • • • •

Inventariseren CRUD-matrix en relatiecontroles; Vervaardigen testgevallen per entiteit; Vaststellen testacties en controles; Vaststellen initiële gegevensverzameling; Opstellen testscript.

16.7 Programma interfacetest 16.7.1 Algemeen Is een techniek die wordt gebruikt om de interfaces tussen de verschillende programma’s c.q. modules te testen. Voordat er met een programma interface test kan worden begonnen, moeten de te integreren programma’s zelf reeds onafhankelijk van elkaar zijn getest met behulp van gesimuleerde gegevensstromen. Aangemaakt d.d.

27-12-2011

Pagina 56



Met behulp van deze techniek wordt geverifieerd of de programma’s na integratie nog steeds correct functioneren. In dit geval worden de programma’s aangestuurd met echte gegevensstromen in plaats van met gesimuleerde gegevensstromen. Het is een techniek die met name wordt gebruikt bij de integratietest.

Aangemaakt d.d.

27-12-2011

Pagina 57



16.7.2 Globale werking

Figuur 18 Globale w erking Programma interfacetest

Programma 1 en programma 2 zijn reeds getest m.b.v. de gesimuleerde gegevensstromen: • 1 én 4 voor programma 1 en bestudeerd en op juistheid gecontroleerd d.m.v. 2 én 3; • 3 én 6 voor programma 2 en bestudeerd en op juistheid gecontroleerd d.m.v. 4 én 5; Tijdens de Programma interfacetest moet worden geverifieerd of programma 2 nog steeds correct functioneert indien de invoer van de gesimuleerde stromen vervangen worden door de ‘echte’ stromen (3 én 4). Twee soorten gegevensstromen: • directe: zendende programma geeft gegevens door zonder opslag in een bestand aan ontvangende programma; • indirecte: zendende programma slaat gegevens eerst op in een bestand.

16.7.3 Werkwijze • •

Identificeren gegevensstromen; Bepalen equivalentie klassen: Equivalentie klasse is een deelverzameling van een domein met daarin de attribuutwaarden die voor de test gelijkwaardig (equivalent) zijn. De opdeling is afhankelijk van het formaat (tekst, datum, getal). Voor ieder formaat gelden andere regels.

•

Algemeen geldt: • iedere attribuutwaarde uit een domein dient opgenomen te zijn in een equivalentie klasse; • iedere attribuutwaarde mag maar in één equivalentie klasse voorkomen; • als een attribuut niet verplicht is bij het zendende programma dan is de lege verzameling ook een equivalentie klasse; • als het domein van een attribuut slechts enkele waarden bevat, dan wordt iedere waarde een equivalentie klasse; • bij een groot aantal numerieke waarden, dan worden als equivalentie klassen genomen: • het kleinste getal; • het grootste getal; • het getal “0”; • het getal met de meeste posities (zowel vóór als ná de komma); • het getal met de minste posities (zowel vóór als ná de komma); • de overige getallen. • bij een groot aantal alfanumerieke waarden, dan worden als equivalentie klassen genomen: • een waarde met een minimum aantal posities; • een waarde met een maximum aantal posities; • de overige waarden. Bepalen testgevallen: • kies een representant uit iedere klasse; • combineer de representanten tot testgevallen.

Aangemaakt d.d.

27-12-2011

Pagina 58

Uittreksel Titel: Testen volgens TMap • • •


Bepalen testacties en controles; Vaststellen initiële gegevensverzameling; Opstellen testscript.

16.8 Procescyclustest 16.8.1 Algemeen Is een techniek die wordt gebruikt om de interfaces tussen de verschillende programma’s c.q. modules te testen. Voordat er met een programma interface test kan worden begonnen, moeten de te integreren programma’s zelf reeds onafhankelijk van elkaar zijn getest met behulp van gesimuleerde gegevensstromen. Met behulp van deze techniek wordt geverifieerd of de programma’s na integratie nog steeds correct functioneren. In dit geval worden de programma’s aangestuurd met echte gegevensstromen in plaats van met gesimuleerde gegevensstromen. Het is een techniek die met name wordt gebruikt bij de integratietest. De test heeft tot doel de inpasbaarheid van het geautomatiseerde deel van het informatiesysteem binnen de AO-procedures te controleren, waarbij met name wordt gekeken naar de raakvlakken (interfaces) tussen de geautomatiseerde processen en de handmatige procedures. De aanname hierbij is dat de geautomatiseerde processen op zich conform specificaties werken. Tijdens de test wordt geverifieerd of de geautomatiseerde processen aansluiten op de handmatige procedures en vice versa. Daarbij moet onder andere antwoord worden verkregen op de volgende vragen: • Geven de geautomatiseerde processen voldoende informatie om alle handmatige processen te kunnen uitvoeren. • Levert de uitvoer van de handmatige procedures voldoende gegevens op om alle geautomatiseerde processen te kunnen starten. • Beschikken de medewerkers over voldoende autorisatie om de procedures te kunnen uitvoeren. De test wordt met name gebruikt om de inpasbaarheid vast te stellen. Eventueel kan de Procescyclustest zich tevens richten op de kwaliteitsattributen gebruikersvriendelijkheid en beveiliging. De test wijkt op een aantal punten af van andere technieken. Zo is de test geen specificatietest maar een structuurtest. De testgevallen komen namelijk voort uit de structuur van de procedureflow (net zoals in een programmatest de testgevallen voortkomen uit de structuur van het algoritme) en niet uit de ontwerpspecificaties. Ieder testgeval bestaat derhalve uit een groep opeenvolgende acties die te zamen precies een pad door de procedureflow vormen. Bij deze acties horen in tegenstelling tot de testgevallen die met behulp van andere testtechnieken worden vervaardigd, geen (expliciete) controles. De (impliciete) controle van een bepaalde actie is namelijk dat de volgende actie uitvoerbaar is. Het is dus voldoende om te controleren dat de rij acties inderdaad achtereenvolgens uitvoerbaar is. Nog een verschil met de overige technieken is dat er bij de testuitvoering meer nodig is dan alleen de fysieke testomgeving. De handmatige procedures moeten namelijk veelal worden uitgevoerd door verschillende soorten medewerkers, hetgeen betekent dat er bij de testuitvoering meerdere testers nodig zijn die een bepaald rollenspel moeten spelen. Het is uiteraard ook mogelijk de test uit te laten voeren door een tester die over meerdere user-id’s beschikt en tijdens de testuitvoering meerdere keren in- en uitlogt. Tenslotte zitten de benodigde gegevens slechts voor een deel in de database van het geautomatiseerde deel van het informatiesysteem maar voor het overige daarbuiten, bijvoorbeeld in de vorm van ingevulde formulieren. Ook dat is een verschil met de overige technieken. Bij het uitwerken van de diverse stappen wordt een onderscheid gemaakt tussen een diepgaande en een normale test. De keuze wordt uiteraard gemaakt op basis van het belang dat aan het kwaliteitsattribuut inpasb aarheid is gegeven in de teststrategie. Het verschil tussen beide tests is te herleiden tot een verschil in testmaat. Met de testmaat wordt bepaald in hoeverre afhankelijkheden tussen opeenvolgende beslispunten worden getest. Bij een testmaat n worden alle afhankelijkheden van acties voor 1 beslispunt en na n-1 beslispunten geverifieerd door alle mogelijke combinaties met betrekking tot de activiteiten in testpaden onder te brengen. Aangemaakt d.d.

27-12-2011

Pagina 59



Bij een diepgaande test wordt gewerkt op basis van testmaat 2 en bij een normale test op basis van testmaat 1.

16.8.2 Werkwijze procescylcustest testmaat 2 (zie bijlage B - Voorbeelden Specificatietechnieken) • • • • •

Inventariseren beslispunten; Bepalen padcombinaties + pade; Specificeren testgevallen; Vaststellen initiële gegevensverzameling; Opstellen testscript.

16.8.3 Werkwijze procescyclustest testmaat 1 (zie bijlage B - Voorbeelden Specificatietechnieken) • • • • •

Inventariseren beslispunten; Bepalen testpaden; Specificeren testgevallen; Vaststellen initiële gegevensverzameling; Opstellen testscript.

16.9 Real-life test 16.9.1 Algemeen Het doel van de test, soms uitgevoerd in de vorm van schaduwproduktie, is fouten te ontdekken die te maken hebben met de uiteindelijke omvang van het informatiesysteem. De test moet dus zoveel mogelijk de werkelijke situatie nabootsen ten aanzien van onder andere het aantal verwerkingen, het aantal gebruikers en de belasting van het informatiesysteem in de loop van de tijd. Vaak blijken bij het in gebruik nemen van het systeem plotseling een aantal zaken niet te werken. Deze techniek voorkomt dit soort verassingen. Fouten die met deze techniek gevonden worden, houden doorgaans verband met het resourcegebruik van het systeem: • De responsetijden zijn onvoldoende. • De snelheid van de batchverwerking is onvoldoende. • De beschikbare geheugen- diskruimte is te klein. • De printercapaciteit is onvoldoende. • Het datacommunicatienetwerk kan de belasting niet aan. Een ander aspect dat kan worden getest met behulp van deze techniek is de relatie met de omgeving; het daadwerkelijk in produktie-omgeving functioneren van de interfaces met andere informatiesystemen. De techniek kan zich richten op kwaliteitsattributen zoals performance, geschiktheid infrastructuur, bedrijfszekerheid en robuustheid. Veelal wordt de techniek gebruikt aan het einde van een acceptatietest als het systeem functioneel reeds voldoet.

16.9.2 Werkwijze • •

Profielschets systeemgebruik: welke acties worden hoe vaak gedurende een bepaalde periode uitgevoerd; Specificeren en realiseren testgevallen.

16.10 Semantische test 16.10.1 Algemeen Deze test heeft tot doel de relaties tussen gegevens bij het invoeren te verifiëren. Deze relaties kunnen liggen tussen de gegevens binnen een scherm, tussen gegevens op verschillende schermen onderling en tussen de (invoer)gegevens en reeds in de database aanwezige gegevens. Deze techniek start met een inventarisatie van de relatiecontroles. Deze relaties worden ontleed in condities en paden: onder welke omstandigheden gebeurt wat. Deze condities worden een voor een (per scherm) uitgetest. Aangemaakt d.d.

27-12-2011

Pagina 60



Deze techniek wordt met name gebruikt bij het testen van on-line systemen in het kader van een systeemtest of acceptatietest. De techniek kan zich naast functionaliteit ook op het kwaliteitsattribuut beveiliging richten. De controle op de toegangsbeveiliging kan namelijk worden gezien als een relatiecontrole op in het systeem aanwezige beveiligingsdefinities (autorisaties) en de invoer van user-id en wachtwoord. Naast deze semantische test kunnen op de mens-machine interface ook syntactische tests worden uitgevoerd. Het doel daarvan is het ontdekken van fouten in de lay-out en de primaire validaties (o.a. domeinen) met betrekking tot de velden. Syntactische tests kunnen parallel met de semantische tests worden uitgevoerd. Eventueel kunnen zelfs de testscripts worden gecombineerd.

Aangemaakt d.d.

27-12-2011

Pagina 61



16.10.2 Werkwijze (zie bijlage B - Voorbeelden Specificatietechnieken) • • • • •

Inventariseren relatiecontroles; Uitwerken relatiecontroles in ALS, DAN en ANDERS met EN / OF vergelijkingen Vaststellen testacties en controles; Vaststellen initiële gegevensverzameling; Opstellen testscript.

16.11 Syntactische test 16.11.1 Algemeen Deze test heeft tot doel fouten te ontdekken in de lay-out van schermen en overzichten en in de primaire invoercontroles met betrekking tot de rubrieken. Als toetscriteria kunnen geldende standaards worden gebruikt en specifieke beschrijvingen van schermen en overzichten in de functionele specificaties. Dit wordt gedaan door enerzijds alle (scherm)rubrieken te relateren aan de attributen uit het gegevensmodel en van deze attributen vervolgens te bepalen welke lengte deze mogen hebben en welke restricties van toepassing zijn. Anderzijds worden de beschikbare opties geïnventariseerd en gerelateerd aan de schermen en schermrubrieken. Het testen hiervan is vervolgens relatief rechtlijnig. Deze techniek kan met name worden gebruikt bij het testen van on-line systemen. Echter ook bij batchsystemen kan een syntactisch test worden toegepast voor een controle op de geproduceerde overzichten. Naast de syntactische tests kunnen op de mens-machine interface kunnen ook semantische tests (zie hiervoor) worden uitgevoerd. Het doel hiervan is onder andere het ontdekken van fouten in de consistentie tussen de ingevoerde velden of schermen enerzijds en de reeds en het systeem aanwezige informatie anderzijds. Semantische tests kunnen parallel met de syntactische tests worden uitgevoerd. Het verdient aanbeveling ook de testscripts van beide testtechnieken te combineren.

16.11.2 Werkwijze • • •

Opstellen checklist m.b.t. schermen en overzichten; Vaststellen te testen scherm en overzichten; Opstellen testscript.

16.11.3 Syntactische controles • • •

lay-outcontrole op de schermen en overzichten; functiegebruik-controle op de schermen; rubriekcontrole op schermen en overzichten: • schermrubriekcontrole; • invoer/uitvoer (I/O) controle; • controle velddefinities; • controle verplichte rubrieken; • help controle. • overzichtrubriekcontrole.

17. Checklist Kwaliteitsattributen 17.1 Inleiding In bijlage B- Checklists zijn de checklists opgenomen voor de indirecte meetbare kwaliteitsattributen. Dit zijn de kwaliteitsattributen die worden beoordeeld d.m.v. statisch testen. Tevens is een checklist gebruikersvriendelijkheid opgenomen die kan worden gebruikt tijdens het dynamisch impliciet testen van gebruikersvriendelijkheid.

Aangemaakt d.d.

27-12-2011

Pagina 62



Per checklist zijn de relevante maatregelen beschreven die invloed hebben op het betreffende kwaliteitsattribuut. Met een “+” zijn de maatregelen met een guntsige invloed en met een “-“ met een ongunstige invloed aangeduid.

Aangemaakt d.d.

27-12-2011

Pagina 63



De beschreven maatregelen zijn ingedeeld in een aantal aandachtsgebieden, te weten: • Verwerkingsorganisatie; • Gebruikersorganisatie; • Functionele systeemarchitectuur; • Technische systeemarchitectuur; • Gegevensinfrastructuur; • Fysieke beveiligingsmaatregelen; • Ontwikkelomgeving; • Produktie-omgeving. Het is niet altijd mogelijk om een specifiek kwaliteitsattribuut in een specifieke organisatie te onderzoeken met een standaard checklist. De checklists opgenomen in de bijlage B - Checklists dienen dan ook als referentiekader en voorbeeld voor het samenstellen van organisatie-afhankelijke en soms zelfs projectafhankelijke checklists. M.b.t. de volgende kwaliteitsattributen zijn checklists opgenomen in bijlage B - Checklists: • Beheerbaarheid; • Beveiliging; • Connectiviteit; • Continuïteit; • Controleerbaarheid; • Flexibiliteit; • Gebruikersvriendelijkheid; • Herbruikbaarheid; • (geschiktheid) Infrastructuur; • Onderhoudbaarheid; • Portabiliteit; • Testbaarheid.

18. Overige Checklists 18.1 Inleiding Voor het voorbereiden en uitvoeren van de verschillende testactiviteiten is het beschikbaar hebben van een checklist een uitstekend hulpmiddel. Natuurlijk is het niet mogelijk om een specifieke situatie in een specifieke organisatie te onderzoeken met een standaard checklist. De checklists opgenomen in de bijlage B - Checklists dienen dan ook als voorbeeld voor het samenstellen van organisatie-afhankelijke en soms zelfs project-afhankelijke checklists. Opgenomen zijn: • Evaluatie testproject; • Globale bestudering informatiesysteem; • Randvoorwaarden en uitgangspunten; • Risico’s testproject; • Structurering; • Testfaciliteiten; • Testmetrieken testproces; • Vrijgave produktie.

Deel IV: Organisatie 19. Inleiding organisatie 19.1 Testorganisatie Het testen maakt onlosmakelijk deel uit van de processen die nuttig voor ons zijn op alle niveaus van de organisatie; strategisch, tactisch en operationeel.

Aangemaakt d.d.

27-12-2011

Pagina 64



19.2 Strategisch Het samenspel van diverse functies in een organisatie, bijvoorbeeld verkoop, produktie of expeditie, bepaalt in welke mate aan de doelstellingen kan worden voldaan. De informatievoorziening is ook een van die functies. Op strategisch niveau in de organisatie moeten de kwaliteitsdoelstellingen worden vastgesteld en de mogelijkheden worden aangegeven waarmee die verwezenlijkt moeten worden. De vertaling daarvan, het kwaliteitsbeleid, vormt de basis voor de structurering van het testen en de faciliteiten die daarvoor beschikbaar komen.

19.3 Tactisch Net als in elk ander proces binnen de informatievoorziening vraagt testen om voorschriftgeving en controle op de toepassing en toepasbaarheid van deze voorschriften. Ze beschrijven hoe binnen de organisatie inhoud gegeven moet worden aan de vier pijlers onder een gestructureerde testaanpak, aan de fasering, de technieken, de infrastructuur en de organisatie. De functie voorschriftgeving en controle moeten op tactisch niveau in de organisatie verankerd worden. Om reden van functiescheiding wordt de controlefunctie bij voorkeur separaat gepositioneerd van de voorschriftgeving.

19.4 Operationeel De functies in het operationele testproces zijn te onderscheiden in enkele voorw aardenscheppende en zuivere uitvoeringsfuncties.

Voorw aardenscheppende functies Ondersteunende functies op methodisch, technisch en functioneel gebied.

Uitvoeringsfuncties Typische functies zijn Testen en Testmanagement. Testen vraagt een mixture van expertise van de materie, het informatiesysteem, infrastructuur en testtools en uiteraard testen. Bij voorkeur worden deze activiteiten in projectvorm uitgevoerd, nadrukkelijk ondersteund door en afhankelijk van lijnfuncties. Dat vraagt veel organisatietalent en tact van alle partijen. De belangen en verantwoordelijkheden van project en lijn conflicteren maar al te vaak. Het onderhoudstesten worden mees tal belegd in de lijn.

19.5 Nota bene Afhankelijk van bijvoorbeeld de testsoort, de omvang van het testobject en de typologie van de organisatie zal de optimale mixture van testproces-bouwstenen zoals testfuncties, personeel en beheersmiddelen, worden ingericht. Voor een verantwoorde uitvoering van Black-box tests (systeem en acceptatie) is in veel gevallen een groot deel van de bouwstenen noodzakelijk. Voor de White-box tests kan meestal worden volstaan met een afgeleide vorm.

19.6 Inrichting van de organisatie TMap biedt instrumenten die de keuze voor de organisatiestructuur ondersteunen.

20. Testfuncties 20.1 De functie testen De functie testen omvat de primaire testtaken, de kern van het proces. De testtaken zijn de meeste creatieve, maar ook de meest arbeidsintensieve van de testactiviteiten. De functie testen is in de TMap-fasering actief vanaf de intake van de testbasis in de fase Voorbereiding tot en met de conservering van de testware in de fase afronding. Aangemaakt d.d.

27-12-2011

Pagina 65


Aangemaakt d.d.

27-12-2011


Pagina 66



Mogelijke taken • Intake van de testbasis (de specificaties) • Specificatie van logische en fysieke testgevallen en uitgangsgegevens. • Vulling uitgangsbestanden. • Uitvoeren van testgevallen (dynamisch testen). • Uitvoeren van controles en onderzoeken (statisch testen). • Registreren van bevindingen. • Conserveren van testware.

20.2 De functie teamleiding De teamleider geeft als meewerkend voorman leiding aan een team van 2 tot 4 testers. Het leidinggeven neemt circa 20% van de tijd in beslag. De functie teamleiding is in de TMap fasering actief vanaf de intake van de testbasis in de fase Voorbereiding tot en met de conservering van de testware. Mogelijke taken • Opstellen detailplannen. • Uitvoeren werkverdeling en voortgangsbewaking. • Waarborgen faciliteiten. • Registratie van de voortgang en uitputting van het (uren)budget. • Aandragen van oplossingen van knelpunten en het effectueren daarvan. • Instructie en ondersteuning van testers. • Beoordeling medewerkers. • Uitvoering van de primaire testtaken, zie functie testen.

20.3 De functie testmanagement Het testmanagement is verantwoordelijk voor de planning, de aansturing en de uitvoering van het testproces, binnen planning en budget met de juiste kwaliteit. Het testmanagement rapporteert conform het testplan over de voortgang van het testproces en de kwaliteit van het testobject. De testmanagement-functie is actief bij alle activiteiten van de TMap-fasen. Mogelijke taken • Opstellen, verkrijgen van goedkeuring en onderhouden van het testplan. • Uitvoeren van het testplan binnen planning en budget. • Rapporteren over de voortgang van het testproces en de kwaliteit van het testobject.

20.4 De functie methodische ondersteuning De functie ondersteunt het testproces op methodisch gebied in de meest ruime zin van het woord. Ze is ondersteunend voor alle testtechnieken en voor alle leden van het testteam. Dus zowel voor het testmanagement bij bijvoorbeeld de strategiebepaling als voor de tester bij het specificeren van testgevallen. De functie kan actief zijn bij alle activiteiten van de TMap-fasen. Mogelijke taken • Inrichting testtechnieken. • Ontwikkeling van nieuwe testtechnieken. • Opstellen testvoorschriften. • Ontwikkeling bijbehorende opleiding. • Doceren en coachen. • Adviseren en ondersteunen bij de toepassing van alle soorten testtechnieken. • Managementadvisering.

20.5 De functie technische ondersteuning De functie ondersteunt het testproces op technisch gebied in de meest ruime zin van het woord. Ze moet bewerkstelligen dat het testproces blijvend en op hoog niveau kan beschikken over de testinfrastructuur. Het beheer en beheersbaarheid van de Testomgevingen, de testtools en de kantoorinrichting moeten gewaarborgd zijn. De functie kan actief zijn bij alle activiteiten van de TMap-fasering. Aangemaakt d.d.

27-12-2011

Pagina 67



Mogelijke taken • Inrichting en beheer van de infrastructuur. • Fysieke configurationmanagement. • Oplossing van technische problemen. • Bewaking van de reproduceerbaarheid van de testen. • Verzorgt creatie, transformatie, onderhoud en beheer van job control.

20.6 De functie functionele ondersteuning De functie ondersteunt het testproces op functioneel gebied in de meest ruime zin van het woord. De functie zorgt voor de inbreng van zowel de materiekennis als de kennis hoe deze materie functioneel is gespecificeerd. Ze is ondersteunend bij de uitvoering van die activiteiten waarbij vragen over de functionaliteit kunnen ontstaan. Dus zowel voor het testmanagement bij bijvoorbeeld de strategiebepaling of het opstellen van risicorapportages als voor de tester bij de intake of het specificeren van testgevallen. De functie kan actief zijn bij alle activiteiten van de TMap-fasen.

20.7 De functie intermediair In grotere Black-box testteams is het aanbevelingswaardig een speciale functie in te richten voor een adequate kanalisering van de bevindingen en de oplossingen daarvan. De intermediair onderhoudt hierover op uitvoerend niveau de externe contacten. De intermediair fungeert als doorgeefluik van enerzijds de bevindingen en anderzijds de oplossingen. Alle incidenten passeren dit knooppunt. De belangrijkste doelen zijn: • Beheer van oplossingen en bevindingen. • Voorkomen van overhead.

20.8 De functie beheer Testbeheer is een administratief, logistieke functie. De functie draagt de verantwoording voor de registratie, opslag en beschikbaarstelling van alle beheersobjecten van het testproces. Soms door het beheer zelf te voeren, in andere gevallen door dat beheer in te richten en of zelf te controleren. De toedeling van de uitvoerende beheerstaken hangt sterk af van de omgeving en de typologie van het testproces (omvang, project of lijn, nieuwbouw of onderhoud). Ook de mate waarin beheerstaken in de structurele organisatie verankerd zijn, is hierbij uiteraard bepalend. De functie kan actief zijn bij alle activiteiten van de TMap-fasen. Mogelijke taken • Voortgangsbeheer. • Beheer testdocumentatie. • Administreren van bevindingen en verzamelen van statistieken. • Logisch beheer van binnen het testproces beschikbaar gestelde (delen) testbasis en testobject. • Logisch beheer van testware, inclusief bestanden. • Beheer huisvesting en logistiek. • Controle op de gedelegeerde beheerstaken.

20.9 De functie testvoorschriftgeving Is een lijnfunctie die functioneert in situaties waar het testen geheel of gedeeltelijk in de structurele organisatie is ingebed. ‘Gedeeltelijk in de structurele organisatie’ kan uiteenlopen van alleen de functie testvoorschriftgeving en eventueel de controle tot en ment alle activiteiten behalve bijvoorbeeld de testuitvoering zelf. De functie is, voor wat betreft de voorschriftgevende taken, vergelijkbaar met de functie Methodische Ondersteuning. De functie werkt voor alle activiteiten van de TMap-fasen. Mogelijke taken • Inrichting en onderhoud testvoorschriften. • Distributie van testvoorschriften. • Ontwikkeling van nieuwe testtechnieken en procedures.

Aangemaakt d.d.

27-12-2011

Pagina 68



20.10 De functie controle Is een lijnfunctie. Ze functioneert in die situaties waar het testen geheel of gedeeltelijk in de structurele organisatie is ingebed. ’Gedeeltelijk in de structurele organisatie’ kan uiteenlopen van alleen de functie testvoorschriftgeving en eventueel de controle tot en met alle activiteiten behalve bijvoorbeeld de testuitvoering zelf. De functie bezit de taken van de functies testmanagement, intermediair en beheer. Om reden van functiescheiding is deze functie gescheiden van de functie testvoorschriftgeving. De functie werkt voor alle activiteiten van de TMap-fasen. Mogelijke taken • Controle op de toepassing van de testvoorschriften. • Controle op de bruikbaarheid van de testvoorschriften. • Rapporteren over de resultaten.

20.11 De functie coördinatie en advies De functie, hierna CenA, is een lijnfunctie die functioneert in die situaties waar het testen geheel of gedeeltelijk in de structurele organisatie is ingebed. Ze opereert als facilitaire eenheid, die ondersteuning verleent aan de testprocessen in de meest ruime zin van het woord. Ze herbergt een groot aantal ondersteunende taken, die normaal in een operationeel testteam voorkomen. Nadrukkelijk moet worden gesteld dat deze functie facilitair gericht is, en zich dus nooit rechtstreeks op het kritieke pad van een testproces zal bewegen. Test worden herhaaldelijk uitgevoerd. Het is daarom niet verstandig voor de individuele projecten telkenmale het wiel opnieuw uit te vinden. Door haar opstelling zal de functie automatisch allerhande vragen over het testen verkrijgen. Het is van belang dat te laten groeien. De functie heeft in dit kader als taak de testexpertise en ervaringen te consolideren en aan de diverse testprocessen beschikbaar te stellen. Uiteraard dient de functie nadrukkelijk betrokken te zijn bij het onderhouden van de testvoorschriften. De functie heeft ook een belangrijke taak bij het verzamelen en evalueren van statistische gegevens over het testen. Een van de wezenlijke problemen bij het testen is, dat de vraag of er voldoende is getest pas achteraf te beantwoorden is. Om daarvan te kunnen leren dienen gegevens omtrent het testverloop en het gedrag in produktie te worden bijgehouden en zo mogelijk gerelateerd. Dit geeft in latere projecten de mogelijkheid de risico’s bij het in produktie gaan beter in te schatten en testprocessen beter te kunnen plannen. Indien gewenst zal de functie de diverse testplannen inhoudelijk toetsen op planningsaspecten en op concurrende testactiviteiten ten aanzien van het gebruik van de testinfrastructuur. Ze zal zo nodig concurrerend optreden. Mogelijke taken • Masterplanning van de testprocessen • Ondersteuning bij het opstellen van (detail)testplannen. • Ondersteuning bij het inrichten van de testorganisatie. • Aannemen en beoordelen medewerkers. • Ontwikkeling en onderhoud van testopleidingen. • Doceren en coachen. • Bemiddeling bij externe opleidingen. • Adviseren en ondersteunen bij de toepassing van alle soorten testtechnieken. • Managementadvisering. • Bemiddeling bij inhuur van expertise.

20.12 De functie testbeheer Is een lijnfunctie die facilitaire ondersteuning levert aan testprocessen voor technische aspecten, het beheer en onderhoud van de testinfrastructuur en tools. De functie vervult voor het testen de rekencentrumtaken. Ze functioneert in die situaties waar het testen geheel of gedeeltelijk in de structurele organisatie is ingebed. Nadrukkelijk moet worden gesteld dat deze functie facilitair gericht is, dus nooit rechtstreeks op het kritieke pad van een testproces zal bewegen. Gezien de vereiste flexibiliteit en responsesnelheid is het gewenst dat de functie enigszins geïsoleerd van de normale produktionele activiteiten wordt gesitueerd. De functie kan actief zijn op alle activiteiten van de TMap-fasen.

Aangemaakt d.d.

27-12-2011

Pagina 69



21. Personeel en opleidingen 21. 1 Personeel Naast de gebruikelijke perikelen rond het fenomeen Personeel kenmerkt de personeelsvoorziening voor het testen zich door enkele eigenaardigheden waarmee bij selectie, instroom en opleiding rekening moet worden gehouden: • Miskenning van het testvak. • Testen vraagt een testhouding en speciale sociale vaardigheden. • Testers moeten tegen een stootje kunnen want ze krijgen kritiek van alle kanten. • Moeilijk planbare rekrutering en uitstroom van testpersoneel. Testopleidingen worden als overbodig gezien.

21.2 Opleidingen Van testers wordt verwacht dat ze zowel in de breedte (automatisering algemeen en sociale vaardigheden) als in de diepte (testmethoden en -technieken) bekwaam zijn. Het is raadzaam testopleidingen modulair op te (laten) bouwen en beschikbaar te stellen. Afhankelijk van de functie en de bij de medewerker aanwezige expertise kan dan min of meer individueel per (deel) onderwerp worden opgeleid.

22. Organisatiestructuur 22.1 Synergie De structuur moet meer zijn dan de optelsom van de functies. Er moet sprake zijn van een synergie, dus als het kan: 2+2=5.

22.2 Testfuncties en taken Operationeel • Testen • Teamleiding • Testmanagement • Methodische ondersteuning • Technische ondersteuning • Functionele ondersteuning • Intermediair •

Beheer

Voorw aarde scheppend • Testvoorschriftgeving • Controle • Coördinatie en advies • Testbeheer

Intake, testspecificatie, testuitvoering en afronding. Leiding testteams met 2 tot 4 testers. Leiding, planning, voortgangs- en kwaliteitsbewaking en rapportage. Ondersteuning t.a.v. testtechnieken en opleiding. Ondersteuning t.a.v. testinfrastructuur en tools. Ondersteuning t.a.v. de functionaliteit van het testobject. Registratie, beoordeling en routing van in- en uitgaande bevindingen en oplossingen. Beheer van testproject, testinfrastructuur en testware.

Ontwerp, fixatie, implementatie en onderhoud van testvoorschriften. Toetsing van naleving en bruikbaarheid van de testvoorschriften. Masterplanning, verzamelen statistieken; opleiding en advies. Beheer van testfaciliteiten zoals testware, testinfrastructuur en tools

22.3 Universele organisatiestructuur Het is onmogelijk een organisatiestructuur voor het testen vast te stellen. Voor het operationele testproces prevaleert de projectorganisatie, voor de voorwaardenscheppende functies de lijnorganisatie. In het algemeen geldt dat de structuur van de testorganisatie gelijk moet zijn aan die van het bijbehorende proces van systeemontwikkeling Beïnvloedingsfactoren • Testsoort en testvorm • Nieuwbouw of onderhoud • Gebruikersbetrokkenheid • Organisatie van het ontwikkelingsproces Aangemaakt d.d.

27-12-2011

Pagina 70



Typologie en omvang van de organisatie Automatiseringsvolwassenheid van de organisatie Omvang en complexiteit van het testobject

Aangemaakt d.d.

27-12-2011

Pagina 71



22.4 Organisatie-modellen Figuur 19 Operationele testorganisatie

Figuur 20 Projectorganisatie met testteam

Bedrijfsleiding P&O Finance & IC Kwaliteitszorg R&D

Commercie

Produktie

Informatievoorziening

Expeditie

Kwaliteitszorg R&D Architectuur Support

Rekencentrum

Aangemaakt d.d.

27-12-2011

Systeemontwikkeling

Systeembeheer

Pagina 72



23. Testbeheer 23.1 Inleiding Binnen een testproces worden drie vormen van beheer onderscheiden: • Testproces, aspecten: • voortgang • kwaliteit • statistieken • rapportage • Infrastructuur, aspecten: • testomgeving • (test) tools • kantoorinrichting • Testprodukten, aspecten: • testbasis • testobject • testware • testdocumentatie • testvoorschriftgeving

23.2 Beheer testproces Testprocesbeheer richt zich op het in bedwang houden van het testproces en de kwaliteit van het testobject. Daartoe zijn twee hoofdtaken gedefinieerd: • Registratie, administratie, opslag en interpretatie van: • voortgang en de besteding van budget en tijd; • kwaliteitsindicatoren; • teststatistieken. • Rapportage

23.3 Beheer infrastructuur De infrastructuur wordt tijdens de vroege fase van TMap gespecificeerd en besteld. Na installatie, acceptatie en intake ervan is het testmanagement verantwoordelijk voor het beheer. De beheertaken worden in twee groepen verdeeld: • Technisch beheer, aspecten: • de testomgeving • (test) tools • Logistiek beheer, aspecten: • kantoorinrichting (niet technische deel van de infrastructuur) Wijzigingen in de infrastructuur mogen alleen worden doorgevoerd na goedkeuring van het testmanagement.

23.4 Beheer testprodukten Het is van groot belang de diverse testprodukten goed te onderscheiden en op een eenduidige manier te beheren. Daarbij worden onderscheiden: • Externe produkten: externe veranwtoordelijkheid • testbasis; • testobject. • Interne produkten • testware; • testbasis (intern); • testobject (intern); • testdocumentatie; • testvoorschriftgeving. Aangemaakt d.d.

27-12-2011

Pagina 73



23.5 Procedures 23.5.1 Testproduktbeheer Het doel van deze procedure is het beheren van de interne produkten. Testproduktbeheer bestaat uit een viertal stappen: • Aanleveren van produkten door de testers bij de beheerder; • Registreren van de produkten door de beheerder; • Archiveren van nieuwe en gewijzigde produkten door de beheerder; • Raadplegen: uitgifte van produkten aan teamleden of derden, inclusief registratie aan wie is uitgereikt en wanneer.

23.5.2 Bevindingenbeheer Twee soorten bevindingen: • Intern (een testfout): • testspecificatie fout; • (eigen) omgevingsfout; • uitvoeringsfout; • beoordelingsfout; • overig. • Extern (de fout ligt buiten de test): • testbasis (specificaties, eisen); • testobject (b.v. programmatuur, documentatie); • testomgeving en testtools; • overig.

Figuur 22 Produkten en bevindingen

Binnen een testteam bestaat een interne-bevindingen-procedure. Deze omvat de afspraken over de wijze waarop de tester omgaan met ‘bevindingen’. Twee beslismomenten nl., intake en resultaatvoorspelling. De externe-bevindingen-procedure omvat zowel het besluitvormings- als het herstelproces van bevindingen. Wijzigingsverzoeken of een probleemrapport worden door het ‘analyse-forum’ en het ‘beslisforum’ in behandeling genomen. A.d.h.v. de beslissingen worden herstelopdrachten c.q. wijzigingsopdrachten opgesteld. Voor de rapportage van problemen dient een standaard probleemrapport opgesteld te worden.

23.6 Beheer en kwaliteitszorg Het testmanagement mag verwachten dat de voorwaarden om kwalitatief te kunnen werken zijn of worden gerealiseerd. Externe kwaliteitszorg is niet de competentie van het testmanagement. Het testmanagement mag ook periodiek rekenen op een proces-audit of een produkt-review. De interne kwaliteitszorg valt wel onder de verantwoordelijkheid van het testmanagement. Het is echter niet toe te wijzen aan één functionaris, allen zijn bij het testproces betrokken. De volgende aspecten dienen in ieder geval gewaarborgd te worden t.b.v. de interne kwaliteitszorg: • audit-trail, zichtbaar maken van de relatie tussen de testactiviteiten en de produkten in het testproces; • dekkingsgraad, controle op de in het testplan overeengekomen dekkingsgraad; • tijd en budget. Het is raadzaam op gezette tijden risico-analyses uit te voeren op het testproces. Op basis daarvan kunnen met de opdrachtgever maatregelen genomen worden bij kosten- c.q. budgetoverschrijding, tijdoverschrijding, het leveren van verkeerde of onvoldoende functionaliteit c.q. kwaliteit.

Aangemaakt d.d.

27-12-2011

Pagina 74



24. Structurering 24.1 Teststructureringsproces De implementatie van TMap in een organisatie vraagt een eigen strategie, een Veranderingsstrategie. Een strategie die de fasering, de activiteiten en de invoeringsmethoden aangeeft voor het verbeteren of ontstaan van een gestructureerd testende organisatie. De uitvoering van de implementatie is een taak van organisatiedeskundigen.

24.2 Fasering voor teststructurering •

•

•

•

Initiatie • Opdracht en doelstelling • Veranderingsstrategie • Globale planning Inventarisatie • Samenstelling structureringsteam • Studie, interview en sterkte/zwakte analyse • Plan van aanpak realisatie en invoering Realisatie • Definiëren van de testaanpak • Structureren van de organisatie • Structureren van de infrastructuur • Rekruteren van personeel Invoering • Introduceren, opleiden en begeleiden • Beproeven in de praktijk • Toepassing in produktie

24.3 Valkuilen bij het structureren • • • • • • • •

Going en growing concern Top-down structurering Volstaan met opleiden Eenzijdige structurering Ongeschikte pilot Testtools zien als het ei van Columbus Alleen Black-box tests structureren Teveel beloven, valse verwachtingen wekken

24.4 Veranderen en weerstand Daar waar veranderd wordt, zijn sommige mensen eenvoudig tegen. Dat vraagt inzicht in de relatie tussen de fase waarin het veranderingsproces zich bevindt en het gedrag van de innovator en de hoeveelheid daardoor opgeroepen weerstand. Als dat inzicht er is, wordt weerstand voorspelbaar en beïnvloedbaar. Door telkens te voorspellen wat een bepaalde actie aan weerstand zal oproepen, kunnen vooraf reducerende , maatregelen genomen worden. Voordat bijvoorbeeld breed geïnformeerd wordt, moeten dus reducerende activiteiten zoals ondersteuning en hulpmiddelen beschikbaar zijn.

Aangemaakt d.d.

27-12-2011

Pagina 75



Figuur 23 Weerstand is voorspelbaar en beïnvloedbaar

Aangemaakt d.d.

27-12-2011

Pagina 76



Deel V: Infrastructuur De infrastructuur bestaat uit de faciliteiten en middelen die nodig zijn om adequaat te kunnen testen. Er wordt onderscheid gemaakt tussen de faciliteiten voor testuitvoering (testomgevingen), voor de ondersteuning van het testen (testtools) en voor de kantoorinrichting.

25. Testomgevingen 25.1 Inleiding 25.1.1 Testomgeving De uitvoering van de dynamische tests vraagt een passende testomgeving. Deze is op hoofdlijnen samengesteld uit de volgende componenten: • hardware; • software; • communicatiemiddelen; • faciliteiten voor opbouw en gebruik van bestanden; • procedures. De omgeving moet dusdanig worden samengesteld en ingericht dat a.d.h.v. de testresultaten optimaal kan worden vastgesteld in hoeverre het testobject aan de gestelde eisen voldoet. De programmatest vraagt doorgaans om een heel andere inrichting dan een produktie-acceptatietest. Soms is zo’n omgeving zeer beperkt van omvang en soms omvat het een grote verzameling van apparatuur, programmatuur en procedures, opgesteld op vele locaties. Bovendien spelen de exploitatie-standaards, het type toepassing, de organisatie-structuur en de beschikbare budgetten een belangrijke rol. Dé testomgeving is niet te beschrijven.

25.1.2 Algemene eisen aan testomgevingen • • • • • • •

Overeenstemming met de uiteindelijke poduktie-omgeving; Stabiliteit t.b.v. het onder dezelfde omstandigheden laten functioneren van het testobject; Snel aanpasbaar zijn; Meerdere (fysieke) testomgevingen zonder dat gelijktijdige tests elkaar beïnvloeden; Mogelijkheid om systeemdatum te manipuleren t.b.v. ‘datum-tests’; Back-up / restore mogelijkheden; Uitwijkmogelijkheden t.b.v. de continuïteit van het testen.

25.1.3 Relatie met TMap-fasering Bij toepassing van de TMap-fasering groeit de infrastructuur en daarmee de testomgeving. Binnen de diverse TMap-fasen zijn de onderstaande activiteiten benoemd: • fase Planning en beheer : definiëren infrastructuur; • fase Voorbereiding : specificeren infrastructuur; • fase Specificatie : specificeren intake testobject/infrastructuur, realiseren infrastructuur; • fase Uitvoering : intake testobject.infrastructuur.

25.2 Testomgevingen 25.2.1 Traditioneel Er zijn drie testomgevingen beschikbaar: • de laboratoriumomgeving t.b.v. white-box tests; • de systeemtestomgeving t.b.v. systeemtests; Aangemaakt d.d.

27-12-2011

Pagina 77



de ‘als-het-ware-produktie’-omgeving t.b.v. acceptatietests.

Aangemaakt d.d.

27-12-2011

Pagina 78



Laboratoriumomgeving De white-box testomgeving is uitsluitend geschikt om de programmatuur op haar technische werking te testen. De programmatest en de integratietest worden in de ontwikkelomgeving uitgevoerd, veelal door de programmeur zelf. Het versiebeheer bij white-box tests is van groot belang, daar de programmeur soms met vijf verschillende versies werkt.

Systeemtestomgeving Deze omgeving is er vooral om delen van of het gehele systeem op zowel technische als functionele aspecten te testen. De systeemtest moet worden uitgevoerd in een, van het laboratorium gescheiden, beheersbare omgeving. Beheersbaar houdt in dat er middelen voorhanden zijn waarmee o.a. de programmatuur, de documentatie, de testbestanden en de testware overgedragen en beheerd kunnen worden. Enkele voorwaarden t.b.v. de beheersbaarheid: • Het overzetten van nieuwe of gewijzigde programmatuur moet controleerbaar zijn; • De tests moeten reproduceerbaar zijn; • Individuele tests van het ene en een ander systeem moeten gescheiden kunnen plaatsvinden; • Wildgroei in systeemomgevingen moet worden tegengegaan. Dit leidt tot vele versies, grote testbestanden en dus redundantie en enorme opslagcapaciteiten (kosten).

Acceptatieomgeving Deze omgeving biedt de mogelijkheid toekomstige gebruikers en beheerders het testobject in een zoveel mogelijk ‘als-het-ware-produktie’ omgeving te testen. Doorgaans worden er twee soorten tests onderscheiden: • FAT: Functionele Acceptatie Test: de functionaliteit wordt getest • PAT: Produktie Acceptatie Test: beheer en produktie worden getest. Tijdens de accpetatie-tests kunnen volgende problemen naar voren komen: • Flessehalswerking van de PAT-omgeving. Er is geen tijd meer voor het herstellen van de geconstateerde bevindingen. Om dit te voorkomen dient de ‘als-het-ware-produktie’ omgeving veel eerder in het proces beschikbaar te zijn. •

Starheid van het rekencentrum. Dit is een onmisbaar onderdeel in de ‘als-het-ware-produktie’ omgeving en vormt de verzekeringspremie voor de beheersbaarheid van de informatievoorziening. In testteamverband wordt aanbevolen de functie technische ondersteuning door een medewerker van het rekencentrum te laten invullen.

•

Bestel- en planningsmoment van de testomgeving ligt vaak op het moment dat er nog weinig bekend is over de samenstelling en planning ervan. Hierover dienen vooraf afspraken gemaakt te worden met leveranciers en derdern.

25.2.2 Variaties Combinatie systeem- en FAT-omgeving (de geïntegreerde omgeving) Tijdens de systeemtest controleert de ontwikkelaar de functionele kwaliteit van het systeem, tijdens de functionele acceptatietest doet de acceptatietester hetzelfde. Door de acceptatietestgevallen in eerste instantie in de systeemomgeving te laten uitvoeren, kan een belangrijke optimalisatie gerealiseerd worden. Door toepassing van deze aanpak worden fouten vroeger gevonden en kan er voor de acceptatietestgevallen gebruik gemaakt worden van geavanceerde testtools. Ook kunnen er meestal tests parallel worden uitgevoerd.

Inrichten naar testvormen De inrichting en de beschikbaarstelling van de testomgeving dient gerelateerd te worden aan de testvorm, dus eigenlijk rechtstreeks aan de kwaliteitsattributen. Aangemaakt d.d.

27-12-2011

Pagina 79



Het vraagt veel organisatie- en overredingskracht voor het testmanagement, zeker op het gebied van verantwoordelijkheden en functiescheiding. Staat normaal de ‘eigenaar’ van de omgeving centraal, nu staat de “test” centraal.

25.3 Keuzen en overwegingen Testvorm stress middelengebrui k produktie herstel beveiliging functionaliteit standaards controls interfaces

Kwaliteitsattribuut bedrijfszekerheid, continuïteit zuinigheid juistheid, bedrijfszekerheid onderhoudbaarheid beveiliging, geoorloofdheid juistheid, volledigheid beveiliging, bruikbaarheid juistheid, controleerbaarheid juistheid, volledigheid

Omgeving ‘als-het-ware-produktie’ ‘als-het-ware-produktie’ ‘als-het-ware-produktie’ systeem, ‘als-het-ware-produktie’ ‘als-het-ware-produktie’ laboratorium, systeem, ‘als-het-ware-produktie’ systeem, ‘als-het-ware-produktie’ ‘als-het-ware-produktie’ laboratorium, systeem, ‘als-het-ware-produktie’

Inrichtingsfactoren bij testomgevingen • • • • • • • • • • • • • •

testsoort; testvorm; eisen aan de omgeving; beschikbare testomgevingen; standaards; platform (architectuur van hardware en software); organisatie van de systeemontwikkeling; type toepassing; datacommunicatie, decentrale verwerking; begrenzing van de test; budget; geografische locatie; gebruik van testtools; beschikbaarheid van testware.

25.4 Faciliteiten voor opbouw en gebruik van bestanden 25.4.1 Opbouwen van bestanden •

Opbouwen met reguliere systeemfuncties heeft als nadeel dat die functies zelf vaak nog niet uitputtend zijn getest en dat de ingevoerde gegevens derhalve grondig gecontroleerd moeten worden. Het voordeel is dat tijdens het opbouwen van de bestanden de reguliere functies gelijktijdig (impliciet) worden getest.

•

Opbouwen met aparte laadprogrammatuur heeft als nadeel dat allerlei 'onmogelijke situaties' ineens mogelijk zijn, omdat er geen controle is op de invoer. Dit betekent dat bij de opbouw technische ondersteuning nodig is en er uiteraard (aan een test onderworpen) laadprogrammatuur beschikbaar moet zijn. Het voordeel is dat de bestanden relatief snel kunnen worden opgebouwd.

•

Converteren van produktiegegevens heeft als nadeel dat weliswaar met veel gegevens wordt getest, maar dat deze gegevens onderling niet echt wezenlijk verschillen. Met produktiegegevens wordt vooral het zogenaamde 'goed-pad' getest, maar niet of nauwelijks het zogenaamde 'fout-pad'. Daarnaast is niet altijd bekend welke testsituaties de gegevens dekken. Tevens is het beslag op de schijfruimte vaak een veelvoud van hetgeen noodzakelijk is. Een ander nadeel is dat het niet altijd is toegestaan (wegens privacywetgeving, fraudegevoeligheid) met produktiegegevens te werken. Hierdoor is het noodzakelijk om identificerende gegevens te verminken of te coderen. Het voordeel is dat de bestanden snel kunnen worden opgebouwd en dat impliciet de eventuele conversieprogrammatuur wordt getest.

Aangemaakt d.d.

27-12-2011

Pagina 80



Los van planningstechnische en budgettaire perikelen, heeft het eerste alternatief de voorkeur.

25.4.2 Gebruik van bestanden •

Bij cumulatieve opbouw groeien de bestanden met de tests mee. Er worden naar behoefte nieuwe testgegevens opgevoerd en vervolgens gemuteerd, enzovoort. Dit geeft enerzijds de testers veel vrijheid en flexibiliteit maar anderzijds zullen de gegevens snel vervuilen en zal de vraag naar opslagcapaciteit snel groeien. Om deze nadelen te reduceren zijn adequate beheersinstrumenten noodzakelijk;.

Aangemaakt d.d.

27-12-2011

Pagina 81



•

Een tweede strategie is het periodiek terugzetten van een verzameling basisgegevens, bijvoorbeeld per dag of per week. Elke test wordt gebaseerd op die gegevens. Om het afvoeren van een gegeven te testen wordt het opvoeren van dat gegeven eerst opgenomen, enzovoort. Een speciale beheerprocedure voorziet in het structureel toevoegen van een gegeven aan de basisverzameling. Een groot voordeel is de beheersbaarheid van de gegevens, maar een nadeel zijn de afhankelijkheid van het verfrissingsmoment en het extra werk om tot de relevante testsituatie te komen. Dit laatste kan echter met behulp van een record & playbacktool worden versneld (zie hoofdstuk 26).

•

Een derde mogelijkheid is het gebruik van meerdere parallele versies van de gegevens. Elke tester heeft zijn eigen systeem en gegevensverzamelingen. Soms kan worden volstaan met slechts een gedeeltelijke 'privé' beschikbaarheid, terwijl andere gegevens gemeenschappelijk gebruikt kunnen worden. Voordeel van deze aanpak is de parallelliteit van de tests. Dat levert enorme tijdwinst op. Een ander voordeel is tevens een belangrijk nadeel, de onafhankelijkheid van de tests voorkomt weliswaar dat testers elkaar in de wielen rijden, maar door het isolement van de tests komen integrale testaspecten pas laat aan de orde.

•

Tip: Bij alles wat met de bestelling, de inrichting, de installatie en het gebruik van testomgevingen te maken heeft, is het raadzaam het personeel te betrekken van de organisatie die u de testomgevingen moet leveren (meestal het rekencentrum). Huur ze desnoods in. U kunt niet zonder de specifieke kennis van de infrastructuur en de procedures. Het ontbreken daarvan kost veel tijd en geld.

26. Testtools 26.1 Inleiding De kritische succesfactor voor het gebruik van CAST, Computer Aided Software Testing, is de aanwezigheid van een gestructureerde testaanpak en organisatie. Vanuit de gestructureerde testaanpak en de corresponderende technieken dient de implementatie van een of meer testtools gestalte te krijgen. De meeste testtools sluiten echter niet voldoende aan bij een gestructureerde testaanpak,

26.2 Testtools nader bezien Gezien de huidige status van testtools is ondersteuning bij het testen met name mogelijk bij testuitvoering en in mindere mate bij testontwerp en testplanning. Voor White-box testen zijn meer en vooral meer bruikbare testtools beschikbaar dan voor Black-box testen.

26.3 Voordelen Onder voorwaarde dat testtools worden gebruikt in combinatie met een gestructureerde testaanpak kunnen de voordelen behoorlijk van omvang zijn aangezien het toepassingsgebied van de meeste testtools, zijnde testuitvoering, veelal zo’n 40% van de totale testinspanning vergt.

26.4 Valkuilen CAST kan ertoe bijdragen dat de kwaliteit van de software en het testproces wordt verbeterd en een hogere produktiviteit wordt bereikt, maar is niet DE oplossing voor alle problemen. De meerderheid van ontwikkelaars, testers en managers zijn niet uitgerust met specifieke kennis van het gestructureerd testen en testtechnieken. Met behulp van ongestructureerd testen is het onmogelijk de kwaliteit van het informatiesysteem vast te stellen. Het is immers onmogelijk iets betrouwbaar te meten als het meetinstrument niet voldoende betrouwbaar is. Tools zullen niet de gewenste verbeteringen tot gevolg hebben indien ongestructureerd wordt getest. Met name als de testactiviteiten onder grote tijdsdruk moeten worden uitgevoerd, moeten de principes van het gestructureerd testen worden gehandhaafd. Op deze momenten zal de werkelijk management committent blijken.

26.5 Overzicht testtools Planning en beheer • Begroting Aangemaakt d.d.

27-12-2011

Pagina 82


• • • •


• Functiepuntanalyse • Testpuntanalyse Bevindingenadministrtatie Configuratie management Planning Voortgangsbewaking

Opbouw en uitgangsbestanden • Input generator • Testdata generator Testuitvoering • Compilers • Debugger • Record & playback • Simulator • Testdriver Beoordeling • Comparator • Static analyzer (verificatie tool) • Testcoverage tool • Query talen • Monitoring tools

27. Kantoorinrichting Een van de aspecten die bij het testen vaak wordt vergeten, is het beschikbaar stellen van een effectieve en efficiënte kantoorinrichting voor de testteams. Het gaat hierbij om kantoorinrichting in de breedste zin, ook de testers moeten hun werk onder goede omstandigheden kunnen uitvoeren.

Kantoorruimte Het testen wordt vaak op projectmatige basis uitgevoerd en dit houdt in dat er naast de beschikbare ruimte voor de normale (lijn) werkzaamheden, behoefte is aan extra kantoorruimte. Het is raadzaam het testteam in één kamer c.q. locatie onder te brengen. Indien het niet mogelijk is voor het testteam één kamer beschikbaar te stellen, dan dient de verdeling van de teamleden over verschillende kamers te zijn afgestemd op bijvoorbeeld de verdeling van de testers over de verschillende systeemdelen, de toe te passen testtechnieken en dergelijke. Binnen het testen wordt veelvuldig overleg gepleegd, enerzijds onderling, anderzijds met de diverse betrokken partijen. Het is dan ook noodzakelijk een aantal vergaderruimtes te reserveren, waar deze overleggen plaats kunnen vinden. Het is raadzaam, qua locatie, het testteam in de nabijheid van het bouwteam, de ontwerpers, het beheerteam, enzovoort te plaatsen.

Werkplekken Voor het opstellen en onderhouden van de testdocumentatie wordt gebruik gemaakt van PC's, terwijl voor de testuitvoering een terminal van bijvoorbeeld het mainframe of de AS/400 noodzakelijk is. Er dient te worden gezorgd voor een tijdige beschikbaarheid van de juiste PC-configuraties, netwerken en printers.

Toegangsregeling Er is binnen veel bedrijven een toegangsregeling voor de medewerkers. Houdt hier rekening mee.

Catering Ondanks een gestructureerde aanpak is er bij het testen, veelal tijdens de fase Uitvoering, sprake van grote werkdruk. Overwerk komt dan ook regelmatig voor, zodat het beschikbaar stellen van catering geen overbodige luxe is. Een hongerige tester wil immers eerder naar huis! Aangemaakt d.d.

27-12-2011

Pagina 83



Bijlage A - Voorbeeldberekening volgens TPA Een informatiesysteem heeft twee gebruikersfuncties en één interne logische gegevensverzameling: • Registreren: 11 functiepunten, met als onderliggende FPA-functies: Invoeren : 3 functiepunten Wijzigen : 4 functiepunten Verwijderen : 4 functiepunten • Verwerken: 12 functiepunten, met als onderliggende FPA-functies: Overzich t 1 : 5 functiepunten Overzich t 2 : 7 functiepunten De interne logische gegevensverzameling ‘gegevens’ heeft 7 functiepunten en wordt in het kader van testpuntanalyse toegerekend aan de invoerfunctie (Invoeren: 3 + 7 = 10 functiepunen) • Berekening totaal aantal testpunten Registreren Verwerken Functiepunten per functie FPf 18 12 (Totaal: 30 punten: FP⇒500 ) • Gebruikersbelang (Gb) 6 12 • Systeemdoorwerking (Sd) 2 2 • Complexitiet © 3 6 • Uniformiteit (U) 1 1

Af = ((Gb+Sd+C)/16)*U Direct meetbare kwal.attr. • Functionaliteit • Beveiliging • Inpasbaarheid • Performance • Gebruikersvriendelijkheid • Zuinigheid • Onderhoudbaarheid

0,69

1,25

expliciet 5→ 4→ 0 0

impliciet

J→ J→ J→ N

Qd = ∑ expliciet + ∑ impliciet

1,05 Registrere Verw erke n n TPf = FPf * Af * Qd 13 16 Totaal aantal directe testpunten ∑ TPf: 29 • • • • •

Flexibiliteit Testbaarheid Beveiliging Continuïteit Controleerbaarheid

N N J→ N N

Indirecte testpunten Qi Totaal aantal testpunten: TP = ∑ TPf + (FP * Qi) / 500 •

expliciet (5/4)*0,75 = 0,94 (4/4)*0,05 = 0,05

impliciet

0,02 0,02 0,02

0,99

0,06

8

8 37

8 (FP = 500, want: 30 < 500)

Berekening totaal aantal testuren

Produktiviteitsfactor (P) Testtools Ontwikkeltest Testbasis Ontwikkelomgeving Testomgeving Testware Totaal

Omgevingsfactor O = ∑ w aarden / 21 Primaire testuren: PT = TP * P * O Teamgrootte Beheerinstrumenten Aangemaakt d.d.

27-12-2011

1,5 4 4 3 4 1 4 20

0,95 52,73

53

3 4 Pagina 84



Opslagpercentage Planning en beheer (%) PT * opslag %: Opslag Planning en beheer Totaal aantal testuren: PT + Opslag Planning en beheer

7 53*0,07 53 + 3,71

3,71 56,71

4 57

Bijlage B - Checklists B1. Checklist testspecificatietechnieken Algoritmetest Bij een algoritmetest wordt de structuur van een algoritme getest. De gewenste testbasis is een stroomschema, beslissingstabel of een Nassi-Schneidermann diagram aangevuld met een beschrijving. De volgende checklist kan worden gehanteerd bij het controleren van de documentatie: • • • • •

Zijn de (programma) algoritmen beschreven in de vorm van een stroomschema, beslissingstabel of NassiSchneidermann diagram? Is de ‘trigger’ duidelijk aangegeven? (met andere woorden: wanneer moet het algoritme worden opgestart?) Is aangegeven welke gegevens worden gebruikt en uit welke bron deze komen? Is het resultaat van het algoritme duidelijk? Zijn de diverse beslispunten eenduidig en volledig beschreven met de daarbij behorende condities?

Beslissingstabellentest Met behulp van de beslissingstabellentest wordt op uiterst formele wijze de verwerking van een programma of functie getest. Deze testtechniek stelt zeer hoge eisen aan de kwaliteit van de testbasis. Bij het toepassen van deze techniek dient derhalve ruim aandacht te worden gegeven aan de detail intake testbasis. Bij de detail intake testbasis kan de volgende checklist worden gehanteerd voor het controleren van de aanwezige ontwerpspecificaties: • • • •

Zijn de ‘triggers’ van het proces duidelijk aangegeven? (Het gaat hierbij zowel om ‘triggers’ vanuit de gebruiker, een extern systeem of een interne functie c.q. programma.) Is de verwerking zodanig beschreven dat hierin de diverse ‘verwerkingspaden’ zijn te onderkennen? Zijn de determinanten (factoren) die het proces beïnvloeden duidelijk te onderkennen en eenduidig beschreven? Is de uitvoer van het proces duidelijk en is het mogelijk resultaten van te voren te voorspellen?

Dataflowtest Aangezien de dataflowtest een minder formele methode is, stelt deze techniek ook minder stringente eisen aan de testbasis. Bij de detail intake testbasis kan de volgende checklist worden gehanteerd bij het controleren van de aanwezige specificaties: • • • •

Zijn de diverse schermen printlayouts beschreven? Is de verwerking van de functies eenduidig beschreven inclusief beslispaden? Is de samenhang tussen de diverse functies beschreven? Is een dialoogontwerp (schermverloopschema’s en dergelijke) aanwezig?

Elementaire vergelijkingentest Het gaat hij de elementaire vergelijkingentest om de beschrijving van de (logische) verwerking van gegevens. Bij de beschrijving van de verwerking kan bijvoorbeeld gebruik zijn gemaakt van pseudo-code en/of beslissingstabellen. Bij de detail intake testbasis kan de volgende checklist worden gehanteerd bij het controleren van de aanwezige specificaties: • • • •

Is Is Is Is

de verwerking zodanig beschreven dat hierin de diverse ‘verwerkingspaden’ zijn te onderkennen? duidelijk onder welke condities (voorwaarden) een bepaald ‘verwerkingspad’ wordt doorlopen? de verwerking eenduidig beschreven inclusief invoer en uitvoer? voor alle ingevoerde rubrieken de verwerking beschreven?

Error Guessing Een specifieke beoordeling op bepaalde aspecten van de documentatie is niet noodzakelijk voor het kunnen uitvoeren van de Error Guessing test. Van belang is dat men op basis van de documentatie een goed begrip Aangemaakt d.d.

27-12-2011

Pagina 85



kan krijgen van het te testen (sub) systeem. Dit inzicht kan overigens ook worden verkregen door het uitvoeren van gestructureerde tests in samenhang met Error Guessing.

Gegevenscyclustest De gegevenscyclustest richt zich op de levensloop van gegevens. Een essentieel onderdeel van de testbasis wordt dan ook gevormd door de CRUD-matrix. Indien niet aanwezig moet deze worden opgesteld zodat de testspecificatie in het kader van de gegevenscyclustest kan worden uitgevoerd. De volgende checklist kan worden gehanteerd bij het controleren van de testbasis voor de gegevenscyclustest:

Aangemaakt d.d.

27-12-2011

Pagina 86

Uittreksel Titel: Testen volgens TMap • • • • • • •


Is er in de documentatie een CRUD-matrix aanwezig? Is het duidelijk in welke functie(s) een entiteit kan worden ingevoerd, geraadpleegd, gewijzigd en verwijderd? Kan elke entiteit worden ingevoerd, gewijzigd en verwijderd? Is er een beschrijving van de entiteiten aanwezig? Is er een entiteitenschema (ERD) aanwezig? Zijn de relaties tussen de diverse entiteiten volledig en eenduidig beschreven? Zijn bij de relaties ook de referentiële relatiecontroles beschreven?

Programma interfacetest De programma interfacetest richt zich op de interactie tussen twee programma’s c.q. modules. Als uitgangspunt geldt dat de te integreren programma 5 los van elkaar goed functioneren. Bij een programma interfacetest worden de gesimuleerde gegevensstromen vervangen door echte gegevensstromen. De volgende controles kunnen worden uitgevoerd op de testbasis in het kader van deze testtechniek: • • • • • •

Is de verwerking van de individuele programma’s eenduidig beschreven, inclusief invoer en uitvoer? Is aangegeven waar interfaces aanwezig zijn? Is de samenhang tussen de diverse programma’s beschreven? Is voor alle ingevoerde rubrieken de verwerking beschreven? Is van alle bij de interfaces betrokken entiteiten aangegeven welke attributen ertoe behoren? Zijn van de attributen de objectklasse, de definitie (range, toegestane waarden) en eventuele bijzondere geldigheidsregels beschreven?

Procescyclustest (Inpasbaarheid) De testbasis voor de procescyclustest bestaat veelal uit procedure-beschrijvingen en bijbehorende formulieren. Bij voorkeur zijn bij de procedurebeschrijvingen zogenaamde flow-charts toegevoegd. Bij de detail intake testbasis kan de volgende checklist worden gehanteerd bij het controleren van de aanwezige procedurebeschrijvingen: • • • • • • • • • • • • •

Zijn alle handmatige procedures die door gebruikers gevolgd dienen te worden om tot een goed gebruik van het systeem te komen, weergegeven in een procedureschema? Is een gedetailleerde beschrijving gemaakt van de handmatige procedures? Zijn de belangrijkste taakomschrijvingen beschreven, inclusief de verantwoordelijkheden en bevoegdheden? Is een beschrijving gegeven van de individuele taken? Zijn de beveiligingsaspecten van deze procedure beschreven? Is de ‘trigger’ duidelijk aangegeven? (met andere woorden: Wanneer moet de procedure worden opgestart.) Is aangegeven welke gegevens (formulieren) moeten worden gebruikt en uit welke bron deze komen? Zijn de uit te voeren handelingen volledig beschreven inclusief uitzonderingen en controles? Is het resultaat van de procedure duidelijk? Zijn de diverse beslispunten beschreven met de daarbij behorende condities? Is een onderscheid gemaakt tussen gebruikers- en beheerprocedures? Zijn de relaties tussen het geautomatiseerde en het niet-geautomatiseerde deel van het informatiesysteem beschreven? Is de gebruikershandleiding beschikbaar?

Real-life test (o.a. Performance en Zuinigheid) Alle documentatie met betrekking tot het operationeel gebruik van het systeem wordt verzameld, onder andere de tijdens de diverse systeemontwikkelfasen gespecificeerde systeemeisen. Met betrekking tot de real-life test dient bij de detail intake testbasis te worden beoordeeld of de aanwezige systeemdocumentatie in voldoende mate inzicht geeft in het toekomstige systeemgebruik. Hiervoor zijn onder andere van belang het aantal gebruikers, de intensiteit van gebruik en de dag-, week- en maandcycli. De volgende vragen kunnen expliciet onderdeel zijn van de intake in het kader van de real-life test: • • • • •

Zijn er specifieke eisen vastgesteld ten aanzien van de performance van on-line functionaliteit? Wordt er een onderscheid gemaakt tussen de responsietijd bij het opstarten van een functie en bij schermwisseling binnen een functie? Zijn er specifieke eisen vastgesteld ten aanzien van de performance van gegevensbenadering? Zijn er specifieke eisen vastgesteld ten aanzien van de performance van batch functionaliteit? Zijn er specifieke eisen gesteld aan het geheugenbeslag?

Aangemaakt d.d.

27-12-2011

Pagina 87



Zijn er normen van toepassing ten aanzien van het aantal database-calls per transactie? Zijn er normen van toepassing ten aanzien van maximale pagina- en buffergrootte? Zijn er specifieke eisen aan de omvang van applicatie en/of de database?

Aangemaakt d.d.

27-12-2011

Pagina 88



Semantische test (o.a. Beveiliging) Het gaat bij de semantische test met name om documentatie waarin invoercontroles op functieniveau, standaards ten aanzien van foutafhandeling op (sub)systeemniveau en eisen ten aanzien van de toegangsbeveiliging voor functies en/of gegevens zijn beschreven. Bij de detail intake testbasis kan de volgende checklist worden gehanteerd bij het controleren van de aanwezige specificaties: • • • • •

Zijn er standaards met betrekking tot foutafhandeling beschreven op (sub) systeemniveau? Zijn de invoercontroles (met name de relatiecontroles) inclusief bijbehorende foutboodschap beschreven als onderdeel van de functiebeschrijving en zijn deze uitvoerbaar? Zijn er specifieke eisen vastgelegd voor toegangsbeveiliging van functies en/of gegevens? Zijn gebruikersprofielen beschreven met betrekking tot beveiliging? Is beschreven welke eisen gesteld worden ten aanzien van identificatie (user-id) en authentificatie (wachtwoord)?

Syntactische test Tijdens de detail intake testbasis wordt de documentatie geselecteerd en beoordeeld die nodig is om de syntactische test ten aanzien van het systeem uit te kunnen voeren. Het gaat hierbij om schermlayouts, scherm-beschrijvingen, overzicht4ayouts, overzichtbeschrijvingen, aanwezige standaards op (sub) systeemniveau en het gegevensmodel. Voor de syntactische test kan bij de detail intake testbasis de volgende checklist worden gehanteerd: • • • •

• • • • • •

Zijn er van toepassing zijnde standaards beschreven op systeemniveau? Zijn er van toepassing zijnde standaards beschreven op subsysteemniveau? Zijn de lay-outs van de schermen beschreven? Is hierbij aandacht gegeven aan de volgende aspecten: • veldlengte van de rubrieken • plaats van de rubriek op het scherm • onderscheid invoer en uitvoer rubrieken • primaire invoercontroles (niet het gevolg van domein definitie) • foutafhandeling • verplichte en niet-verplichte rubrieken • mogelijke functietoetsen, helpschermen en selecties? Zijn de ‘schermrubrieken’ c.q. attributen opgenomen in het gegevensmodel? Zijn van de gebruikte attributen de definities (numeriek, alfanumeriek, datum) en de domeinen beschreven? Zijn de gespecificeerde verplichte en niet-verplichte rubrieken consistent met de optionaliteit uit het gegevensmodel? Voldoen de beschreven scherm-layouts aan de standaards? Zijn de lay-outs van de overzichten beschreven? Is hierbij aandacht gegeven aan de volgende aspecten: • veldlengte van de rubrieken • plaats van de rubriek op het overzicht? • Zijn de ‘overzicht-rubrieken’ c.q. attributen opgenomen in het gegevensmodel? • Voldoen de beschreven overzichtlay-outs aan de standaards?

Aangemaakt d.d.

27-12-2011

Pagina 89



B2. Checklist black-box test Algemeen • • • • • • • • • • • •

Komt de inhoudsopgave van de opgeleverde documentatie overeen met de inhoud? Is een logisch datamodel aanwezig? Is de logische gegevensstructuur beschreven? Is een mogelijke implementatie van de gegevensstructuur aangegeven? Heeft een verdeling plaatsgevonden van het systeem in deelsystemen? Zijn er specificaties gegeven van de interfaces? Zijn alle functies en subfuncties gedetailleerd en eenduidig beschreven? Zijn er schermverloop-schema’s (dialoog ontwerp) aanwezig? Is de in- en uitvoer per functie beschreven? Zijn de lay-outs van de schermen en lijsten aanwezig? Zijn er specificaties gegeven van de benodigde hard- en software? Is een planning voor de verdere ontwikkeling aanwezig?

Logisch datamodel • • •

Is een entiteitenschema aanwezig? Zijn alle opgesomde entiteiten en relaties opgenomen in het schema? Zijn de relaties tussen de datamodellen van de verschillende deelsystemen beschreven?

Logische gegevensstructuur • • • • • • • • • • • • •

Zijn alle getekende entiteiten en relaties opgesomd? Is van alle in het datamodel opgenomen relaties (ook die met andere (deel) systemen) een beschrijving aanwezig? Is per relatie de soort beschreven? Is van alle entiteiten aangegeven welke attributen ertoe behoren? Zijn van de attributen de beveiligings- en privacy-aspecten beschreven? Is in de opsomming van de attributen die deel uitmaken van een entiteit aangegeven welke de sleutelgegevens zijn? Zijn van de attributen de objectklasse, de definitie (range, toegestane waarden) en eventuele bijzonderheden beschreven? Zijn er homoniemen en/of synoniemen aanwezig? Zijn van de attributen de herkomst en de eigenaar aangegeven? Zijn van de attributen de integriteitseisen vermeld? Zijn de gewenste toegangspaden aangegeven? Is de wijze van implementeren, inclusief mogelijke alternatieven, beschreven? Zijn mogelijke probleemgebieden aangegeven en de nog niet opgeloste punten van de conversieproblematiek beschreven?

Indeling in deelsystemen en interfaces • • • • • • •

Zijn in de beschrijving van de gekozen deelsystemen een korte beschrijving van de uit te voeren functies, de benodigde processen en de gegevens opgenomen? Is de volgorde van implementatie aangegeven? Is aangegeven waar interfaces aanwezig zijn? Is duidelijk wie met betrekking tot een interface eigenaar is en wat de beveiligingseisen zijn? Is er een beschrijving aanwezig (van de samenstelling) van de interface? Is er een beschrijving aanwezig van de fysieke realisatie? Zijn de activiteiten die nog moeten worden uitgevoerd ten behoeve van de fysieke realisatie beschreven en opgenomen in de planning?

Aangemaakt d.d.

27-12-2011

Pagina 90



Functiestructuur • • • • • • • •

• • • • • • • • • •

Zijn alle functies weergegeven, bijvoorbeeld in dataflow diagrammen? Is een korte beschrijving gegeven van de functie? Zijn de condities waaronder de uitvoering plaatsvindt vermeld inclusief de frequentie? Is aangegeven of het handmatige of te automatiseren functies zijn? Is van de te automatiseren functies vermeld of deze on-line of in batch uitgevoerd gaan worden? Zijn de beveiligingseisen beschreven? Zijn de maatregelen beschreven die worden genomen in het kader van de juistheid en de volledigheid van de gegevens, bijvoorbeeld: • validaties van de invoer (verbandscontroles, referentiële controles) • redundante invoer (controletotalen) • dubbele invoer • geprogrammeerde controles op de resultaten van de gegevensverwerking • doornummeren van transacties en rapportages? Zijn de performance-eisen beschreven? Is het relatieve belang van de functie ten opzichte van andere functies beschreven? Is er een cross-reference aanwezig tussen de functies en de schermverloop-schema’s? Is er een korte beschrijving aanwezig van de gegevensstromen? Is er een cross-reference aanwezig tussen de functies en de in- en uitvoerstromen? Is van elke invoer de bron vermeld en beschreven? Is van elke uitvoer de bestemming vermeld en beschreven? Is aangegeven welke organisatorische eenheid of welk informatiesysteem het betreft? Zijn alle elementaire functies opgenomen in een dataflow diagram? Is de verwerking duidelijk c.q. eenduidig beschreven?

Beschrijving schermverloop inclusief lay-out • • • • • • • • • •

Is een overzicht gegeven van de relaties tussen functies en schermen? Is de structuur van het schermverloop beschreven? Voldoen de schermen aan de daarvoor geldende richtlijnen? Is de scherminvoer beschreven? Is de schermuitvoer beschreven? Zijn de schermcontroles beschreven? Is het gebruik van functietoetsen beschreven? Is een beschrijving van het gebruik van de HELP4uncties aanwezig? Is het gebruik van attributen beschreven? Is een beschrijving van de schermen printlayout aanwezig?

Specificatie van de benodigde hard- en software •

Zijn voor de produktie-omgeving de benodigde hardware, systeemsoftware, netwerk en communicatieapparatuur in capaciteit en aantallen, vermeld?

Kwaliteitseisen •

•

Zijn de aan het te realiseren informatiesysteem gestelde kwaliteitseisen c.q. prestatie-eisen gespecificeerd? (met name is dit van belang voor de kwaliteitsattributen die zijn opgenomen in de teststrategie> Zijn de kwaliteitseisen zodanig gespecificeerd dat deze meetbaar zijn en gebruikt kunnen worden als acceptatiecriteria?

Aangemaakt d.d.

27-12-2011

Pagina 91



B3. Checklist white-box test Algemeen • • • • •

Komt de inhoudsopgave van de opgeleverde documentatie overeen met de inhoud? Is een beschrijving aanwezig van de fysieke database? Zijn de systeembeveiligingen beschreven? Is het systeemskelet weergegeven? Heeft een programmaverdeling plaatsgevonden?

Ontwerp van de fysiek database • • • • • • • • •

Is Is Is Is Is Is Is Is Is

de argumentatie van de gekozen oplossing beschreven? de fysieke database weergegeven in een entity-relationship diagram? een beschrijving aanwezig van record lay-out toegangspaden. een vergelijking gegeven van het logische datamodel met het fysieke datamodel? van de fysieke database de omvang gegeven in maxima, minima en gemiddeld? de Organisatie rond de fysieke database beschreven? de volgorde (sortering) beschreven? de bestandsorganisatie beschreven? de bestandsbeveiliging beschreven rekening houdend met eventuele eisen uit privacy overwegingen?

Systeembeveiliging •

•

•

Zijn de maatregelen beschreven van de volgende risicogebieden: • abnormale beëindiging van een job • systeemuitval • fouten in de gegevensverzameling • herstelbaarheid (herstart en recovery) • toegangsbeveiliging? Zijn maatregelen beschreven ten aanzien van: • continuïteit • integriteit • privacy • traceerbaarheid (audit-trail)? Zijn de afwijkingen van de normale procedures beschreven?

Systeemskelet •

Is het systeemskelet van het subsysteem weergegeven, om van daaruit te komen tot de programmaverdeling?

Programmaverdeling • •

Zijn alle programma’s weergegeven in de vorm van een systemflow? Zijn van alle programma’s in de systemflow beschreven: • de naam van het programma • de invoer en uitvoer • de verwerking?

Programmabeschrijving Zijn bij de diverse programmabeschrijvingen de navolgende aspecten volledig en eenduidig beschreven: • de identificatie en doel van het programma • de beschrijving van de functie/transactie(s) • de beschrijving van de invoeren uitvoerstromen • de beschrijving van de koppeling naar andere programma’s c.q. (sub> systemen • de beschrijving van de buffers en bestanden • de beschrijving van de sleutelgegevens • de beschrijving van de mogelijke sorteringen • de beschrijving van de parameters (inclusief de controle) • de beschrijving van de logging • de beschrijving van de akkoord- en eindhandeling • de schematische weergave van het programma • de bij het schema behorende beschrijving van het programma met daarin de aangeroepen secties en paragrafen en de gebruikte standaard routines.

Aangemaakt d.d.

27-12-2011

Pagina 92



Prestatie-eisen • •

Zijn de prestatie-eisen gespecificeerd? (met name is dit van belang voor de kwaliteitsattributen die zijn opgenomen in de teststrategie) Zijn de prestatie-eisen zodanig gespecificeerd dat deze meetbaar zijn?

Aangemaakt d.d.

27-12-2011

Pagina 93



B4. Checklist Beheerbaarheid Definitie Beheerbaarheid Het gemak waarmee het informatiesysteem in operationele staat kan worden gebracht en gehouden.

Verwerkingsorganisatie + + + +

Is geanalyseerd of ten behoeve van het nieuwe of gewijzigde informatiesysteem aanvullende opleidingen noodzakelijk zijn? Is er een adequate procedure in geval van storing? Is er een verzekering aanwezig voor de apparatuur en dergelijke? Is er een calamiteitenplan aanwezig?

Functionele systeemarchitectuur + + + + +

Is er een beknopte functionele beschrijving beschikbaar? Is de keuze voor deelsystemen beargumenteerd? Zijn er richtlijnen voor het beperken van de toegang tot applicaties? Wordt gebruik gemaakt van ‘passwords’? Worden de toegangspogingen gecontroleerd?

Technische systeemarchitectuur + + + + + +

+ + + + + +

+ + + + + + + + + − − −

Worden automatische back-ups vervaardigd? Zijn controleprocessen (‘watchdogs’) aangebracht? Zijn de invoer; verwerking en uitvoer apart geïmplementeerd? Kan de operator status informatie verschaffen? Wordt door middel van de juiste transactiegrootte en roll-back-faciliteiten voor de consistentie van de gegevens zorg gedragen? Is gebruik gemaakt van geldende (inter)nationale standaards of bedrijfsstandaards? Bijvoorbeeld voor gegevensuitwisseling via netwerken (OSI), applicaties in de IBM-omgeving (SAA) en een standaard programmeertaal? Wordt gebruik gemaakt van een standaard machine-interface? Zijn de standaardhandelingen consistent in de interface ingebouwd? Is er een beschrijving aanwezig van de bij installatie noodzakelijke materie-applicaties en standaard modules (inclusief versienummers)? Is gebruik gemaakt van standaard naamgevingen? Kunnen alle (ook niet-logische) functies minimaal één keer worden aangestuurd? Is er een back-up en recovery systeem bestaande uit procedures en programmatuur voor: • het periodiek veiligstellen van een samenhangende set kopieén van de gegevensverzamelingen; • logging van alle transacties vanaf de laatste veiligheidskopieën; • het eventueel opnieuw uitvoeren van alle gelogde transacties? Is bij het opstellen van de back-up procedure vastgesteld wanneer bestanden/databases veilig gesteld moeten worden en hoelang de betreffende back-ups bewaard moeten blijven? Is het mogelijk een applicatie opnieuw te starten na een systeemuitval? Is het mogelijk een applicatie opnieuw te starten na een applicatiestoring? Is een beschrijving aanwezig van de noodzakelijke autorisaties? Is er een procedure aanwezig voor het onderhouden van de autorisaties? Is er een beveiligingspakket (bijvoorbeeld RACF) aanwezig? Zijn er specifieke normen en standaards aanwezig in het kader van invoer; batch verwerking, on-line verwerking, uitvoer en beveiliging? Wordt aan deze specifieke normen en standaards voldaan? Vindt registratie, bijvoorbeeld logging, plaats van alle verwerkingen? Wordt de gegevensverwerking dubbel uitgevoerd? Zijn de deelsystemen gedeconcentreerd? Is de programmatuur]r geparametriseerd?

Gegevensinfrastructuur + − −

Is er documentatie betreffende het datamodel aanwezig en is deze consistent? Zijn de gegevensbestanden versleuteld? Is de gegevensopslag gedeconcentreerd?

Aangemaakt d.d.

27-12-2011

Pagina 94



Fysieke beveiligingsmaatregelen + + + +

Hebben het bedrijfsterrein en de gebouwen een gecontroleerde toegang? Zijn maatregelen genomen inzake het voorkomen, signaleren en opvangen van technische storingen en calamiteiten? Wordende back-ups van vitale gegevens op een aparte locatie bewaard in een extra beveiligde omgeving, hij voorkeur buiten het rekencentrum? Is het rekencentrum alleen toegankelijk voor het personeel van het rekencentrum?

Produktie-omgeving + + + + + +

+ + + + +

Is er een tweede set van apparatuur en dergelijke aanwezig waarop (delen van) het informatiesysteem kan uitwijken? Is er een beschrijving beschikbaar van de infrastructurele hardware en software componenten? Zijn er specifieke normen en standaards vanuit de verwerkingsorganisatie aanwezig in het kader vin zuinigheid, extern geheugen en performance? Wordt aan (deze specifieke normen en standaards voldaan? Is er een produktiehandleiding? Zijn de navolgende elementen aanwezig in de produktiehandleiding? • een inleiding met de recapitulatie van namen, identificaties en karakteristieken van de functie van het systeem en de subsystemen; • een schematische voorstelling van de systeemstructuur; • een relatieschema van de runstructuur met per run: het tijdstip, de program ma’s, de indicatieven per programma en de tijdschatting; • de gegevens van de contactpersonen (naam, afdeling, telefoonnummer); • per uit te voeren run de volgende gegevens: naam, identificatie, karakteristieken, systeemstroomschema en/of subsysteemstroomschema, waarbij de gegevensstromen gerelateerd zijn aan de onderdelen van de configuratie en waaruit de interfaces met de niet tot de run behorende systemen en/of subsystemen blijken; • ontvangst en voorbewerking met daarin beschreven: de soort, de bron en het tijdstip van de ontvangst; de ontvangst handelingen en de controles; de gegevensconversie, de instructies en de controles; de bestemming en de afgiftehandelingen van invoermedia; de bestemming en de afgiftehandelingen van basisdocumenten; • produktievoorbereiding met daarin beschreven: het tijdschema; de beschrijving van de werkprocedure (‘jobstream’); de schema’s voor behandeling van verwisselbare geheugens en bewaarinstructies; het aanleveren van de invoer; • bedieningsinstructies met daarin beschreven: de algemene bedieningsinstructies; de bedienings-, controle- en foutmeldingen met de bijbehorende instructies; de onderbrekingsmogelijkheden; de herstartinstructies bij ongewenste onderbrekingen; • produktie-afhandeling met daarin beschreven: de behandeling van de verwisselbare geheugens; de controles en de rapportering; de nabewerking; de bestemming en de distributie; het uiterste aanlevertijdstip Is er een, op basis van het nieuwe of gewijzigde informatiesysteem, aangepaste produktieplanning? Is vastgesteld hoe incidentele batchwerkzaamheden aangevraagd en ingepland moeten worden? Is er een geïntegreerde testfaciliteit aanwezig? Is een courante infrastructuur gebruikt? Heeft een gedetailleerde analyse plaatsgevonden van de benodigde verwerkingscapaciteit, opslagcapaciteit, datacommunicatie apparatuur en systeemprogrammatuur?

Aangemaakt d.d.

27-12-2011

Pagina 95



B5. Checklist Beveiliging Definitie Beveiliging Zekerheid dat raadpleging of mutatie van de gegevens uitsluitend mogelijk is door die personen die daartoe bevoegd zijn.

Verwerkingsorganisatie +

Is de verwerking van vertrouwelijke gegevens (bijvoorbeeld de salarisrun) in aparte procedures ondergebracht, die alleen door daartoe bevoegde personen mogen worden uitgevoerd?

Gebruikersorganisatie + + + + + + +

+

+ + + + + + +

Is sprake van een duidelijk scheiding van functies, bevoegdheden en verantwoordelijkheden in de organisatie van de informatievoorziening? Is een indeling gemaakt van documenten in een aantal klassen van vertrouwelijkheid? Is op basis van deze indeling een beperking (en registratie) van de circulatie van geclassificeerde documenten tot bepaalde functionarissen geregeld? Is er een autorisatieprocedure voor belangrijke documenten die de organisatie verlaten? Is er sprake van controle achteraf namens de interne accountantsdienst op de uitvoering van de procedures aan de hand van geproduceerde informatie? Wordt bij de beveiliging zowel aandacht gegeven aan de schriftelijke als de geautomatiseerd vastgelegde gegevens? Wordt bij het verlenen van autorisatie de controletechnische functiescheiding gehandhaafd; wordt autorisatie verstrekt op basis van het need-todo’ en ‘need-to- know’ principe? (Sluit de logische toegang aan op de aanwezige AO-schema’s?) Is functiescheiding aangebracht tussen: • degene die gerechtigd zijn om functies binnen een informatiesysteem te gebruiken om gegevens te kunnen benaderen en/of te kunnen muteren (eindgebruikers); • degene die bepaalt welke medewerkers toegang hebben tot welke functies (gegevens> en aan wie verantwoording moet worden afgelegd over de gerealiseerde toegangsmogelijkheden; • degene die verantwoordelijk is voor het daadwerkelijk autoriseren van de medewerkers tot functies (gegevens)? Wordt bij het verlenen van autorisatie een onderscheid gemaakt tussen de verantwoordelijkheden voor invoering, verwerking, correctie en controle? Wordt bij het verlenen van autorisatie een onderscheid gemaakt tussen het invoeren, het wijzigen, het raadplegen en het verwijderen van gegevens? Wordt bij het verstrekken van gegevens (aan derden) en externe datacommunicatie rekening gehouden met de eisen van logische toegangsbeveiliging? Is er een specifieke autorisatieprocedure aanwezig voor functionarissen belast met interne controle en/of beveiliging (bijvoorbeeld de systeembeheerder)? Is de wijze waarop de logische toegangsbeveiliging is gerealiseerd adequaat beschreven? Is een procedure waarin de diverse acties zijn beschreven die dienen te worden uitgevoerd op basis van de toegangslogging c.q. de rapportage? Valt het informatiesysteem onder de Wet Persoonsregistraties? Zo ja, is aan de wettelijke verplichtingen voldaan?

Aangemaakt d.d.

27-12-2011

Pagina 96



Technische systeemarchitectuur + + + + + + + + + + + + − −

Worden de mogelijkheden die bestaan om de toegang tot de (systeem) software, teksten en bestanden te beperken zo goed mogelijk benut? Zijn binnen de toegangsbeveiliging de functionaliteiten ten behoeve van identificatie, authentificatie, autorisatie en rapportage te onderkennen? Worden de wachtwoorden door de gebruikers zelf onderhouden en is de gebruiker zelf verantwoordelijk voor het gebruik van zijn user-id en wachtwoord? Is er een (technische> procedure aanwezig die ervoor zorgt dat wachtwoorden periodiek worden gewijzigd? Heeft het wachtwoord een minimale lengte van zes tekens en is het mogelijk voor de samenstelling van het wachtwoord gebruik te maken van alle op het toetsenbord aanwezige tekens? Is er sprake van een maximaal aantal mogelijke pogingen om in te loggen? Vindt de invoer en eventueel de uitvoer (vastlegging) van wachtwoorden op een dusdanige wijze plaats dat daaruit geen herkenning voor derden kan plaatsvinden? Wordt de toegangsbeveiliging niet doorbroken door het gebruik van query-talen? Worden door middel van logging de onjuiste pogingen tot het gebruik geregistreerd? Zijn er maatregelen genomen die ervoor zorgen dat de periode waarin de terminal vrij toegankelijk is wordt beperkt (bijvoorbeeld automatische ‘log-off’)? Is er ten behoeve van de beveiliging een specifiek pakket aanwezig en in gebruik? Wordt het geheugen na gebruik leeggemaakt? Zijn de deelsystemen gedeconcentreerd? Wordt de gegevensverwerking dubbel uitgevoerd?

Gegevensinfrastructuur + + −

Zijn de gegevensbestanden versleuteld? Worden de gegevens die over het netwerk worden verstuurd versleuteld? Is de gegevensopslag gedeconcentreerd?

Fysieke beveiligingsmaatregelen + +

Hebben het bedrijfsterrein en de gebouwen een gecontroleerde toegang? Is het rekencentrum alleen toegankelijk voor het personeel van het rekencentrum?

Produktie-omgeving +

Wordt ten behoeve van de testomgeving en de produktie-omgeving gebruik gemaakt van een verschillende identificatie (user-id) en authentificatie (wachtwoord)?

Aangemaakt d.d.

27-12-2011

Pagina 97



B6. Checklist Connectiviteit Definitie Connectiviteit Het gemak waarmee een koppeling met een ander informatiesysteem of binnen het informatiesysteem tot stand kan worden gebracht en kan worden gewijzigd

Functionele systeemarchitectuur + +

Is gebruik gemaakt van een algemeen referentiemodel? Is de keuze voor deelsystemen beargumenteerd?

Technische systeemarchitectuur +

+ +

Is gebruik gemaakt van geldende (inter) nationale standaards bijvoorbeeld voor gegevensuitwisseling via netwerken (OSI), applicaties in de IBM-omgeving (SAA) en een standaard programmeertaal die op een grote verscheidenheid van apparatuur gecompileerd kan worden? Is gebruik gemaakt van een standaard machine-interface? De connectiviteit wordt mede bepaald door de onderhoudbaarheid ten aanzien van de technische systeemarchitectuur (zie checklist onderhoudbaarheid)

Gegevensinfrastructuur + + − −

Zijn data afgestemd op een bedrijfsgegevensmodel? Is het gegevensmodel genormaliseerd? Is het gegevensmodel geparametriseerd? Zijn de gegevensbestanden versleuteld?

Produktie-omgeving + +

Worden ten behoeve van de interne connectiviteit infrastructuurcomponenten gebruikt die zijn afgestemd op de reeds aanwezige infrastructuur? Is een courante infrastructuur gebruikt?

Aangemaakt d.d.

27-12-2011

Pagina 98



B7. Checklist Continuïteit Definitie Continuïteit De zekerheid dat de gegevensverwerking ongestoorde voortgang zal kunnen vinden, dat wil zeggen ook na ernstige storingen binnen redelijke termijn kan worden hervat. Het kwaliteitsattribuut Continuïteit kan worden uitgesplitst in attributen die achtereenvolgens van toepassing zijn bij toenemende verstoring van het informatiesysteem:

1. Bedrijfszekerheid Definitie Bedrijfszekerheid: De mate waarin de gegevensverwerking vrij blijft van storingen.

Verwerkingsorganisatie + +

Is een doelmatig produktieschema opgezet met een afgewogen bepaling van de prioriteiten tussen de toepassingen onderling en met de ondersteunende functies, zoals bijvoorbeeld de back-up procedure? Zijn binnen de verwerkingsorganisatie plaatsvervangers beschikbaar en opgeleid?

Gebruikersorganisatie + +

Zijn binnen de gebruikersorganisatie plaatsvervangers beschikbaar en opgeleid? Is binnen de gebruikersorganisatie de beveiliging goed geregeld? (zie checklist beveiliging)

Functionele systeemarchitectuur + + + +

Wordt de invoer gecontroleerd? Wordt gebruik gemaakt van passwords? Worden de toegangspogingen gecontroleerd? Is de keuze voor deelsystemen beargumenteerd?


+ + + + + + + + + − − − −

Is gebruik gemaakt van geldende (inter)nationale standaards bijvoorbeeld voor gegevensuitwisseling via netwerken (OSI), applicaties in de IBM-omgeving (SAA) en een standaard programmeertaal die op een grote verscheidenheid van apparatuur gecompileerd kan worden? Is er ten behoeve van de beveiliging een specifiek pakket aanwezig en in gebruik? Zijn de invoer, verwerking en uitvoer apart geïmplementeerd? Wordt door middel van de juiste transactiegrootte en roll-back-faciliteiten voor de consistentie van de gegevens zorg gedragen? Wordt de gegevensverwerking dubbel uitgevoerd? Is de dataverwerking in deeltransacties opgesplitst? Kan de operator status informatie verschaffen? Zijn controleprocessen (‘watchdogs’) aangebracht? Zijn de deelsystemen gedeconcentreerd? Worden de programmamodules hergebruikt? Wordt gebruik gemaakt van technische handelingen in de interface? Is de programmatuur geparametriseerd? Zijn de algoritmen geoptimaliseerd uit bijvoorbeeld performance overwegingen? Wordt de gebruikersinvoer automatisch aangevuld?


Vindt een periodieke geprogrammeerde consistentiecontrole plaats van de database en de gegevensverzamelingen? Is de gegevensopslag gedeconcentreerd? Zijn de gegevensbestanden versleuteld?

Fysieke beveiligingsmaatregelen + + +

Hebben het bedrijfsterrein en de gebouwen een gecontroleerde toegang? Is het rekencentrum alleen toegankelijk voor het personeel van het rekencentrum? Is het verwerkingscentrum c.q. het rekencentrum gehuisvest in een gebouw dat optimaal is beveiligd tegen blikseminslag, brand, stroomstoring, stormschade en waterschade?

Ontwikkelomgeving +

Wordt van 4 GL faciliteiten gebruik gemaakt?

Aangemaakt d.d.

27-12-2011

Pagina 99




+

+ +

Zijn apparatuur, netwerk, PC’s, systeemsoftware en DBMS geselecteerd die op elkaar en op de toepassingen zijn afgestemd? Zijn bij de selectie van apparatuur en dergelijke leveranciers geselecteerd waarvan verwacht mag worden dat zij gedurende de gehele levensduur van het informatiesysteem een adequate ondersteuning zullen bieden? Heeft een objectieve bepaling plaatsgevonden van de benodigde hoeveelheid verwerkingscapaciteit en opslagcapaciteit die het informatiesysteem (centraal en decentraal) nodig heeft om aan alle functionele eisen en kwaliteitseisen te kunnen voldoen? Vindt periodiek een diagnose plaats van de apparatuur, het netwerk en dergelijke? Is een tweede set van apparatuur en dergelijke aanwezig waarop (delen van) het informatiesysteem kan uitwijken?

2. Robuustheid Definitie Robuustheid: De mate waarin de informatievoorziening ook na een storing gewoon door kan gaan.


Zijn binnen de verwerkingsorganisatie plaatsvervangers beschikbaar en opgeleid?

Gebruikersorganisatie +

Zijn binnen de gebruikersorganisatie plaatsvervangers beschikbaar en opgeleid?

Functionele systeemarchitectuur +

Zijn de essentiële functies van het informatiesysteem afgeschermd in een apart deelsysteem dat extra is beveiligd?

Technische systeemarchitectuur + + + + +

Zijn automatische uitwijkfaciliteiten ingebouwd? Zijn controleprocessen (‘watchdogs’) aangebracht? Wordt de gegevensverwerking dubbel uitgevoerd? Kan de operator statusinformatie verschaffen? Wordt door middel van de juiste transactiegrootte en roll-back-faciliteiten voor de consistentie van de gegevens zorg gedragen?


Zijn apparatuur; netwerk, PC’s, systeemsoftware en DBMS geselecteerd die op elkaar en op de toepassingen zijn afgestemd? Is een tweede set van apparatuur en dergelijke aanwezig waarop (delen van) het informatiesysteem kan uitwijken?

3. Herstelbaarheid Definitie Herstelbaarheid Het gemak en de snelheid waarmee de informatievoorziening na een storing hersteld kan worden.


Zijn binnen de verwerkingsorganisatie plaatsvervangers beschikbaar en opgeleid?


Zijn binnen de gebruikersorganisatie plaatsvervangers beschikbaar en opgeleid? Is een verzekering aanwezig die het risico afdekt van schade als gevolg van fouten of onderbrekingen in de informatievoorziening?

Functionele systeemarchitectuur + +

Is de keuze voor deelsystemen beargumenteerd? Zijn er utilities beschikbaar voor onvoorziene opvragingen en/of rapportages?

Aangemaakt d.d.

27-12-2011

Pagina 100




+

+ + + + + + + + +

Is gebruik gemaakt van geldende (inter)nationale standaards bijvoorbeeld voor gegevensuitwisseling via netwerken (OSI), applicaties in de IBM-omgeving (SAA) en een ‘standaard’ programmeertaal die op een grote verscheidenheid van apparatuur gecompileerd kan worden? Is er een back-up en recovery systeem bestaande uit procedures en programmatuur voor: • het periodiek veiligstellen van een samenhangende set kopieën van de gegevensverzamelingen; • logging van alle transacties vanaf de laatste veiligheidskopieën; • het eventueel opnieuw uitvoeren van alle gelogde transacties? Wordt de recovery procedure periodiek getest? Zijn controleprocessen (‘watchdogs’) aangebracht? Wordt door middel van de juiste transactiegrootte en roll-back-faciliteiten voor de consistentie van de gegevens zorg gedragen? Zijn de deelsystemen gedeconcentreerd? Is de essentiéle functionaliteit in aparte modules ondergebracht? Wordt de gegevensverwerking dubbel uitgevoerd? Zijn er automatische uitwijkfaciliteiten ingebouwd? Is er een actueel overzicht van alle in gebruik zijnde programmatuur, inclusief versienummers? De herstelbaarheid wordt in belangrijke mate bepaald door de onderhoudbaarheid ten aanzien van de technische systeemarchitectuur (zie checklist onderhoudbaarheid).

Gegevensinfrastructuur + + + −

Is de gegevensopslag gedeconcentreerd? Zijn utilities beschikbaar voor analyse en reorganisatie van de database? Is er een actueel overzicht van alle in gebruik zijnde bestanden? Is de benadering van de database geoptimaliseerd?

Fysieke beveiligingsmaatregelen +

Wordende back-ups van vitale gegevens op een aparte locatie bewaard in een extra beveiligde omgeving, bij voorkeur buiten het rekencentrum?


Is een tweede set van apparatuur en dergelijke aanwezig waarop (delen van) het informatiesysteem kan uitwijken?

4. Degradatiemogelijkheid Definitie Degradatiemogelijkheid Het gemak waarmee de kern van de informatievoorziening kan worden voortgezet nadat een deel is uitgevallen.

Verwerkingsorganisatie + + +

Zijn voorzieningen getroffen zodat in geval van ernstige storingen of calamiteiten de informatievoorziening zoveel mogelijk in de een of andere vorm kan worden voortgezet? Is een vergelijkbare produktie-omgeving gereserveerd, bijvoorbeeld in een computeruitwijkcentrum inclusief bijbehorende uitwijkprocedures? Zijn handmatige procedures voorbereid die (onderdelen van) de geautomatiseerde informatievoorziening kunnen vervangen?

Functionele systeemarchitectuur + + +

Zijn de functies in samenhang met het bedrijfsprocesmodel gemodelleerd? Is de keuze voor deelsystemen beargumenteerd? Is de informatieverwerking zodanig functioneel gestructureerd dat het mogelijk is de informatieverwerking voort te zetten wanneer bepaalde niet essentièle onderdelen van het informatiesysteem worden stilgelegd?

Technische systeemarchitectuur + +

Is de essentiële functionaliteit in aparte modules ondergebracht? Zijn de deelsystemen gedeconcentreerd?

Gegevensinfrastructuur + −

Is de gegevensopslag gedeconcentreerd? Is de benadering van de database geoptimaliseerd?

Aangemaakt d.d.

27-12-2011

Pagina 101



5. Uitwijkmogelijkheid Definitie Uitwijkmogelijkheid Het gemak waarmee (een deel van) de informatievoorziening op een andere locatie kan worden voortgezet.

Verwerkingsorganisatie / Gebruikersorganisatie + + + + + + +

+ + + + + + + + + + +

Zijn voorzieningen getroffen zodat in geval van ernstige storingen of calamiteiten de informatievoorziening zoveel mogelijk in de een of andere vorm kan worden voortgezet? Is er een calamiteitenplan aanwezig? Is de mate van afhankelijkheid van het informatiesysteem voor de gebruikersorganisatie vastgesteld (kritisch, gevoelig, ongevoelig)? Is de maximaal toelaatbare uitvaltijd vastgesteld? Is bepaald wat als calamiteit wordt beschouwd? Is er een coördinator benoemd voor het geval zich een calamiteit voordoet en zijn de bevoegdheden en verantwoordelijkheden in geval van een calamiteit beschreven? Zijn de noodprocedures alsmede de alternatieve werkwijzen voor een eventuele overgangsperiode beschreven? (Onder andere dient aandacht te zijn gegeven aan procedures met betrekking tot het afhandelen van transacties die nog niet geheel zijn afgehandeld op het moment van storing (tussenbestanden c.q. de ‘pijplijn’)) Is binnen het calamiteitenplan aandacht gegeven aan eventuele reserve hardware? Is er, als onderdeel van het calamiteitenplan, een uitwijkplan aanwezig? Zijn de organisatorische aspecten alsmede de van toepassing zijnde procedures bij uitwijk beschreven? Is beschreven welke functionaris bevoegd is te beslissen om al dan niet uit te wijken? Is een vergelijkbare produktie-omgeving gereserveerd, bijvoorbeeld in een computeruitwijkcentrum inclusief bijbehorende uitwijkprocedures? Beschikt de (externe) uitvoerende instantie, belast met de realisatie van de uitwijk, over een up-to-date uitwijkplan? Is het calamiteitenplan bekend binnen de betrokken organisatieonderdelen? Wordt het uitwijkplan periodiek, doch minstens eenmaal per jaar, getest? Leiden de bevindingen die worden gedaan bij de uitwijktest tot aanpassingen in het uitwijkplan? Vindt een test van het uitwijkplan plaats na een ingrijpende wijziging in de systeemarchitectuur? Zijn handmatige procedures voorbereid die (onderdelen van) de geautomatiseerde informatievoorziening kunnen vervangen?

Aangemaakt d.d.

27-12-2011

Pagina 102



B8. Checklist Controleerbaarheid Definitie Controleerbaarheid Het gemak waarmee de juistheid en de volledigheid van de informatie (in het verloop van de tijd) gecontroleerd kunnen worden.

Functionele systeemarchitectuur + + + + + + +

Zijn geprogrammeerde controles op de resultaten van de gegevensverwerking aanwezig zoals controletotalen en vierkantstellingen? Worden transacties doorgenummerd met vermelding van de betreffende nummers op mutatieverslagen? Worden rapportbladzijden doorgenummerd met vermelding van het totaal aantal pagina's? Worden historische gegevens en mutatierecords vastgelegd en bewaard? Zijn informatiefuncties aanwezig met betrekking tot de historische gegevens met voldoende selectiemogelijkheden? Zijn er mogelijkheden in het kader van een audit-trail? Wordt ten behoeve van de audit trail bij elke mutatie ook geregistreerd wie hem heeft verricht en met welke functie?

Technische systeemarchitectuur + + +

Zijn er controlefuncties voor de juistheid van de informatie? Zijn er controlefuncties voor de volledigheid van de informatie? Vindt registratie, bijvoorbeeld logging, plaats van alle verwerkingen?

Gegevensinfrastructuur +

Zijn er mogelijkheden voor een (periodieke) controle van de consistentie van de gegevens?

B9. Checklist Flexibiliteit Definitie Flexibiliteit De mate waarin de gebruiker zelf uitbreidingen of variaties op het informatiesysteem kan aanbrengen zonder dat de programmatuur wordt aangepast.

Technische systeemarchitectuur + + +

Is de programmatuur geparametriseerd? Worden logicals gebruikt in plaats van harde getallen in de code? Is de gegevensverwerking gescheiden van de gegevensbenadering?

Gegevensinfrastructuur + + + +

Is het gegevensmodel geparametriseerd? Is het gegevensmodel genormaliseerd? Zijn meerdere zoeksleutels gedefinieerd per entiteit? Is er een 'meta-gegevensmodel' aanwezig?

Ontwikkelomgeving + +

Wordt gebruik gemaakt van 4 GL faciliteiten? Kan de gebruikersorganisatie op eenvoudige wijze zelf rapportages definiëren?

Aangemaakt d.d.

27-12-2011

Pagina 103



B10. Checklist Gebruikersvriendelijkheid Definitie Gebruikersvriendelijkheid Het gemak waarmee de eindgebruiker kan leren omgaan met het informatiesysteem en het bedieningsgemak van het informatiesysteem voor ingeleerde gebruikers. Indien er voor wordt gekozen het kwaliteitsattribuut gebruikersvriendelijkheid op te nemen in de teststrategie geeft dit veelal problemen. Hoe dient het testteam een uitspraak te doen over het slechts subjectief meetbare kwaliteitsattribuut gebruikersvriendelijkheid? Een mogelijke werkwijze is het opstellen van een vragenlijst die tevens vrije ruimte laat voor toelichtingen en overige opmerkingen. Deze vragenlijst wordt vervolgens door de testers ingevuld waarna de testmanager c.q. testteamleider enig inzicht krijgt in de gebruikersvriendelijkheid van het informatiesysteem. Het geheel blijft natuurlijk enigszins subjectief Het verdient aanbeveling het invullen van de vragenlijst met name te combineren met het uitvoeren van semantische en syntactische tests. Mogelijke vragen die onderdeel kunnen uitmaken van de vragenlijst: •

Hoe beoordeelt u de opstartprocedure?

•

Wat is uw algemeen oordeel over de opbouw (lay-out) van de schermen? onaanvaardbaar acceptabel met aanpassingswensen acceptabel Toelichting:………………………………(ook bij de volgende vragen)

•

Zijn er schermen die in negatieve zin opvallen? nee ja, te weten scherm…………………

•

Hoe beoordeelt u het taalgebruik op de diverse schermen?

•

Hoe beoordeelt u het gebruik van iconen? (van toepassing in een GUl-omgeving: Windows, Macintosh, OS/2)

•

Zijn de foutboodschappen duidelijk? ja nee, te weten………………………..(schermnaam en omschrijving aangeven)

•

Zijn de helpschermen c.q. helpteksten duidelijk en hoe beoordeelt u het gebruik ervan?

•

Hoe beoordeelt u het gebruik van de muis/functietoetsen/toetscombinaties?

•

Hoe beoordeelt u de menustructuur; is er behoefte aan gebruikersmenu's? Is de naamgeving van de functies duidelijk?

•

Is er voldoende standaardisatie ten aanzien van menuschermen, functieschermen, functietoetsen, enzovoort?

•

In hoeverre sluiten de functies aan bij de werkwijze en structuur van de gebruikersorganisatie?

•

Wat is uw algemeen oordeel ten aanzien van de lay-out van de overzichten? onaanvaardbaar acceptabel met aanpassingswensen acceptabel

•

Zijn er overzichten die in negatieve zin opvallen? nee ja, te weten…………………………..

•

Bevatten de overzichten de gewenste informatie? (Zijn er te veel of te weinig details vermeld?)

Aangemaakt d.d.

27-12-2011

Pagina 104



•

Hoe beoordeelt u de standaards ten aanzien van de kopregels en voetregels?

•

Hoe beoordeelt u de afdrukfaciliteiten?

•

Hoe beoordeelt u de gebruikersdocumentatie? Met ander woorden in welke mate is gebruikersdocumentatie daadwerkelijk ondersteunend bij het werken met het informatiesysteem?

De vragenlijst kan desgewenst worden afgesloten met een vraag waarin een algemene waardering ten aanzien van de gebruikersvriendelijkheid wordt gevraagd in termen van een cijfer (van 1 tot 10). Op deze wijze is de gebruikersvriendelijkheid ook (enigszins) te kwantificeren.

Aangemaakt d.d.

27-12-2011

Pagina 105



B11. Checklist Herbruikbaarheid Definitie Herbruikbaarheid De mate waarin delen van het informatiesysteem, of van het ontwerp, opnieuw gebruikt kunnen worden voor de ontwikkeling van andere toepassingen.

Functionele sys1eemarchi~ctuur + + +

Is gebruik gemaakt van een algemeen referentiemodel? Zijn de functies met een bedrijfsprocesmodel gemodelleerd? De herbruikbaarheid wordt mede bepaald door de onderhoudbaarheid van het (deel van het) informatiesysteem (zie checklist onderhoudbaarheid).


+ + + + + + + + −

Is gebruik gemaakt van geldende (inter)nationale standaards of bedrijfsstandaards? Bijvoorbeeld voor gegevensuitwisseling via netwerken (0~I), applicaties in de IBM-omgeving (SAA) en een standaard programmeertaal die op een grote verscheidenheid van apparatuur gecompileerd kan worden? Is de programmatuur geparametriseerd? Is de dataverwerking in deeltransacties opgesplitst? Is de invoer; verwerking en uitvoer apart geïmplementeerd? Zijn eventuele machine-afhankelijkheden in aparte modules geïmplementeerd? Zijn 1/0 operaties in aparte modules ondergebracht om de gegevensbenadering van de gegevensverwerking te scheiden? Is gebruik gemaakt van een standaard machine-interface? Zijn standaardhandelingen consistent in de interface ingebouwd? Zijn programmamodules hergebruikt? Zijn de algoritmen geoptimaliseerd?


Zijn data afgestemd op een bedrijfsgegevensmodel? Is het gegevensmodel geparamatriseerd? Is de benadering van de database geoptimaliseerd?


Is een courante infrastructuur gebruikt?

B12. Checklist geschiktheid Infrastructuur Definitie Geschiktheid Infrastructuur De geschiktheid van de apparatuur, het netwerk, de systeemsoftware en het DBMS voor de betreffende toepassing en de mate waarin deze infrastructuur-elementen op elkaar aansluiten.

Ontwikkelomgeving +

Zijn één of meer 3 GL of4 GL programmeeromgevingen geselecteerd die geschikt zijn voor de betreffende toepassing en passen bij de verdere infrastructuur?


Zijn apparatuur, netwerk, PC's, systeemsoftware en DBMS geselecteerd die op elkaar en op de toepassingen zijn afgestemd? Heeft een objectieve bepaling plaatsgevonden van de benodigde hoeveelheid verwerkingscapaciteit en opslagcapaciteit die het informatiesysteem (centraal en decentraal) nodig heeft om aan alle functionele eisen en kwaliteitseisen te kunnen voldoen?

Aangemaakt d.d.

27-12-2011

Pagina 106



B13. Checklist Onderhoudbaarheid Definitie Onderhoudbaarheid Het gemak waarmee het informatiesysteem kan worden aangepast aan nieuwe wensen van de gebruiker, de veranderende externe omgeving of om fouten te herstellen.

Functionele systeemarchitectuur + + + +

Is de keuze voor deelsystemen beargumenteerd? Is gebruik gemaakt van een algemeen referentiemodel? Zijn de functies in samenhang met een bedrijfsprocesmodel gemodelleerd? Is toegankelijke, consistente en actuele functionele documentatie aanwezig?


+

+ + + + + + + + + + − − − − −

Wordt bij het ontwikkelen gebruik gemaakt van standaards? (Bijvoorbeeld: standaardschematechnieken, standaards voor gestructureerd programmeren, standaard benadering van de database, werkbare documentatiestandaards, herkenbare naamgevingsstandaards en standaards voor het gebruik van gebruikersinterfaces.) Is gebruik gemaakt van geldende (inter>nationale standaards of bedrijfsstandaards, bijvoorbeeld voor gegevensuitwisseling via netwerken (OSI), applicaties in de IBM-omgeving (SAA) en een standaard programmeertaal die op een grote verscheidenheid van apparatuur gecompileerd kan worden? Zijn de standaardhandelingen consistent in de interface ingebouwd? Zijn controleprocessen ('watchdogs'> aangebracht? Kan de operator statusinformatie verschaffen? Is de dataverwerking in deeltransacties opgesplitst? Zijn de invoer, verwerking en uitvoer apart geïmplementeerd? Zijn eventuele machine-afhankelijkheden in aparte modules geïmplementeerd? Zijn de essentiële functionaliteiten in aparte modules ondergebracht? Zijn 1/0 operaties in aparte modules ondergebracht om de gegevensbenadering van de gegevensverwerking te scheiden? Zijn de programma's doorzichtig en gestructureerd opgezet? Is toegankelijke, consistente en actuele technische documentatie aanwezig? Is de programmatuur geparametriseerd? Wordt gebruik gemaakt van technische handelingen in de interface? Zijn de deelsystemen gedeconcentreerd? Is gegevensverwerking dubbel uitgevoerd? Zijn de algoritmen geoptimaliseerd?

Gegevensinfrastructuur + − −

Is een gegevensmodel aanwezig en is het genormaliseerd? Zijn de gegevensbestanden versleuteld? Is de benadering van de database geoptimaliseerd?

Ontwikkelomgeving + + + + +

Is er een geïntegreerde testfaciliteit aanwezig? Wordt gebruik gemaakt van 4 GL faciliteiten? Is er sprake van een geïntegreerde 'functionele' ontwikkelomgeving? (workbench (CASE-tool), tekstverwerker en dergelijke> Is er sprake van een geïntegreerde 'technische' ontwikkelomgeving? (DBMS, 4 GL> Wordt gebruik gemaakt van een code- of systeemgenerator (ICASE)?

Aangemaakt d.d.

27-12-2011

Pagina 107



B14. Checklist Portabiliteit Definitie Portabiliteit De diversiteit van hardware- en systeemsoftware-omgevingen waarin het inf ormatiesy steem kan draaien, en het gemak waarmee het systeem kan worden overgebracht van de ene omgeving naar een andere omgeving.

Technische systeemarchitectuur + +

+ + − −

Is de programmatuur geparametriseerd? Is gebruik gemaakt van geldende (inter)nationale standaards of bedrijfsstandaards, bijvoorbeeld voor gegevensuitwisseling via netwerken (OST), applicaties in de IBM-omgeving (SAA> en een standaard programmeertaal die op een grote verscheidenheid van apparatuur gecompileerd kan worden? Is gebruik gemaakt van een standaard machine-interface? Zijn eventuele machine-afhankelijkheden in aparte modules geïmplementeerd? Zijn de algoritmen geoptimaliseerd? Zijn de diverse deelsystemen gedeconcentreerd?

Gegevensinfrastructuur −

Is de benadering van de database geoptimaliseerd?

Ontwikkelomgeving + + +

Is gebruik gemaakt van 4 GL faciliteiten? Zijn courante ontwikkelhulpmiddelen gebruikt? Wordt gebruik gemaakt van een courante infrastructuur?


Is een infrastructuur (apparatuur netwerk en dergelijke> geselecteerd die 'upwards compatible' is binnen een bepaalde range? Is een courante infrastructuur gebruikt?

Aangemaakt d.d.

27-12-2011

Pagina 108



B15. Checklist Testbaarheid Definitie Testbaarheid Het gemak en de snelheid waarmee de functionaliteit en het prestatieniveau van het systeem (na iedere aanpassing) getest kunnen worden.


Wordt de vervaardigde testware afgerond en geconserveerd ten behoeve van volgende tests? Zijn er ter ondersteuning van het testproces hulpmiddelen voor planning en probleembeheer?

Functionele systeemarchitectuur + + −

Is de keuze voor deelsystemen beargumenteerd? Is toegankelijke, consistente en actuele technische documentatie aanwezig? Is er sprake van een sterke interactie c.q. doorwerking tussen de diverse functionaliteiten?


+ + + + + + + + + + − − − −

Wordt bij het ontwikkelen gebruik gemaakt van standaards? (Bijvoorbeeld: standaardschematechnieken, standaards voor gestructureerd programmeren, standaard benadering van de database, werkbare documentatiestandaards, herkenbare naamgevingsstandaards en standaards voor het gebruik van gebruikersinterfaces.> Zijn controleprocessen ('watchdogs'> aangebracht? Kan de operator statusinformatie verschaffen? Is de dataverwerking in deeltransacties opgesplitst? Zijn de invoer, verwerking en uitvoer apart geïmplementeerd? Zijn eventuele machine-afhankelijkheden in aparte modules geïmplementeerd? Zijn de essentiële functionaliteiten in aparte modules ondergebracht? Zijn 1/0 operaties in aparte modules ondergebracht om de gegevensbenadering van de gegevensverwerking te scheiden? Worden programmamodules hergebruikt? Zijn de programma's doorzichtig en gestructureerd opgezet? Is toegankelijke, consistente en actuele technische documentatie aanwezig? Zijn de deelsystemen gedeconcentreerd? Wordt de gegevensverwerking dubbel uitgevoerd? Is de programmatuur geparametriseerd? Zijn de algoritmen geoptimaliseerd?

Gegevensinfrastructuur − − − −

Zijn de gegevensbestanden versleuteld? Is de gegevensopslag gedeconcentreerd? Is het gegevensmodel geparametriseerd? Is de benadering van de database geoptimaliseerd?

Ontwikkelomgeving + + + + + + + +

Is er een geïntegreerde testfaciliteit aanwezig? Wordt gebruik gemaakt van een testtool ten behoeve van 'record & playback' en/of testontwerp? Is er de mogelijkheid om queries uit te voeren met betrekking tot de gegevensverzamelingen? Wordt gebruik gemaakt van 4 GL faciliteiten? Is er sprake van een aparte testomgeving? Is er sprake van een geïntegreerde 'functionele' ontwikkelomgeving? (workbench, (CASE-tool), tekstverwerker en dergelijke) Is er sprake van een geïntegreerde 'technische' ontwikkelomgeving? (DBMS, 4 GL) Wordt gebruik gemaakt van een code- of systeemgenerator (ICASE)?

Aangemaakt d.d.

27-12-2011

Pagina 109



B16. Checklist Evaluatie testproject Deze checklist kan worden gebruikt om tijdens en na afloop van het testproces het project kwalitatief te beoordelen. Een periodiek gebruik van deze checklist tijdens het testproject kan leiden tot een adequate preventieve actie op eventuele problemen. • • • • • • • • • • • • • • • • • • • • • • • • • •

• • • • • • • • • • • • • • • • • •

Is de checklist produktie-vrijgave afgewerkt? Speelt het testproject zich af onder tijdsdruk? Zo ja, worden er concessies gedaan aan de oorspronkelijke teststrategie? Worden de gebruikers tijdig bij het testproject betrokken? Krijgt, naar de mening van de gebruikers, de acceptatietest voldoende tijd? Worden er gedurende het testproject concessies gedaan aan de geplande testomvang en -intensiteit? Krijgt het testteam ondersteuning van ervaren (externe) adviseurs en testspecialisten? Is er voldoende materiekennis en ervaring aanwezig in het testteam? Is de probleemafhandeling goed geregeld en werkt versiebeheer naar behoren? Krijgen de aansluitingen op de bestaande systemen en de Organisatie voldoende aandacht? Is er voldoende afstemming met andere projecten? Geeft de voorgeschreven wijze van testen, bijvoorbeeld vastgelegd in een handboek testen, voldoende informatie en steun bij eventuele problemen? Vindt er controle plaats op naleving van de richtlijnen? Is er een procedure die voorziet in afhandeling van eventuele afwijkingen van deze richtlijnen? Is er volgens 4e voorschriften een testplan vervaardigd? Is er sprake van een kritische einddatum voor beëindiging van het testen? Wordt het testplan, gedurende het verloop van de test, nader gedetailleerd en/of onderhouden? Komen de gevraagde ondersteunende aspecten (tools, apparatuur, enzovoort) in voldoende mate en tijdig beschikbaar? Ziet men kans het voorgenomen testplan binnen de daarvoor gestelde grenzen te realiseren? Is het testplan begrijpelijk en uitvoerbaar voor de leden van het testteam? Worden planningstechnieken en -hulpmiddelen toegepast? Vindt een adequate bewaking van testactiviteiten en testvoortgang plaats? Zijn de redenen voor eventuele bijstellingen van de planning duidelijk gedocumenteerd en kenbaar gemaakt aan de betrokkenen? Is concreet aan te geven waar men zich bevindt ten opzichte van de planning? Is er steeds een goede relatie tussen de testplanning en de 'overall' projectplanning? Voldoen de standaardtechnieken en -hulpmiddelen? Is er in het testteam voldoende inbreng van: • systeemontwikkelaars • systeembeheer • rekencentrum • materiedeskundigen • eindgebruikers • accountantsdienst? Is het management voldoende betrokken bij het testen? Is er een goede en eenduidige taakverdeling? Is er sprake van versiebeheer van de te testen applicatiedelen? Zijn er speciale opleidingen nodig ten aanzien van apparatuur, programmatuur en/of testen)? Zijn de leden van het testteam universeel inzetbaar? Wordt de testfasering gehanteerd zoals is voorgeschreven? Worden alle systeemfuncties doorlopen bij het testen? Worden er nog andere, dan van de testbasis afkomstige, testgevallen uitgevoerd? Wordt door gebruikers een kwaliteitsoordeel gevormd over de manier waarop het bouwteam test? Worden de door het bouwteam samengestelde testgevallen beschikbaar gesteld aan de acceptatietesters? Wordt error-guessing toegepast? Wordt de hulpprogrammatuur getest? Wordt de back-up/restore programmatuur getest? Wordt de conversieprogrammatuur getest? Is er voorzien in een regressietest aan het einde van de test? Worden geautomatiseerde hulpmiddelen gebruikt voor de creatie van testgevallen? Worden alle geplande testscripts uitgevoerd? Worden de administratief organisatorische procedures met betrekking tot het nieuwe systeem getest?

Aangemaakt d.d.

27-12-2011

Pagina 110

Uittreksel Titel: Testen volgens TMap • • • • • • • • • • • • •


Worden eventueel beschikbare checklists gebruikt? Voldoen de overlegstructuren, intern in het testteam en die met de ontwikkelaars? Wordt voldoende documentatiediscipline opgebracht? Wordt de testware systematisch gecomplementeerd? Worden de oorzaken van afwijkingen in testaanpak, planning en gebruikte technieken steeds goed gedocumenteerd? Is het budget voldoende? Is er voldoende ruimte voor testen overlegwerkzaamheden? Is de kantoorinrichting naar behoren? Zijn er voldoende testhulpmiddelen, terminals, printers en dergelijke? Is er voldoende capaciteit beschikbaar op de (centrale) computer? Is er voldoende bestandsruimte? Is er voldoende personeel? Komen de testresultaten voldoende snel beschikbaar?

Aangemaakt d.d.

27-12-2011

Pagina 111



B17. Checklist Globale bestudering informatiesysteem In deze checklist zijn de mogelijke aspecten van studie opgenomen met betrekking tot de activiteit 'globale intake en studie' uit de fase Planning en beheer.

Organisatie-informatie • • • •

bedrijfsdoelstelling cultuur organisatieschema (onder andere informatievoorziening en informatiegebruik) eventueel aanwezige knelpunten.

Projectinformatie • • • • • • • • • • • • •

opdrachtgever opdrachtnemer doelstelling (opdracht, strategisch belang) afspraken (contracten) standaards en richtlijnen (ontwikkelmethoden enzovoort) rapport definitiestudie (onder andere beschrijving bestaande situatie) documentatie uit de fase basisontwerp ontwikkel-infrastructuur (apparatuur; hulpmiddelen en systeem-software) projectorganisatie inclusief personele bezetting rapportagelijnen activiteiten tijdplanningen financièle planning randvoorwaarden gesteld aan de uit te voeren test risico's.

Applicatie-informatie (met name bij een testproces voor onderhoud) • • • • • • • •

invoer en uitvoer (aantallen en pieken) aantallen mutaties te onderscheiden processen gegevensverzamelingen (opslagtechnieken en grootte) gegevensmodel exploitatie-infrastructuur relaties met andere informatiesystemen reeds aanwezige testware: • testspecificaties • testscripts • testdraaiboek • testinfrastructuur • testtools • statistieken • evaluatierapport voorgaande tests.

Aangemaakt d.d.

27-12-2011

Pagina 112



B18. Checklist Randvoorwaarden en uitgangspunten In deze checklist wordt een aantal mogelijke randvoorwaarden en uitgangspunten opgesomd. Randvoorwaarden en uitgangspunten worden tijdens het op stellen van het testplan vastgesteld. Randvoorwaarden worden in principe extern aan het testproject opgelegd. Zij liggen over het algemeen op het terrein van limieten en voorwaarden met betrekking tot benodigde middelen, mensen, budget en tijd. Uitgangspunten worden daarentegen door het testteam zelf bepaald. • • •

•

•

•

• •

•

•

•

•

•

•

Vaste einddatum: De test dient uiterlijk op een vastgestelde einddatum te zijn beëindigd; Projectplan: Bij het uitvoeren van de diverse testactiviteiten geldt het vigerende projectplan als randvoorwaarde; Opleveringen testeenheden: Het is vereist dat de software door het bouwteam in functioneel bruikbare en testbare eenheden wordt aangeleverd conform de bouwplanning. Naast de software dienen de gebruikershandleidingen te worden meegeleverd. Deze functionele eenheden dienen aan een programmatest en een systeemtest te zijn onderworpen, conform het plan van aanpak systeemtest; Inzicht en wijzigingen bouwplanning: Het testteam dient een aantal vooraf afgesproken maanden vóór oplevering van een deelsysteem op de hoogte te zijn van de planning van het bouwteam. Wijzigingen in de bouwplanning moeten vóór effectuering worden doorgegeven aan het acceptatietestteam; Inspraak bouwplanning: Het testteam krijgt (door tussenkomst van het projectmanagement) sturingsmogelijkheden in de bouwen opleveringsvolgorde en de op te leveren eenheden. De sturing is noodzakelijk voor het vaststellen van de volgorde van testspecificatie en om in een vroegtijdig stadium de beschikking te krijgen over definitieve, bruikbare functies voor het opbouwen van de initiële gegevensverzamelingen; Kwaliteit Produktie-acceptatietest: Het rekencentrum voert de produktie-acceptatietest uit op de haar toegewezen kwaliteitsattributen en objecten, eerst per subsysteem en tenslotte op systeemniveau; Kwaliteit systeemtest: Het bouwteam voert de systeemtest uit op de haar toegewezen kwaliteitsattributen en objecten; Inzicht systeemtest: Het acceptatietestteam krijgt op verzoek inzicht in de volgende produkten van de systeemtest: • planning, • teststrategie, • testgevallen en • testresultaten om daar waar het testmanagement dat nodig en zinvol acht, rekening mee te kunnen houden; scope testbasis: Het acceptatietestteam krijgt inzicht in alle systeemdocumentatie, waaronder ook de documenten die niet tot de primaire testuitgangsdocumentatie (testbasis) behoren. Hier wordt met name gedoeld op de technische documentatie, om de logische testgevallen te kunnen vertalen naar fysieke testgevallen; Wijzigingen testbasis: Het testteam dient per ommegaande op de hoogte te worden gesteld van doorgevoerde wijzigingen in de testbasis; Kwaliteit testbasis: Als op basis van de kwaliteit van voornoemde testbasis het specificeren of daadwerkelijk uitvoeren van tests onmogelijk is, dienen de tekortkomingen, na melding per ommegaande door de opdrachtgever, hersteld danwel aangevuld te worden; Beschikbaarheid testteam: Het testteam dient conform de testplanning beschikbaar te zijn. Zij dienen te voldoen aan het geschetste profiel van kennis en ervaring. Nadrukkelijk wordt vermeld dat opleiding van het testteam buiten het testproject sec valt en dat methodische begeleiding wel is voorzien; Ondersteuning bouwteam: Tijdens de uitvoering van de test dient structurele ondersteuning van het bouwteam beschikbaar te zijn om fouten te herstellen, waarbij de voortgang van de testuitvoering als primaire voorwaarde geldt; Ondersteuning gebruikersorganisatie: Voor ondersteuning met betrekking tot materiedeskundigheid kan te allen tijde worden teruggevallen op de aanwezige expertise binnen de gebruikers-organisatie;

Aangemaakt d.d.

27-12-2011

Pagina 113



Ondersteuning rekencentrum: Tijdens de uitvoering van de test dient structurele ondersteuning van het rekencentrum beschikbaar te zijn om fouten en tekortkomingen in de testomgeving te herstellen;

Aangemaakt d.d.

27-12-2011

Pagina 114


•

•

•


Definitie en onderhoud testomgeving: De definitie van de acceptatietestomgeving en de systeemtestomgeving zal in gezamenlijk overleg tussen het bouwteam en het acceptatietestteam geschieden. Er zal gebruik gemaakt kunnen worden van hetzelfde/eenzelfde beheersinstrumentarium. De technische inrichting, alsmede het onderhoud en het beheer, zal worden uitgevoerd door het rekencentrum; Beschikbaarheid testomgeving: De testomgeving (hard- en software, benodigde bestanden en programmatuur) ten behoeve van de test dient voor het testmanagement beheersbaar en conform de planning beschikbaar te zijn. Hiertoe zal het rekencentrum structurele bijstand moeten leveren, volgens nog nader af te spreken voorwaarden. Er moet een als ware het produktie' omgeving beschikbaar zijn, waarin onder andere ook de decentrale infrastructuur getest kan worden; Installatie testomgeving: Installatie van nieuwe en/of herstelde programmatuur en bestanden in de testomgeving vindt alleen plaats na schriftelijke toestemming van het testmanagement; Gebruik testtools: De acceptatietest en de systeemtest zullen gebruik maken van dezelfde testtools. Daartoe zal in de afgesproken periode in onderling overleg, ook met het rekencentrum, een definitieve lijst van te gebruiken testtools worden opgesteld, alsmede een onderbouwd voorstel met betrekking tot de acquisitie van die tools.

Aangemaakt d.d.

27-12-2011

Pagina 115



B19. Checklist Risico’s testproject In de paragraaf risico's uit het testplan worden de onderkende risico's opgesomd. Per onderkend risico dienen de consequenties en, indien mogelijk, oplossingen en/of maatregelen ten aanzien van de onderkende risico's te worden aangegeven. In de checklist staan mogelijke risico's die kunnen worden onderkend met betrekking tot een uit te voeren testproject. Overigens kunnen risico's (tussentijds) tevens worden onderkend met behulp van de checklist evaluatie testproject. • • • • • • • • • •

Het ontbreken van een detailplanning van het ontwikkelteam voor de diverse deelsystemen; De vooraf vastgestelde einddatum heeft invloed op de volledige uitvoering van de testactiviteiten zoals vermeld in het testplan; Het niet tijdig beschikbaar van de testbasis (AO-procedures, gebruikershandleiding en ontwerpspecificaties); Onvoldoende kwaliteit van de testbasis; Het niet tijdig beschikbaar zijn van functiepunttellingen, alsmede de betrouwbaarheid ervan. Beide aspecten leiden indirect tot een onbetrouwbare testplanning bij het toepassen van testpuntanalyse; De beschikbaarheid van testpersoneel (capaciteit, geschiktheid qua testervaring en materiekennis); De groei van de omvang, uitgedrukt in functiepunten, van het te testen informatiesysteem; De beschikbaarstelling en de werking van de gewenste testomgeving; De beheersbaarheid van de testomgeving en van alle elementen (programmatuur en gegevens) daarbinnen; De introductie van een nieuwe testaanpak waarmee geen ervaring is binnen de organisatie.

Aangemaakt d.d.

27-12-2011

Pagina 116



B20. Checklist Structurering Indien gestructureerd testen wordt ingevoerd in een Organisatie, dient allereerst te worden bepaald wat de huidige status ten aanzien van het testen is. Om dit te bepalen wordt een kort onderzoek uitgevoerd genaamd testinventarisatie. Deze hierna beschreven checklist kan worden gebruikt bij het uitvoeren van een testinventarisatie.

Testfasering • • • •

Welke testsoorten worden onderscheiden (programmatest, systeemtest, acceptatietest, enzovoort) en wat wordt per testsoort getest? Wat is de samenhang tussen deze testsoorten? In hoeverre vullen de testsoorten elkaar aan c.q. bestaat er overlap tussen de testsoorten? Wordt het testen voor iedere te onderscheiden testsoort gefaseerd uitgevoerd? (planning, voorbereiding, specificatie, uitvoering en afronding).

Fase Planning • • • • • • • • • • • • • •

Is er een mastertestplan van waaruit de onderliggende testplannen worden opgesteld? Wordt een testplan opgesteld? Bevat het testplan een opdrachtformulering waarin de verantwoordelijkheden, het beschouwingsgebied, de uitgangspunten en de randvoorwaarden worden gedefinieerd? Wordt in het testplan de testbasis vastgelegd? Wordt er, uitgaande van de gewenste dekkingsgraad en acceptatiecriteria een teststrategie opgesteld? Wordt in de fase planning de teststrategie bepaald? Is de testinfrastructuur gedefinieerd in het testplan en zijn afspraken omtrent beheer vastgelegd? Is een procedure ten aanzien van probleemrapportage beschreven in het testplan? Is in het testplan beschreven welke produkten gedurende de test worden opgeleverd? Is in het testplan beschreven uit welke onderdelen de testware bestaat en hoe het beheer van de testware geregeld is? Is in het testplan beschreven welke (test)functies worden onderscheiden inclusief de verdeling van taken, verantwoordelijkheden en bevoegdheden? Is in het testplan beschreven welke rapportagelijnen te onderscheiden zijn vanuit het testteam? Is in het testplan een activiteitenplanning alsmede een financiële en personele planning opgenomen? Wordt er een gefundeerde begroting opgesteld met betrekking tot het testen? (Wordt hiervoor een methode, bijvoorbeeld testpuntanalyse gebruikt?)

Fase Voorbereiding • •

Wordt voor iedere testsoort een intake gedaan op de testbasis? Vindt er een onderbouwde keuze plaats van te gebruiken testtechnieken?

Fase Testspecificatie • •

Worden er testspecificaties opgesteld? Worden hiervoor testspecificatietechnieken gebruikt? Zo ja, welke zijn dit?

Fase Testuitvoering • • •

Is er sprake van een formeel probleembeheer? Hoe worden testbestanden opgebouwd en beheerd? Is er sprake van hertests?

Fase Afronding • •

Wordt de testware na afloop van de test opgeslagen ten behoeve van onderhoudstests? Vindt er een formele overdracht/vrijgave plaats?

Testtechnieken • • •

Zijn er technieken ten behoeve van teststrategiebepaling? Zijn er testbegrotingstechnieken? Zijn er testspecificatietechnieken? Zo ja, welke zijn dit?

Testorganisatie

Aangemaakt d.d.

27-12-2011

Pagina 117



Projectorganisatie • • • • • • •

Hoe is de projectorganisatie van het testen geregeld? Bij wie liggen de bevoegdheden en de verantwoordelijkheden? Wie voert de tests uit? Zijn er afspraken gemaakt met betrekking tot de rapportage? Zijn er procedures met betrekking tot het probleembeheer? Hoe vinden de intake en overdracht plaats? Wie is bevoegd voor vrijgave van een getest systeem?

Lijn organisatie • • • • • •

Zijn er normen en standaards met betrekking tot het testen? Zo ja, worden deze standaards gehanteerd? Vindt er controle plaats op het hanteren van de standaards? Worden er ervaringscijfers verzameld met betrekking tot het testen? Is er (inhoudelijke) ondersteuning beschikbaar ten behoeve van het testen? Is er testcoördinatie over alle testprojecten heen? Hebben er opleidingen plaatsgevonden op het gebied van testen? Wat is het kennisniveau van de medewerkers op het gebied van testen?

Infrastructuur en Testtools Onderstaande vragen dienen beantwoord te worden per onderkende testsoort: • Is er ten behoeve van het testen een aparte testomgeving? Wie is eigenaar van deze testomgeving? • Is de inrichting van de testomgeving vergelijkbaar met de produktie-omgeving? • Zijn er procedures met betrekking tot het versie- en configuratiebeheer van • de testomgeving? • Zijn er back-up/ en recovery procedures? • Is de testomgeving qua inrichting en toegankelijkheid afgeschermd van de • ontwikkelen produktie-omgeving? • Zijn er testtools beschikbaar ten aanzien van: • testmanagement (planning, tijdregistratie, voortgangsbewaking) • testspecificatie • probleembeheer • testbegroting • testuitvoering (record- & playback, testdrivers, enzovoort) • bestandsbeheer • Zijn er verder nog hulpmiddelen (digitaal) beschikbaar, zoals checklists en standaard documenten?

Ontwikkelomgeving • • • • • • •

Welke hardware is aanwezig? Welke systeemsoftware is hierop geïnstalleerd? Op welke wijze vindt database-manipulatie en -beheer plaats? Welke programmeertalen worden gebruikt? Op welke wijze vindt systeemontwikkeling plaats (methode)? Zijn er case-tools in gebruik? Zijn er verder nog geautomatiseerde hulpmiddelen die van belang zijn voor de inventarisatie? Zo ja, welke?

Aangemaakt d.d.

27-12-2011

Pagina 118



B21. Checklist Testfaciliteiten In deze checklist zijn een aantal aandachtspunten opgesomd die van belang zijn bij het inrichten en opzetten van de infrastructuur; de Organisatie en het beheer tijdens de fase 'Planning en beheer'.

Werkruimte • • • • • • •

kamers vergaderruimte meubilair (stoelen, bureaus, tafels, kasten) kopieermogelijkheid kantoorbehoeften formulieren floppies

Hardware • • • • •

PC's en/of terminals printers communicatielijnen opslagruimte (tapes, schijfruimte) mainframe capaciteit

Software • • • • •

systeemprogrammatuur (PC) tekstverwerkingspakket plannings- en voortgangsbewakingspakket mainframe utilities testtools

Opleiding • • • • •

introductiecursus testen cursus testtechnieken elementair begrip functioneel ontwerp elementair begrip technisch ontwerp JCL

Logistiek • • • •

koffie- en theevoorziening lunch voorziening declaratieregeling overwerkregeling

Personeel • • • • •

testteam systeembeheer gebruikers produktiebegeleiding management

Procedures • • • • • • • • •

produktiebestudering overdracht bouwteam naar testteam versiebeheer van het testobject, de testomgeving en de testware onderhoud van de initiële gegevensverzameling probleemprocedure back-up/recovery beveiliging testinstructies planningsbewaking testoverleg

Documentatie •

voorschriftgeving of zelfs een handboek testen.

Aangemaakt d.d.

27-12-2011

Pagina 119



B22. Checklist Testmetrieken Een metriek is een getal dat uiteindelijk moet worden vergeleken met een vastgestelde norm of standaard. De volgende metrieken zijn mogelijk te hanteren graadmeters om de effectiviteit en efficiency van het testproces te meten en te vergelijken met de door de organisatie gestelde norm. Zij kunnen ook worden gebruikt bij de rapportage aan de opdrachtgever:

•

•

•

• •

• • • •

•

•

•

• • • • • • • • • •

Gebruikersparticipatie: Verhouding tussen tests uitgevoerd door gebruikers en de totale testtijd. Dit geeft een indicatie van de betrokkenheid van gebruikers; Uitgevoerde instructies: Verhouding tussen het aantal geteste programma-instructies en het totaal aantal programma4nstructies. Er zijn tools beschikbaar die een dergelijke metriek kunnen opleveren; Aantal tests: Verhouding tussen het aantal tests en de systeemgrootte (bijvoorbeeld uitgedrukt in functiepunten). Dit geeft aan hoeveel tests er nodig zijn om een onderdeel te testen; Aantal geteste paden: Verhouding tussen de geteste en het totaal aantal aanwezige logische paden; Testkosten: Verhouding tussen de testkosten en de totale ontwikkelkosten. Een definitie van de verschillende kosten vooraf is hierbij essentieel; Kosten per gedetecteerde fout: Totale testkosten gedeeld door het aantal gevonden fouten; Budgetuitputting: Verhouding tussen het budget en de werkelijke testkosten; Fouten tijdens produktie: Geeft een indicatie van het aantal tijdens het testproces niet gevonden fouten; Aantal gevonden fouten: Het totaal aantal gevonden fouten tijdens het testen gedeeld door het totaal aantal, mede tijdens produktie te bepalen, fouten; Testeffectiviteit in relatie tot het primaire proces: Geeft aan hoeveel kosten het testen heeft bespaard doordat het primaire proces normaal doorgang heeft kunnen vinden. Wat zou het hebben gekost als de betreffende fout pas in de produktiefase was gevonden? Activawaarde van de test: Verhouding tussen de testkosten en de waarde van de activa, die door het ontwikkelde systeem worden beheerd; Hang-up analyse: Verhouding tussen het aantal wijzigingen in de onderhoudsfase en het aantal keren dat het systeem vastloopt; Broncode-analyse: Verhouding tussen het aantal gewijzigde geprogrammeerde instructies en het aantal tests; Testefficiency: Het aantal benodigde tests versus het aantal gevonden fouten; Automatiseringsgraad van het testen: Verhouding tussen het aantal handmatig uitgevoerde en het aantal geautomatiseerd uitgevoerde tests; Testeffectiviteit in de definitiestudiefase: Verhouding tussen de kosten van het testen en het aantal gedane bevindingen in de definitiestudiefase; Testeffectiviteit in de ontwerp-fase: Verhouding tussen de kosten van het testen en het aantal gedane bevindingen in de ontwerp-fase; Testeffectiviteit in de programmeerfase: Verhouding tussen de kosten van het testen en het aantal gedane bevindingen in de programmeerfase; Testeffectiviteit in de testuitvoeringsfase: Verhouding tussen de kosten van het testen en het aantal gedane bevindingen in de testuitvoeringsfase; Testeffectiviteit in de implementatiefase: Verhouding tussen de kosten van het testen en het aantal gedane bevindingen in de implementatiefase; Testeffrctiviteit in de onderhoudsfase: Verhouding tussen de kosten van het testen en het aantal gedane bevindingen in de onderhoudsfase; Aantal gevonden fouten: Verhouding tussen het aantal gevonden fouten en de grootte van het systeem per tijdseenheid testen;

Aangemaakt d.d.

27-12-2011

Pagina 120


•

•


Problemen als gevolg van niet geteste aanpassingen: Problemen door niet geteste aanpassingen, als onderdeel van het totaal aantal problemen, ontstaan door wijzigingen; Problemen na geteste aanpassingen: Problemen door geteste aanpassingen, als onderdeel van het totaal aantal problemen, ontstaan door wijzigingen; Besparing van de test: Geeft aan hoeveel er is bespaard door de test uit te voeren. Met andere woorden hoe groot zou het verlies zijn, als de test niet was uitgevoerd.

Aangemaakt d.d.

27-12-2011

Pagina 121



B23. Checklist Vrijgave produktie Alvorens een systeem daadwerkelijk te voorzien van een vrijgave-advies voor produktie, kan de volgende vrijgave checklist worden afgewerkt. Indien de diverse tests volledig en juist zijn uitgevoerd zal het grootste deel van de vragen reeds zijn verwerkt in de diverse uitgevoerde tests.

Volledigheid produkt • • • • • • • •

Is er een regressietest beschikbaar voor onderhoud? Is de benodigde invoerings- en conversieprogrammatuur bijgeleverd, getest en accoord bevonden? Is programmatuur voor gegevensbeheer ontwikkeld om incidentele bestandscorrecties uit te kunnen voeren? Is de benodigde hulp-, nood- en correctieprogrammatuur aanwezig? Zijn de instrumenten voor het meten van de systeemperformance aanwezig en getest? Is de vereiste systeemdocumentatie, gebruikersdocumentatie en produktiedocumentatie aanwezig, compleet, toegankelijk en consistent? Zijn de vereiste herstartvoorzieningen aangebracht? Is er een draaiboek voor de systeem- en gegevensconversie?

Volledigheid testactiviteiten • • • • • • • • • • • • • • • • • • •

Zijn de interfaces tussen de diverse programma's getest en accoord bevonden? Zijn de interfaces tussen de diverse subsystemen getest en accoord bevonden? Zijn de interfaces met andere systemen getest en accoord bevonden? Zijn de interfaces met decentrale applicaties getest en accoord bevonden? Zijn de interfaces met decentrale apparatuur getest en accoord bevonden? Zijn de interfaces met de besturingsprogrammatuur getest en accoord bevonden? Zijn de interfaces met de handmatige procedures getest en accoord bevonden? Zijn de datatransmissievoorzieningen getest en accoord bevonden? Is de testware afgerond? Heeft de testware de benodigde kwaliteitscontrole ondergaan? Zijn de volumetests naar behoren verlopen? Zijn de netwerkaansluitingen getest en accoord? Wordt voldaan aan de gestelde eisen inzake performance? Werkt een eventuele checkpoint~recovery? Zijn alle herstartmogelijkheden met goed gevolg getest? Vindt de bestandsbenadering plaats binnen de daarvoor gestelde (beveiligings) eisen? Werkt het programma ook met lege invoerbestanden? Wordt door het systeem adequaat gereageerd op extreem foute invoer? Zijn de diverse formulieren tenminste eenmaal uitgeprobeerd?

Produktievoorbereiding • • • • • • • • •

Zijn de nieuwe gebruikers bekend met het nieuwe systeem en de eventuele nieuwe apparatuur? Voldoet de naamgeving van de programmatuur aan de voorschriften? Blijft het systeembeslag binnen de gestelde normen? Zijn de op het moment van in produktie gaan nog aanwezige restfouten (ook bij de gebruikers) bekend? Is bekend hoe met de nog aanwezige restfouten wordt omgegaan? Is terugkeer naar de oude situatie mogelijk bij eventuele onoverkomelijke problemen tijdens produktie? Zijn de bewaartermijnen van de bestanden bekend? Is de bij reconstructie voorgeschreven verwerkingsvolgorde bekend? Is voldoende rekening gehouden met de mogelijkheden van de te gebruiken uitvoermedia?

Produktie-uitvoering • • • • • •

Is bekend welk beslag het systeem legt op de capaciteit van het systeem (processingtijd, randapparatuur, personeel, enzovoort)? Zijn de gebruiks- en beheerfuncties in voldoende mate gescheiden? Is de probleemprocedure duidelijk en werkbaar? Is bij de uitvoer adequate kwaliteitsbeheersing mogelijk door toepassing van speciale controletechnieken? Wordt van elke verwerking een verslag geproduceerd met tijd-, medium-, nummer- en versievermelding? Wordt uitvoer voorzien van begin- en eindindicaties ten behoeve van volledigheidscontrole?

Aangemaakt d.d.

27-12-2011

Pagina 122



Bijlage C - Voorbeelden Specificatietechnieken 1. Algortimetest 1.1 Testmaat 2 Voor een actie is niet slechts de beslissing van acties.

belang, maar ook de uitvoering van de voorliggende

Bij ieder beslispunt actiecombinaties maken! Beslispunt A: • vóór A: 1 én 6 (vanuit B); • ná A: 2, 3 én 4 Beslispunt B: • vóór B: 2, 3 én 4 • ná B: 5 én 6. Combinaties: • A: (1,2); (1,3); (1,4); (6,2); (6,3); (6,4). • B: (2,5); (3,5); (4,5); (2,6); (3,6); (4,6). Paden maken die gehele algoritme doorlopen. Iedere actiecombinatie dient één keer voor te komen in pad. Combinaties: (1,2); (1,3); (1,4); (2,5); (2,6); (3,5); (3,6); (4,5); (4,6); (6,2); (6,3); (6,4). • pad 1: (1,2) + (1,5) wordt: (1,2,5). Hierdoor vervallen (1,2) én (2,5). • pad 2: (1,3) + (3,5) wordt: (1,3,5). Hierdoor vervallen (1,3) én (3,5). • pad 3: (1,4) + (4,5) wordt: (1,4,5). Hierdoor vervallen (1,4) én (4,5). • pad 4: (2,6) + (1,2) + (2,5) wordt: (1,2,6,2,5). Hierdoor vervalt (2,6). Dubbel getest worden (1,2) én (2,5). • pad 5: (3,6) + (4,6) + (6,2) + (6,3) + (6,4) wordt: (1,3,6,4,6,3,5).

1.2 Testmaat 1 Een actie wordt slechts beïnvloed door de beslissing en niet door voorliggende acties. • geen beslissing vóór actie (1); • A is de beslissing vóór actie (2,3,4); • B is de beslissing vóór actie (5,6). Paden: • Pad 1: (1,2,5); Acties (1); (2); (5) vervallen, blijven over: (3,4,6). • Pad 2: (1,3,6,4,5).

2. Beslissingstabellentest Ter verduidelijking wordt een voorbeeld gebruikt waarbij sprake is van een proces (taak) dat zich bezighoudt met de berekening van het uit te betalen salaris. Het proces wordt opgestart als onderdeel van de maandverw erking.

2.1 Procesbeschrijving De persoon, waarvoor salaris wordt berekend, wordt geïdentificeerd door middel van een nummer, het salarisprogramma controleert of het nummer een geldig nummer is, hetgeen betekent dat de persoon in dienst is. Indien er sprake is van een niet geldig nummer, genereert het systeem een foutmelding (1). De salarisberekening is als volgt: ALS gewerkt =J EN aantal jaren > 10 (2) DAN salaris := 10.000 ANDERS salaris := 5.000 ALS (getrouwd =J OF samenwonen =J) EN land = 'Nederland' (3) DAN salaris := salaris + 5.000 ANDERS ALS leeftijd> 18 EN leeftijd < 60 (4) DAN salaris := salaris + 4.000 Aangemaakt d.d.

27-12-2011

Pagina 123



ANDERS salaris := salaris + 3.000 ALS gewerkt =J EN afdeling = 'produktie' EN leeftijd> 18 DAN salaris := salaris + 1.000

(5)

2.2 Stap 1: Destilleren triggers Welke activiteiten brengen het proces op gang? HIER: de maandverwerking.

2.3 Stap 2: Bepalen determinanten Welke kenmerken zijn van positieve of negatieve invloed op het proces? Bij negatieve determinanten genereert het proces altijd een foutmelding. Triggers zijn ook determinanten. Alle “IF’s” (beslispunten) binnen een proces. HIER: • (0) Maandverwerking (trigger) • (1) Nummer persoon (negatieve determinant) • (2) Indicatie gewerkt/aantal dienstjaren (positieve determinant) • (3) Burgerlijke status/Land (positieve determinant) • (4) Leeftijd (positieve determinant) • (5) Gewerkt/Leeftijd/Afdeling (positieve determinant)

2.4 Stap 3: Vervaardigen beslissingstabellen Regels voor beslissingstabellen: • onder dubbele strepen staat het resultaat vermeld; • de logische testkolommen ontstaan door de waarden die de determinanten kunnen aannemen; • waarde van de determinanten kunnen zijn: (1): waar; (0): onwaar; (-): n.v.t.; • triggers hebben altijd de waarde (1) • resultaten kunnen de waarde krijgen: (X): treedt op; ( ): treedt niet op; (?): niet bekend; • als bij resultaat (→) vermeld staat betekent dit dat deze situatie geldt bovenop alle volgende situaties; • beginnen met negatieve determinanten in een beslissingstabel te zetten en de trigger hierin op te nemen; • vervolgens kolommen doornummeren en de positieve determinanten in een beslissingstabel zetten. Teststrategie bepaalde de testmaat: 1. alle combinaties van determinanten, dus alle mogelijke situaties worden getest; 2. het minimum aantal situaties wordt getest, waarbij iedere determinant in ieder geval één keer “0” en één keer “1” is; 3. alles tussen de twee bovenstaande strategieën. Negatieve determinanten en triggers: Salarisberekening Logische testkolom 1 2 Trigger: maandverwerking 1 1 Determinant: ‘nummer persoon’ 1 0 Foutmelding X → Positieve determinanten volgens testmaat 2: minimum aantal situaties: Salarisberekening Logische testkolom 3 4 5 6 7 maandverwerking 1 1 1 1 1 indicatie gewerkt/dienstjaren 0 1 1 0 1 burgerlijke status/land 0 0 1 1 1 leeftijd 1 0 -(1) -(0) -(0) gewerkt/leeftrijd/afdeling 1 0 0 0 1 Salaris X X X X X

Aangemaakt d.d.

27-12-2011

Pagina 124



2.5 Stap 4: Specificeren logische testgevallen Er kunnen samengestelde determinanten (X>0 EN Y=3) aanwezig zijn. Deze determinanten kunnen op meerdere manier waar of onwaar zijn. Er dient een detailleringsmaat aangebracht te worden om de determinanten enkelvoudig te maken. Slechts dan is de logische testkolom gelijk aan een logisch testgeval. Detailleringsmaten: 1. multiple condition coverage: alle mogelijke combinaties worden getest; 2. decision coverage: test door samengestelde determinant één keer waar en één keer onwaar; 3. condition coverage: test door enkelvoudige determinaten één keer waar en één keer onwaar; 4. decision/condition coverage: combinatie van 2 én 3; 5. condition/determination coverage: test door enkelvoudige determinanten twee keer de waarde van de samengestelde determinant te laten bepalen. Bij de salarisberekening gelden vier samengestelde determinanten: • indicatie gewerkt / aantal dienstjaren • burgerlijke status / land • leeftijd • gewerkt / leeftijd / afdeling Volgens detailleringsmaat ‘decision coverage’ betekent dit voor ons voorbeeld het volgende: Determinant 2 indicatie gewerkt aantal jaren Det.2 = waar 1 1 Det.2 = onwaar 1 0 Determinant 3 getrouwd samenwonen land Det.3 = waar 1 0 1 Det.3 = onwaar 0 1 0 Determinant 4 leeftijd>18 leeftijd<60 Det.4 = waar 1 1 Det.4 = onwaar 0 1 Determinant 5 indicatie gewerkt afdeling leeftijd>18 Det.5 = waar 1 1 1 Det.5 = onwaar 1 0 1

2.6 Stap 5: Transformeren van de logische testkolommen naar testgevallen Er zijn nu twee mogelijkheden om de logische testkolommen te transformeren in logische testgevallen: • splitsen: alle samengestelde determinanten opgesplitst en benoemd; • onderbrengen: één op één transformatie van testkolom naar testgeval. Voorbeeld splitsen en onderbrengen: Identificatie tabel Logische 1 2 3 4 testkolommen Trigger 1 1 1 1 A>0 1 0 0 0 B=6 0 1 0 0 C=2 EN D=4 EN E=5 0 0 1 0 F<0 OF G>0 0 0 0 1 Resultaat 1 X Resultaat 2 X X X Detailleringsmaat ‘condition/determination coverage’: Nummer C=2 D=4 E=5 Res. C, D en E bepalend 1 1 1 1 E bepalend 1 1 0 0 D bepalen 1 0 1 0 C bepalend 0 1 1 0 Detailleringsmaat ‘condition/determination coverage’: Nummer F>0 G<0 Res. F en G bepalend 0 0 0 Aangemaakt d.d.

27-12-2011

5 1 1 1 1 1 X X

Pagina 125

Uittreksel Titel: Testen volgens TMap G bepalend F bepalend Splitsen levert op: Identificatie tabel Logische testgevallen Trigger A>0 B=6 C=2 D=4 E=5 F<0 G>0 Resultaat 1 Resultaat 2

Aangemaakt d.d.


0 1

1a 1 1 0 1 1 0 0 0 X

1 0

1b 1 1 0 1 0 1 0 0 X

27-12-2011

1 1

1c 1 1 0 0 1 1 0 0 X

2a 1 0 1 1 1 0 0 0

2b 1 0 1 1 0 1 0 0

2c 1 0 1 0 1 1 0 0

3 1 0 0 1 1 1 0 0

4a 1 0 0 1 1 0 0 1

4b 1 0 0 1 0 1 1 0

4c 1 0 0 0 1 1 1 0

X

X

X

X

X

X

X

5a 1 1 1 1 1 1 0 1 X X

5b 1 1 1 1 1 1 1 0 X X

Pagina 126

Uittreksel Titel: Testen volgens TMap Onderbrengen levert op: Identificatie tabel Logische testgevallen Trigger A>0 B=6 C=2 D=4 E=5 F<0 G>0 Resultaat 1 Resultaat 2

1 1 1 0 1 1 0 0 0 X


2 1 0 1 1 0 1 0 0

3 1 0 0 1 1 1 0 0

4 1 0 0 0 1 1 0 1

X

X

X

5 1 1 1 1 1 1 1 0 X X

Voor ons voorbeeld betekent dit bij onderbrengen: Salarisberekening Logische testgevallen 1 2 Trigger 1 1 Det.1 nummer persoon 1 0 Det.2 gewerkt = J 1 1 Det.2 Aantal jaren > 10 0 1 Det.3 Getrouwd = J 0 0 Det.3 Samenwonen = J 1 1 Det.3 land = Nederland 0 0 Det.4 leeftijd > 18 1 0 Det.4 leeftijd < 60 1 1 Det.5 gewerkt = J 1 1 Det.5 afdeling = produktie 1 0 Det.5 leeftijd > 18 1 0 Foutmelding X Salaris 10000

3 1 0 1 1 1 0 1 1 0 1

4 1 0 1 0 1 0 1 1 0 1

5 1 0 1 1 1 0 1 1 1 1

13000

15000

16000

3. Dataflowtest Ter verduidelijking wordt een voorbeeld gebruikt waarbij sprake is van een proces (taak) dat zich bezighoudt met het uitbrengen en afhandelen van offertes.

3.1 Procesbeschrijving Een offerte wordt door een vertegenwoordiger ingebracht, waarbij per artikel een offerteregel wordt gemaakt. Allerhande variaties met kortingen, leverings- en betalingscondities, enz. zijn mogelijk. De chef van de vertegenwoordiger kan de offerte goedkeuren. Er is dus sprake van functiescheiding. Zodra de offerte is goedgekeurd kan hij worden afgedrukt om verstuurd te worden. Als de offerte is afgedrukt, kan deze niet meer worden gewijzigd. Een goedgekeurde (nog niet afgedrukte) offerte die wordt gewijzigd, krijgt automatisch weer de status ‘voorlopig’. Na verloop van tijd komt een antwoord van de klant op de verstuurde offerte waarbij de offerte kan worden gegund of worden afgewezen.

3.2 Bepalen testsituaties Dit begint met een inventarisatie van de gegevens die van belang zijn bij de uitvoering van de taak. Twee begrippen per taak: • centrale begrip met relaties naar andere van belang zijnde begrippen, de • randbegrippen.

Aangemaakt d.d.

27-12-2011

Pagina 127

Uittreksel Titel: Testen volgens TMap Ons voorbeeld: Begrip Relatie met Offerte afnemer offerte-adres offerteregel verkoopkorting betalingscondities leveringscondities Offerteregel prijs regelkorting regeltekst


Waarden Voorlopig, goedgekeurd, afgedrukt, gegund, afgwezen wel of niet bekend in systeem wel / niet aanwezig aantal: 0, 1 of meer schermen wel / niet invullen wel / niet default uit afnemersgegevens wel / niet default uit afnemersgegevens aantal: 0, 1 of meer schermen wel / niet default wel / niet aanwezig wel / niet invoeren

3.3 Bepalen testgevallen Bij het bepalen van de testgevallen moet ervoor worden gezorgd dat alle testsituaties (waarden) minstens eenmaal voorkomen. Testgeval Offerte: Afnemer Offerte-adres Verkoopkorting Betalingscondities Leveringscondities Offerteregel: Artikel aantal prijs regelkorting regeltekst

Offerte-1

Offerte-2

Offerte-3

AFN_1 aanwezig invoeren default default

nieuw invoeren invoeren invoeren invoeren

AFN_2 invoeren niet default overschrijven default overschrijven

0 -

1 wel wel niet

meer schermen wel/niet default wel/niet aanwezig wel/niet invoeren

3.4 Bepalen testacties Een testactie is een vooraf gedefinieerde actie die goed of fout kan verlopen. Per begrip moet worden bekeken welke functies hierop van toepassing zijn. •

•

• •

•

•

1. 001 002 003 2. 004 005 006 007 008 3. 009 4. 010 011 012 013 5. 014 015 6.

Invoeren Voer in offerte-1 Voer in offerte-2 Voer in offerte-3 Wijzigen Status voorlopig Status goedgekeurd (niet afgedrukt) Status afgedrukt * Status gegund * Status afgewezen * Afbeelden offerte Afbeelden offerte Afdrukken offerte Status voorlopig * Status goedgekeurd Status afgedrukt * Status gegund * Overzicht offerte Overzicht offertes na invoeren Overzicht offertes met gemengde status Fiatteren offerte van status naar status 016 voorlopig goedgekeurd 017 ……

Aangemaakt d.d.

27-12-2011

Pagina 128



* geeft aan dat er na de betreffende actie een foutboodschap dient te volgen.

3.5 Bepalen controles Beschreven moet worden op welke wijze gecontroleerd wordt dat de verwerking correct verloopt. • • • •

CO1 Totaal bedrag offerte op scherm bij regelinvoer, wijziging of verwijdering C02 Volledigheid bij afdrukken C03 Offertenummer ophogen in stuurgegevens C04 ……..

3.6 Vaststellen initiële gegevensverzameling Er moet worden vastgesteld of t.b.v. de testuitvoering een initiële gegevensverzameling aanwezig dient te zijn. •

•

Afnemers: AFN_1 t.b.v. testgeval Offerte-1 AFN_2 t.b.v. testgeval Offerte-2 Artikelen: …….

4. Elementaire vergelijkingentest Ter verduidelijking wordt het volgende voorbeeld gebruikt.

4.1 Procesbeschrijving ALS naam = 'Frank' OF woonplaats = 'Haarlem' DAN zakgeld := 5,00 ANDERS zakgeld := 3,50 ALS leeftijd> 10 EN werk = 'ja' DAN zakgeld := zakgeld +1,00 ANDERS ALS naam = 'Frank' DAN zakgeld := zakgeld +0,50

4.2 Analyse functiebeschrijving Alle “ALS ….. DAN opdracht [ANDERS] [opdracht]” dienen geanalyseerd te worden door ze er één voor één uit te lichten en voorzien van een unieke codering. Dit geldt alleen voor de “ALS, DAN, ANDERS” als ze aangestuurd worden door gegevensinvoer, zogenaamde lussen (ZOLANG teller < 10 DOE) worden niet meegenomen in de elementaire vergelijkingentest. C1

ALS naam = 'Frank' OF woonplaats = 'Haarlem' DAN zakgeld := 5,00 ANDERS zakgeld := 3,50

C2

ALS leeftijd> 10 EN werk = 'ja' DAN zakgeld := zakgeld +1,00

C3

ANDERS ALS naam = 'Frank' DAN zakgeld := zakgeld +0,50

4.3 Bepalen testsituaties Alle condities zijn benoemd (C1 t/m C3). Nu moet er worden gekeken naar samengestelde (EN / OF) condities en enkelvoudige condities. Hiervoor gelden de volgende regels: • samengestelde OF condities worden getest op: • onwaar-onwaar; waar-onwaar; onwaar-waar; waar-waar wordt niet getest. • samengestelde EN condities worden getest op: • waar-waar; onwaar-waar; waar-onwaar; onwaar-onwaar wordt niet getest. Aangemaakt d.d.

27-12-2011

Pagina 129



Conditie C1 testsituatie 1 testsituaties 2 testsituatie 3 • naam Frank <>Frank <>Frank • woonplaats <>Haarlem Haarlem <>Haarlem C2 • leeftijd >10 >10 10 • werk ja nee ja C3 • naam Frank <>Frank (⇒ - C2) C3 is afhankelijk van C2: alleen als conditie C2 onwaar is wordt C3 aangeroepen.

4.4 Bepalen testgevallen De kunst is het zo min mogelijk testgevallen nodig te hebben, echter alle condities dienen conform de uitwerking van de testsituaties getest te worden. Testgeval Pers-1 Pers-2 Pesr-3 Pers-4 • naam Frank Frank Jos Léon • woonplaat Geleen Kerkrade Haarlem Brunssum s • leeftijd 23 14 10 20 • werk ja nee ja ja

4.5 Vervaardigen testgeval / testsituatie matrix • •

Horizontaal : alle gedefinieerde testgevallen Verticaal : alle gedefinieerde testsituaties Pers- Pers- Pesr- Pers1 2 3 4 C1.1 X X C1.2 X C1.3 X C2.1 X X C2.2 X C2.3 X C3.1 X C3.2 X Als de testgevallen bekend zijn kunnen, mede op basis daarvan, de testacties worden bepaald. Bij dit voorbeeld wordt ervan uit gegaan dat de testgevallen in een testset worden opgeslagen en de test via een batch-job wordt uitgevoerd

4.6 Bepalen controles Beschreven dient te worden welke gegevens moeten worden gecontroleerd. De testgevallen worden doorberekend. • C01: Pers-1 zakgeld: 5,00 + 1,00 = 6,00 • C02: Pers-2 zakgeld: 5,00 + 0,50 = 5,50 • C03: Pers-3 zakgeld: 5,00 • C04: Pers-4 zakgeld: 3,50 + 1,00 = 4,50

4.7 Vaststellen initiële gegevensverzameling Personen: • Frank woonachtig te Geleen, 23 jaar en indicatie werk op ja; • Frank woonachtig te Kerkrade, 14 jaar en indicatie werk op nee; • Jos woonachtig te Haarlem, 10 jaar en indicatie werk op ja; • Léon woonachtig te Brunssum, 39 jaar en indicatie werk op ja; Woonplaatsen: • Geleen t.b.v. testgeval Pers-1; • Kerkrade t.b.v. testgeval Pers-2; • Haarlem t.b.v. testgeval Pers-3; Aangemaakt d.d.

27-12-2011

Pagina 130



Brunssum t.b.v. testgeval Pers-4;

Aangemaakt d.d.

27-12-2011

Pagina 131



4.8 Testsituaties bepalen bij elementaire vergelijkingentest Pseudocode: DOE voor alle personen waarvoor geldt dat datum_geboorte >= 1-1-1964 EN cd_geslacht= 2 EN brd_inkomen < 45000 DAN brd_korting = 50 ALS datum_inschrijving < 1-1-1988 EN srt_lidmaatschap = 'algemeen' EN ind_wanbetaler = 0 EN (srt_speler = 'comp' OF niv~speler = 'c') DAN bedr_korting = 100 EIND-ALS EIND-DOE Analyse pseudocode: Werk DOE- en ALS-regels één voor één uit: • DOE: • datum_geboorte >= 1-1-1964 : D1 • cd-geslacht = 2 : D2 • bdr_inkomen < 45000 : D3 • ALS: • datum_inschrijving < 1-1-1988 : A1 • srt_lidmaatschap = ‘algemeen’ : A2 • ind_wanbetaler = 0 • srt_speler = ‘comp’ • niv_speler = ‘c’ : A5

: A3 : A4

Gebruik het “&”-teken om EN-koppelingen en het “|”-teken voor OF-koppelingen en schrijf de relaties uit met bovenstaande coderingen: • •

DOE : D1 & D2 & D3 ALS : A1 & A2 & A3 & (A4 | A5)

Werk volgens de regels beschreven in 4.3. iedere relatie van links naar rechts uit. Controle: aantal testsituaties = aantal condities + 1 •

DOE : D1 & D2 & D3 wordt opgesplitst in: D1 & D2 (D3=1) én D2 & D3 (D1=1): D1 en D2 bepalend D1& D2& D3 0 1 1 1 0 1 1 1 1

D2 en D3 bepalend D1& D2& 1 0 1 1 1 1

Gecombineerd D3 1 0 1

1 2 3 4 5 6

Geen invloed door een & dan waarde = 1 Geen invloed door een | dan waarde = 0 Omzetten naar bijbehorende waarden datum_geboorte cd_geslacht bdr_inkomen 01-01-1979 2 40000 01-01-1960 1 40000 01-01-1960 2 50000 01-01-1960 2 40000 •

D1& 0 1 1 1 1 1

D2& 1 0 1 0 1 1

D3 1 1 1 1 0 1

Eliminatie dubbele

=4 =6

D1& 0 1 1 1

D2& 1 0 1 1

D3 1 1 1 0

=2 =3

ALS : A1 & A2 & A3 & ( C4 | C5 ) wordt opgesplitst in:

A1&

A1 en A2 bepalend A2& A3& (A4| A5)

Aangemaakt d.d.

A2 & A3 bepalend A1& A2& A3& (A4| A5)

27-12-2011

A3 en A4 bepalend A1& A2& A3& (A4| A5)

A4 en A5 bepalend A1& A2& A3& (A4| A5) Pagina 132

Uittreksel Titel: Testen volgens TMap 0 1 1 A1& 0 1 1 1 1 1 1 1 1 1 1 1

1 1 1 0 1 1 1 1 1 Gecombineerd A2& A3& (A4| 1 0 1 0 1 1 1 1 1 1 1 1

1 1 1 1 0 1 0 1 1 1 1 1

1 1 1 1 1 1 1 0 1 0 1 0

0 0 0 A5) 0 0 0 0 0 0 0 0 0 0 0 1

Onderwerp: Test Management Approach 1 1 1

0 1 1 0 1 0 1 0 1 1 1 0 Eliminatie dubbele: A1& A2& A3& (A4| A5) 0 1 1 1 1 1

1 0 1 1 1 1

1 1 1 0 1 1

1 1 1 1 0 0

0 0 0 0 0 1

1 1 1

1 1 1

0 1 0 1 1 1 0 0 1 0 0 1 1 1 1 0 1 1 0 1 1 1 0 1 Omzetten naar bijbehorende waarden dat_insch srt_lidm. Ind_wanb. Srt_speler niv_speler r 01-01-90 algemeen 0 comp b 01-01-78 jeugd 0 comp b 01-01-78 algemeen 1 comp b 01-01-78 algemeen 0 club b 01-01-78 algemeen 0 club c 01-01-78 algemeen 0 comp b

5. Procescyclustest 5.1 Procesbeschrijving

Figuur 24 Procedure-flow Bij de afdeling klantenregistratie komen mutatieformulieren binnen betreffende de gegevens van een klant. De mutatieformulieren komen binnen bij het afdelingshoofd die deze formulieren vervolgens doorgeeft aan een medewerker van de afdeling. Afhankelijk van de soort mutatie (wijzigen, invoeren of verwijderen) wordt een onderhoudsfunctie met betrekking tot de gegevens opgestart. Indien het een nieuwe klant betreft (mutatiesoort = invoeren) moet afhankelijk van de landcode een bepaald vervolgscherm worden ingevuld. Nadat de betreffende mutatie is doorgevoerd, geeft de medewerker schriftelijk een gereedmelding aan het afdelingshoofd, deze controleert met behulp van de functie fiatteren gegevens de aangebrachte mutatie. Indien accoord wordt de mutatie gefiatteerd en is de procedure beëindigd. Indien echter een fout wordt aangetroffen, wordt de mutatie opnieuw aangeboden aan de betreffende medewerker. Volgens de procedure-flow zijn de padcombinaties: • bij beslispunt A: (1,2); (1,3); (1,4); (8,2); (8,3); (8,4); • bij beslispunt B: (3,5) en (3,6); • bij beslispunt C: (2,7); (4,7); (5,7); (6,7); (2,8); (4,8); (5,8) en (6,8). Vervolgens moeten deze padcombinaties 'aan elkaar worden geknoopt' tot paden die van het begin van de procedure-flow tot aan het eind van de procedure-flow lopen.

Werkwijze procescyclustest testmaat 2 - bepalen padcombinaties + paden De padcombinaties zijn: (1,2); (1,3); (1,4); (2,7); (2,8); (3,5); (3,6); (4,7); (4,8); (5,7); (5,8); (6,7); (6,8); (8,2); (8,3); (8,4). Deze combinaties worden naar de volgende paden vertaald: • Pad 1: (1,2,7) • Pad 2: (1,3,5,7) • Pad 3: (1,4,7) • Pad 4: (1,2,8,2,7) • Pad 5: (1,3,6,7) • Pad 6: (1,4,8,3,5,8,4,7) • Pad 7: (1,3,6,8,2,7)

Aangemaakt d.d.

27-12-2011

Pagina 133

Uittreksel Titel: Testen volgens TMap Controletabel: Padcominaties (1,2,7) (1,3,5,7) (1,4,7) (1,2,8,2,7) (1,3,6,7) (1,4,8,3,5,8,4,7) (1,3,6,8,2,7)


(1,2) (1,3) (1,4) (2,7) (2,8) (3,5) (3,6) (4,7) (4,8) (5,7) (5,8) (6,7) (6,8) (8,2) (8,3) (8,4) X X X X X X X X X X X X X X X X X X X X X X X X X X

Werkwijze procescyclustest testmaat 1 - bepalen padcombinaties + paden Regels: • een testpad begint bij het startpunt en eindigt bij het eindpunt; • alle afzonderlijke activiteiten moeten minimaal eenmaal in een testpad voorkomen; • er wordt naar gestreefd een zo klein mogelijk aantal testpaden met daarin alle mogelijke combinaties. Werkwijze: 1. kies eerst het kortste pad van begin tot eind; 2. neem het laatste beslispunt en combineer de kortste met een pad dat nog niet voorkomt; 3. ga één beslispunt terug en kies een pad dat nog niet voorkomt; 4. herhaal punt 3. Totdat alle beslispunten geanalyseerd zijn. Uitwerking (zie figuur 23): • Pad 1: (1,2,7): kortste van begin tot eind; • Pad 2: (1,2,8,3,5,7): vanuit C: (8,3,5) + (1,2,7); • Pad 3: (1,3,6,8,4,7): vanuit B: (6,8,4) + (1,3,7), (3) omdat anders niet met (6) begonnen kan worden. Controle: Padcominaties (1,2,7) (1,2,8,3,5,7) (1,3,6,8,4,7)

(1,2) (1,3) (1,4) (2,7) (2,8) (3,5) (3,6) (4,7) (4,8) (5,7) (5,8) (6,7) (6,8) (8,2) (8,3) (8,4) X X X X X X X X X X X X X X X X X

6. Semantische test 6.1 Uitwerken relatiecontroles De relaties worden uitgewerkt in ALS, DAN en ANDERS-vergelijkingen, waarbij EN / OF-vergelijkingen zijn toegestaan.

Voorbeeld 1 De ingangsdatum van de ingevoerde adreswijziging moet liggen na de einddatum die is aangegeven bij het vorige adres van de pensioengerechtigde. Is dit niet het geval dan volgt een foutboodschap. Dit levert in het kader van het testen de volgende vergelijking: ALS 'einddatum oude adres' ingangsdatum nieuwe adres' DAN foutboodschap ANDERS correcte invoer

(a) (testpad 1) (testpad 2)

In dit voorbeeld wordt een tweetal testpaden onderkend, testpad 1 waarin de bewering (a) waar is (einddatum >= begindatum) en het testpad 2 waarin de bewering (a) onwaar is (einddatum < begindatum).

Voorbeeld 2 Een voorbeeld met meerdere paden is de volgende controle: ALS minimum voorraad code gelijk is aan S(ignaal) DAN ALS aantal millimum voorraad gelijk is aan nul Aangemaakt d.d.

27-12-2011

(a) (b) Pagina 134



DAN foutboodschap 1O3 (testpad 1) ANDERS correcte invoer (testpad 2) ANDERS correcte invoer (testpad 3) Indien de minimum voorraadcode ongelijk aan S is, vindt geen verdere controle plaats (testpad 3). Indien de minimum voorraadcode gelijk aan S is, en het aantal minimum voorraad is nul volgt een foutboodschap (testpad 1). Als het aantal minimum voorraad ongelijk aan nul is, de bewering (a) is waar en de bewering (b) is onwaar, volgt geen foutboodschap (testpad 2).

6.2 Vaststellen testacties en controles Voorbeeld 2 M.b.t.

het voorbeeld van het voorraadsysteem kunnen de volgende testacties worden onderkend:

A0l A02 A03

Invoeren min. voorraadcode S en aantal minimum voorraad 0 Invoeren min. voorraadcode S en aantal minimum voorraad 250 Invoeren minimumvoorraadcode B

Bij het uitvoeren van actie AO1 wordt gecontroleerd of de juiste foutboodschap verschijnt: C0l

FB 103: 'bij voorraadcode S minimum voorraadaantal invullen'

Aangemaakt d.d.

27-12-2011

Pagina 135

Uittreksel. Ten geleide

Recommend Documents