TESTEN smartsite

download TESTEN smartsite

of 64

  • date post

    13-Jul-2015
  • Category

    Documents

  • view

    588
  • download

    2

Embed Size (px)

Transcript of TESTEN smartsite

Velden in rechterkolom pas Invullen nadat de practice is aangepast.Naam Best Practice Bestandsnaam Datum aangepast Omschrijving van de inhoud Soort document ASL Processen Opmerkingen Zo testen we bij 0303_bp.doc 20/09/2002 Beschrijving van het gehele testproces voorafgaand aan de acceptatie van een applicatie Procedure Testing

Zo testen we bij template rapport

Naam vestiging Plaats vestigingAdres Postbus Postcode PlaatsT +31 F +31 I www. .

Plaats Datum Auteur Status

Plaats 23 December 2011 Auteur Concept 0.1

Zo testen we bij 23 december 2011 2/64

Inhoudsopgave1 Inleiding............................................................................................................6 1.1 Leeswijzer, doelgroep..................................................................................6 2 Overzicht aanbevolen testtechnieken............................................................7 2.1 Aanbevolen..................................................................................................7 2.2 Aanbevolen voor specifieke situaties...........................................................8 2.3 Niet aanbevolen.........................................................................................10 3 Testen, wat is dat?.........................................................................................19 3.1 Gestructureerd testen; fasering testproces................................................21 4 Kwaliteitsattributen........................................................................................23 4.1 Inleiding.....................................................................................................23 4.2 Beheerbaarheid.........................................................................................23 4.3 Beveiliging.................................................................................................24 4.4 Bruikbaarheid.............................................................................................24 4.5 Connectiviteit.............................................................................................24 4.6 Continuteit................................................................................................25 4.7 Controleerbaarheid....................................................................................25 4.8 Flexibiliteit..................................................................................................26 4.9 Functionaliteit.............................................................................................26 4.10 Gebruikersvriendelijkheid........................................................................26 4.11 Herbruikbaarheid.....................................................................................27 4.12 (Geschiktheid) Infrastructuur....................................................................27 4.13 Inpasbaarheid..........................................................................................27 4.14 Onderhoudbaarheid.................................................................................28 4.15 Performance............................................................................................28 4.16 Portabiliteit...............................................................................................28 4.17 Testbaarheid............................................................................................29 4.18 Zuinigheid................................................................................................29 5 Testsoorten.....................................................................................................30 5.1 Testvormen................................................................................................30 5.2 Testmomenten...........................................................................................31 6 Test(specificatie)technieken.........................................................................34 6.1 Algoritmetest..............................................................................................34 6.2 Beslissingstabellentest..............................................................................35 6.3 Checklist....................................................................................................35 6.4 Collegiale toets..........................................................................................36 6.5 Dataflowtest (DFT).....................................................................................36 6.6 Document Inspection.................................................................................37 6.7 Document Review......................................................................................37 6.8 Elementaire vergelijkingentest (EVT).........................................................38Zo testen we bij 23 december 2011 3/64

6.9 Error Guessing...........................................................................................38 6.10 Gegevenscyclustest.................................................................................39 6.11 Heuristic Evaluation ................................................................................39 6.12 Intake Testbasis ......................................................................................40 6.13 Procescyclustest (PCT)...........................................................................40 6.14 Programma interfacestest (PIT)...............................................................41 6.15 Real-life test.............................................................................................41 6.16 Sumi .......................................................................................................42 6.17 Syntactische en Semantische test...........................................................42 6.18 Use cases................................................................................................43 7 De combinatie kwaliteitsattributen, testvormen, testspecificatie technieken.........................................................................................................44 7.1 Testsoorten per kwaliteitsattribuut.............................................................44 7.2 Testmoment per kwaliteitsattribuut............................................................45 7.3 Testtechniek per kwaliteitsattribuut............................................................46 7.4 Testmoment per Testsoort.........................................................................47 7.5 Testmoment per Testtechniek...................................................................48 8 Bijlage A Begrippenlijst.................................................................................49 9 Bijlage B Tmap kwaliteitsattributen in relatie tot ISO 9126........................57 9.1 Definities ISO 9126 kwaliteitsattributen ....................................................57 9.2 Vertaaltabel ISO 9126 - Nederlands .........................................................60 9.3 Vertaaltabel ISO 9126 - TMap...................................................................61 9.4 Vertaaltabel TMap - ISO 9126 ..................................................................62 10 Bijlage C Literatuur......................................................................................63

Zo testen we bij 23 december 2011 4/64

VersiebeheerVersie Datum 0.1 Auteur Auteur Omschrijving Initieel document

DistributielijstVersie Datum 0.1 Aan

Zo testen we bij 23 december 2011 5/64

1InleidingDit document beschrijft een groot aantal begrippen rondom testen. Hierbij zijn de relevante indelingen in methoden, technieken gehanteerd om zo overzicht te scheppen in de terminologie. Omdat elke methode en auteur vaak eigen termen introduceert is het gevaar van verwarring groot. Hier is gekozen om de begrippen van Tmap als uitgangspunt te hanteren. Aan dit begrippenkader zijn een beperkt aantal termen toegevoegd die nu gangbaar zijn in onze organisatie (bijvoorbeeld 'pilot') of die te maken hebben met 'toetsen' (bijvoorbeeld; document inspection).

1.1Leeswijzer, doelgroep Het doel van dit document is een overzicht te schetsen van het begrippenkader rondom toetsen en testen. In het volgende hoofdstuk wordt eerst een samenvattend overzicht gegeven van de testtechnieken. In de hoofdstukken daarna volgen de definities van en toelichtingen op de gebruikte begrippen. Gedetailleerde informatie is te vinden in het Tmap boek dat als naslagwerk beschouwd wordt (zie bijlage C voor literatuurverwijzing). Hoewel niet altijd expliciet vermeld, is het meeste overgenomen uit Tmap. Definities worden voorafgegaan door de term in cursief. Een overzicht van de meeste termen is in bijlage A opgenomen. De relatie met de begrippen van ISO 9126 is in bijlage B opgenomen. De doelgroep van dit document is breed; van projectboard tot ontwikkelaars. Het doel is immers iedereen hetzelfde begrippenkader te geven. De projectboard zal hierbij meer de kwaliteitsatributen en testmomenten bezigen terwijl voor de projectleden (ontwerpers, ontwikkelaars en consultants) de testtechnieken tot hun scope behoren. Dit document is opgesteld met de ontwikkeling van standaardprogrammatuur in het achterhoofd. Kenmerkend voor standaardprogrammatuur is dat deze niet op specificaties van n klant wordt gemaakt, dat een versie van de software door meerdere klanten wordt gebruikt en dat onderhoud voor alle gebruikers tegelijk wordt gedaan buiten de organisatie van de gebruikers. De eisen die hierdoor aan de kwaliteit van de software worden gesteld vertalen zich uiteraard door in het testtraject. Daarmee is natuurlijk niet gezegd dat dit document onbruikbaar is bij de ontwikkeling van maatwerk software. Dit document is verder geschreven met de situatie van SP anno 2000 in het achterhoofd. Naarmate Test Process Improvement meer resultaten boekt zal herziening van de tekst noodzakelijk worden. Op- en aanmerkingen zijn altijd welkom. Indienen bij de leden van het Competence Team Testen (CT Testen).

Zo testen we bij 23 december 2011 6/64

2Overzicht aanbevolen testtechniekenDe wijze van toetsen-en-testen staat niet los van de andere methoden en technieken die gebruikt worden binnen . De testbasis wordt voor een belangrijk deel gedefinieerd door de producten beschreven door het Competence Team Software Ontwikkelmethodiek (CT-Som). De requirements en het acceptatieplan geven inzicht op welke kwaliteitscriteria gestuurd wordt. In de productdescriptions worden kwaliteitsmethoden gekoppeld aan de beschreven producten. Op basis van deze input is het mogelijk een set testtechnieken samen te stellen die voorziet in het gros van het toetsen-en-testen binnen Civlity. De benodigde testbasis voor de technieken wordt daardoor aanwezig verondersteld. Indien dit in de praktijk niet het geval is, zal de techniek alsnog afvallen of moet bij gebruik op extra inspanning gerekend worden. De testbasis zal alsnog gemaakt moeten worden. Want ook voor testen geldt: garbage-in is garbage-out. Schijnkwaliteit is dan het resultaat. De niet aanbevolen technieken zijn uiteraard niet verboden, maar deze zijn volgens ons alleen (nu) minder voor de hand liggend.

2.1Aanbevolen Algoritmetest Doordat de ontwikkelaar bekend is met de interne structuur van het programma, is een grondige test mogelijk. Deze is ook nodig om vroegtijdig fouten te ontdekken. Variatie in diepgang is bij deze techniek te sturen. Checklist Checklisten zijn relatief snel te maken en toe te passen. De kwaliteit van de test wordt bepaald door de kwaliteit van de checklist. Duidelijke standaards dienen de grondslag te vormen. Maar als start zijn ook checklists te maken op basis van ongedocumenteerde werkwijzen, kennis en ervaring. Ze zetten zo het begin van een testverbeteringproces in, maar mogen niet als eindpunt gezien worden. Collegiale toets Deze toetsing is al vaak opgenomen in productdescriptions. Toch zal de uitvoering van de toets iets meer geformaliseerd moeten verlopen dan nu het geval is. De toets is nu vaak niet controleerbaar en aantoonbaar. Voor de combinatie kwaliteitcriteria en te-controleren-product dienen aandachtspuntlijstjes gemaakt te worden. Intake testbasis Een zorgvuldige intake van de testbasis is om diverse redenen zinvol. De kwaliteit, testbaarheid, risicos, noodzakelijke inspanning van het testtraject worden vroegtijdig zichtbaar. Voor de diverse testtechnieken zijn in Tmap intakechecklists opgenomen.Zo testen we bij 23 december 2011 7/64

Dataflowtest Deze testtechniek heeft enkele belangrijke voordelen; de kwaliteit van de testbasis is van minder belang, ook niet-automatiseerders kunnen ermee uit de voeten en hij vereist relatief weinig inspanning. Hier tegenover staat wel dat de test beperkt is en meer afhankelijk van de kwaliteit van de tester. Document review Gebruik deze voor documenten die inhoudelijk correct moeten zijn; requirements, ontwerpen, planningen, handboeken, et cetera. Error Guessing Altijd opnemen in integratietest, systeemtest en acceptatietest. De programmeurstest en collegiale toetsing hebben het error guessing element al in zich. Door time-boxing is de hoeveelheid bestede tijd beheersbaar te houden. Gegevenscyclus Tijdens de acceptatietest goed bruikbaar om alle primaire functionaliteit van het systeem te testen. Maar ook in de systeemtest en pilot bruikbaar. Procescyclus Tijdens de acceptatietest maar meer nog tijdens de pilot, omdat dan de procedures van de klant erin betrokken kunnen worden. Syntactisch/semantisch Tijdens programmatest en later tijdens de integratie- systeemtest ter controle. Bij deze laatste eventueel op enkele geselecteerde aspecten en/of steekproefgewijs.

2.2Aanbevolen voor specifieke situaties Document Inspection Gebruik deze voor documenten waarbij de inhoud zeer kritisch is; externe afspraken, grote (financile) consequenties, onderwerp met veel kans op misverstanden, grote lezersgroep, et cetera. Heuristic evaluation Toe te passen bij de opzet van een nieuwe userinterface of bij herontwerp van een bestaande. Externe kennis is hierbij nodig; heeft geen userinterface-deskundigen. Sumi Bij vergelijking van producten. Bijvoorbeeld: Zijn de gebruikers van vrolijker geworden door de komst van Sumi alleen uitvoeren onder toezicht van een deskundige.

Zo testen we bij 23 december 2011 8/64

Use cases Als deze al bij het ontwerp gemaakt worden kunnen ze vervolgens bij de validatie van het ontwerp en de uitvoering van de acceptatietest en pilot gebruikt worden. Het maken van use-cases voor gehele pakketten wordt ontraden; te veel werk.

Zo testen we bij 23 december 2011 9/64

2.3Niet aanbevolen Beslissingstabellen Niet aanbevolen vanwege de vereiste testbasis en de hoeveelheid inspanning. Is wel te overwegen voor zeer complexe verwerking en wanneer in het ontwerp al beslistabellen gebruikt zijn. Elementaire vergelijkingstest Deze testtechniek is arbeidsintensief en is daarom alleen voor complexe verwerkingen zinvol. In de meeste gevallen kan met een algoritmetest afdoende borging bereikt worden. Wil men tijdens de systeemtest alle functioneel verschillende paden doorlopen (wat dus bij een algoritmetest al tijdens de programmatest is gedaan), dan zal alsnog deze testtechniek toegepast moeten worden. Programma Interfacetest De programma interfacetest veronderstelt dat de afzonderlijke programmas al getest zijn met stubs of drivers. Alleen de daadwerkelijke integratie wordt dus getest. In - onze - praktijk zullen koppelingen tussen programmas pas getest worden nadat beide programmas gereed zijn. Bovendien ligt het accent dan vaak op de gezamelijke functionalteit en niet sec op de interface. De functionaliteit wordt al getest door de andere technieken. Alleen zinvol indien: de interfaces hiertoe aanleiding geven, bijvoorbeeld generieke koppelingen met software van derden, het ontwikkelproces zorgt voor strikt onafhankelijke ontwikkeling van de betrokken programmas. Real-life-test Doordat bij het real-life van klant tot klant verschilt, wordt deze techniek niet vaak gebruikt. Het komt voor dat een klant problemen meldt in de productie-omgeving met betrekking tot de kwaliteitsattributen performance, infrastructuur of zuinigheid. Dit wordt als een op-te-lossen probleem afgehandeld, niet als een test.

Zo testen we bij 23 december 2011 10/64

Testtechniek Algoritmetest

Testbasis Interne structuur; bijvoorbeeld programmacode of technisch ontwerp

Principe van afleiden

Kwaliteitsattributen Functionaliteit

Beslissingentabel

Checklist

Verwerkingslogica; decisison coverage in combinatie met path coverage, naar keuze te verzwaren met testmaat 2. Beslissingstabellen Verwerkingslogica; (uit ontwerp) zowel decisison coverage in interne structuur als combinatie met path (functionele) coverage, naar keuze te specificaties verzwaren met decision/ condition coverage en/of met een hogere testmaat. Standaards, Overig; formuleren van voorschriften en eenduidige controles richtlijnen

Toepassings gebieden Verwerking

Testmomenten Programmatest Integratietest

Aanbevolen Programmatest Integratietest

Beveiliging Functionaliteit

Complexe verwerking

Programmatest Integratietest Systeemtest

Neen

Alle (in principe) maar met name die waarvoor (stabiele) normen aanwezig zijn

Alles waarvoor (meetbare) standaards, voorschriften en richtlijnen gelden.

Elk testmoment

Ja, tevens als beginpunt voor testverbetering

Testtechniek

Testbasis

Principe van afleiden Kwaliteitsattributen Toepassings gebieden Daar waar formele eisen (voorschriften e.d.) ontbreken.

Testmomenten

Aanbevolen

Collegiale toets

Alle soorten testbasis

Overig; op basis van gelijkwaardige kennis en kunde van producent en toetser

Beveiliging Connectiviteit Continuteit Controleerbaarheid Functionaliteit Gebruikersvriendelijkh eid Herbruikbaarheid Onderhoudbaarheid Controleerbaarheid Functionaliteit Portabiliteit Controleerbaarheid Functionaliteit

FO-toets TO-toets Programmatest

Ja, tevens als beginpunt voor kwaliteitsverbeter ing

Dataflowtest

Functionele specificaties Document, Brondocumenten verwante documenten, Voorschriften

Equivalentieklassen

Document Inspection

N.V.T.

Verwerking, Integratie tussen functies en gegevens Documenten waarvan inhoud (zeer) kritisch is; grote consequenties, grote lezersgroep

Acceptatietest

Acceptatietest

FO-toets TO-toets

FO-toets

Zo testen we bij 23 december 2011 12/64

Testtechniek

Testbasis

Principe van afleiden Kwaliteitsattributen Toepassings gebieden Documenten die inhoudelijk correct moeten zijn.

Testmomenten

Aanbevolen

Document Review Document, Brondocumenten verwante documenten, Voorschriften Elementaire vergelijkingstest Interne structuur of formele functionele specificaties bijvoorbeeld pseudocode of gestructureerd Nederlands Alle soorten testbasis

N.V.T.

Verwerkingslogica: modified decicion/condition coverage.

Functionaliteit Controleerbaarheid (Beheerbaarheid Connectiviteit Conituteit Flexibiliteit) Controleerbaarheid Functionaliteit

FO-toets TO-toets

Elk document (ontwerp, handleiding, installatiebeschrij ving etc.) Neen

Complexe verwerking

Integratietest Systeemtest

Error Guessing

Overig: Op basis van vermoedens.

Gegevenscyclustest

Functionele specificaties

CRUD; op basis van de levenscyclus van gegevens

Beveilliging Alle Controleerbaarheid Functionaliteit Gebruikersvriendelijkh eid Inpasbaaarheid Performance Zuinigheid Functionaliteit Integratie tussen functies en gegevens

Programmatest Integratietest Systeemtest

Altijd doen.

Systeemtest Acceptatietest Pilot

Acceptatietest

Zo testen we bij 23 december 2011 13/64

Testtechniek

Testbasis

Principe van afleiden Kwaliteitsattributen Toepassings gebieden Gebruiksvriendelijkhei User Interface d Testbaarheid Beveilliging Bruikbaarheid Gebruikersvriendelijkh eid Inpasbaarheid Functionaliteit Elk testtraject Integratie tussen de administratieve organisatie en het systeem Integraties tussen programmas Simulatie van praktijkgebruik

Testmomenten

Aanbevolen

Heuristic Evalutation Intake Testbasis Procescyclustest

Gui (ontwerp of werkend) PID Acceptatieplan Administratieve Organisatie procedures Interne structuur; bijvoorbeeld programmacode of technisch ontwerp Alle soorten testbasis

N.V.T. N.V.T. Verwerkingslogica; decisison coverage standaard met testmaat 2, maar naar keuze te verzwaren of te verlichten. Equivalentiesklassen

FO-toets, TO-toets Testvoorbereidin g Testspecificatie Acceptatietest Pilot

Alleen bij (her)ontwerp userinterface Altijd Pilot

Programma interfacetest Reallifetest

Integratietest

Neen

Operationeel gebruik

Sumi

Werkend systeem, Vragenlijst met Sumi-vragenlijst statistische referenties Sumi-referentiedata

Beveilliging Continuiteit Infrastructuur Performance Zuinigheid Bruikbaarheid Gebruiksvriendelijkhei d

Pilot

Neen

Meting van de bruikbaarheid in het praktijkgebruik

Gebruik

Voor specifieke situaties

Zo testen we bij 23 december 2011 14/64

Testtechniek

Testbasis

Principe van afleiden Kwaliteitsattributen Toepassings gebieden Beveilliging Interactie(schermen, Functionaliteit rapporten, on-line) Gebruikersvriendelijkh tussen systeem en eid gebruiker, validatie op invoer, eenvoudige verwerking Bruikbaarheid Verwerking, Functionaliteit analyse/simulatie praktijkgebruik, Interactie systeemgebruiker,

Testmomenten

Aanbevolen

Syntactische Semantische test

Functionele specificaties

Equivalentiesklassen; voor primaire gegevensdefinities en voor de relaties tussen gegevens bij invoer. Testen van de layout van schermen en rapporten.

Programmatest Systeemtest

Altijd tijdens programmatest en Systeemtest

Use cases

Use-cases die tijdens ontwerp gemaakt zijn

FO-toets TO-toets Acceptatietest Pilot

FO-toets Acceptatietest Pilot

Zo testen we bij 23 december 2011 15/64

De verschillende testtechnieken hebben elk mogelijkheden in zich om de diepgang van de test te varieren en daarmee de voorbereidings- en uitvoeringskosten die aan de test verbonden zullen zijn. Technniek Algoritmetest Beslissingentabel Variren van diepgang door: Hanteren van hogere of lagere testmaat Gebruik van grenswaarden Hanteren van hogere of lagere testmaat Hanteren van hogere of lagere detailleringsmaat Gebruik van grenswaarden Volledige checklist of subset Steekproefgewijs testen Aantal collegas Time-boxing Omvang aandachtspuntenlijst Gebruik van grenswaarden Afhankelijkheden tussen begrippen cq. Equivalentiesklassen in beschouwing nemen Niet van toepassing Aantal reviewers Alle documenten versus alleen essentiele hoofdstukken van belangrijke documenten Gebruik van grenswaarden Multiple condition coverage (ipv modified decision/conditon coverage) Varieren van de te besteden hoeveelheid tijd; Time-boxing. Verminderde diepgang door niet all wijzig-acties op een gegeven in de test te betrekken.

Checklist Collegiale toets

Dataflowtest

Document Inspection Document Review Elementaire vergelijkingstest Error Guessing Gegevenscycluste st

Zo testen we bij 23 december 2011 16/64

Technniek Variren van diepgang door: Niet van toepassing Niet van toepassing Hanteren van hogere of lagere testmaat Expliciet het resultaat van de verwerking controleren (ipv impliciet controleren dat de volgende actie uitvoerbaar is). Gebruik van grenswaarden Variren van de mate van representatieviteit van de test n testomgeving t.o.v. de verwachte productiesituatie. Bij het testen van de performance kan het werkelijk aantal gebruikers gesiumleerd worden of kunnen de resultaten van een kleiner aantal gextrapoleerd worden. Beperking van de testsituaties tit de meest voorkomende productiiesituaties (80%-regel). Niet van toepassing In detail uitschrijven van de testgevallen f hanteren van een checklist; in beide gevallen is de diepgang gelijk maar het opstellen van een checklist kost minder inspanning. Wel stelt dit hogere eisen aan de kennis en ervaring van de uitvoerende tester. Testen van de primaire gegevensdefinites gebeurt niet voor elk scherm (dus wanneer geboortedatum_klantop 2 schermen staat, wordt enkel op het eerste scherm de invoercontrole getest) Op elke primaire gegevensdefinitie zijn vele controles mogelijk, bijvoorbeeld grenswaarden, wel/niet numeriek, spaties, maximale lengte van rubriek gevuld, etc. Hier kunnen beperkingen aangesteld worden. Steekproefgewijs testen Gebruik van grenswaarden Alleen voor (zeer) belangrijke functionaliteit maken Aantal cases per applicatie/functie Varianten op hetzelfde patroon niet uitwerken, slechts benoemen

Heuristic Evalutation Intake Testbasis Procescyclustest Programma interfacetest Reallifetest

Sumi Syntactische Semantische test

Use cases

Zo testen we bij 23 december 2011 17/64

Met betrekking tot tests volgen wede Nederlandse school van Pol, Koomen en Veenendaal grondleggers van Tmap, TPI, TMM, TPA (zie bijlage C).

Zo testen we bij 23 december 2011 18/64

3Testen, wat is dat?

In elk project wordt wel een activiteit "testen" opgenomen, worden er fouten gevonden die na herstel opnieuw getest worden. Dus testen is een vertrouwde bezigheid. Met de invoering van Prince willen we echter geen genoegen meer nemen met het onderscheiden van een activiteit. We willen weten wat het voortbrengt, de resultaten, op te leveren producten. Nu komt dus de vraag "Wat moet het resultaat zijn van testen en hoe meten we dat? Het beantwoorden van deze vraag vergt enige inspanning en de vraag zelf is (helaas) redelijk nieuw voor de organisatie. Testen en toetsen Testen Testen is het proces van plannen, voorbereiden en meten dat ten doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen de actuele en de vereiste status aan te tonen. Het doel van testen is dus het vinden van aanwezige fouten. Het is een open deur te stellen dat foutopsporing 'vroeger in het proces' goedkoper is dan constatering van gebreken in het eindproduct. Het begrip testen wordt vaak gebruikt voor het onderzoeken van het eindproduct. In onze situatie is dat een werkend informatiesysteem (software, documentatie, procedures, etc). Voor de foutopsporing in de fasen dat er nog geen werkend systeem is, worden de termen "toetsen" of "verifiren gebruikt. Het Engelstalige begrip test betreft beide aspecten. Toetsen Het controleren (inspecteren) van tussenproducten en ontwikkelingsprocessen, ofwel verificatie. Testen Het inspecteren van de eindproducten, ofwel de validatie. De voorkeur gaat uit naar de begrippen "toetsen" en "testen". Testen adviseert over de kwaliteit en de risicos van het informatiesysteem. Hierdoor is testen ook een vorm van risicomanagment. Testbasis en testobject Testen heeft dus tot doel om 'het verschil tussen de actuele en de vereiste status aan te tonen'. Deze vereiste status moet dus bekend zijn en liefst niet alleen in de hoofden van enkele medewerkers. Een kwalitatief goede testbasis (requirements, ontwerpen, standaards, et cetera) is noodzakelijk Op basis van halve of onjuiste informatie kunnen geen testgevallen gespecificeerd worden die alle facetten van het testobject in voldoende detail testen. Aan de testbasis zullen dus eisen gesteld worden. Of voldaan is aan deze eisen wordt gecontroleerd bij de testbasis intake. De testbasis dient het gehele testobject te beschrijven. Een duidelijke afbakening van het testobject is nodig.

Bovenstaande sluit niet uit dat een product ook moet voldoen aan niet gedefinieerde maar wel evidente vereisten. (Zie ook Gilb Advanced Software Quality Assurance voor eisen m.b.t requirements.) Testbasis Alle documenten, waaruit de eisen zijn af te leiden, die aan een informatiesysteem worden gesteld. De documentatie waarop de test is gebaseerd. Indien een document nog slechts via de formele wijzigingsprocedure kan worden gewijzigd, spreekt men van een gefixeerde testbasis. Testobject Het te testen (deel van het) informatiesysteem. Resultaten van een testproces Een testproces bevat de volgende producten. Bevindingen Kwaliteitsadvies Testware Testverslagen en rapportages Kengetallen.

Zo testen we bij 23 december 2011 20/64

3.1Gestructureerd testen; fasering testproces Zoals uit de definitie al blijkt is testen een proces met een fasering: Testen is het proces van plannen, voorbereiden en meten. De bij het testen gebruikte begrippen zijn in onderstaand schema gekoppeld aan de fasen van het testproces. De fasering is conform Tmap. De vermelde begrippen worden of in dit document toegelicht of zullen in andere producten van het CompetenceTeamTesten belicht worden. In de begrippenlijst (Bijlage A) zijn alle specifieke begrippen gedefinieerd.

u figuur: fasering testproces figuur: fasering testprocesZo testen we bij 23 december 2011 21/64

Fase Planning en beheer, waarin het fundament wordt gelegd voor het totale testproces. globale intake en studie bepaling van de teststrategie bepaling testbegroting (TPA) inrichting van de organisatie inrichten van het beheer opstellen testplan het rapporteren over voortgang (kwaliteit en activiteiten) Fase Voorbereiding, start zo snel mogelijk na het vaststellen van het testplan. De voorbereiding bestaat uit: intake van de uitgangsdocumentatie toewijzen van de testtechnieken specificeren van de testinfrastructuur Fase Specificatie, nu wordt de test op papier voorbereid, inclusief de verwachte resultaten. Deze fase omvat: opstellen testscripts met behulp van testspecificatietechnieken definiren uitgangsbestanden opstellen testdraaiboek inrichten infrastructuur Fase Uitvoering, het systeem wordt in deze fase geconfronteerd met de gespecificeerde testgevallen. De fase bestaat uit: het in ontvangst nemen van het systeem het opbouwen van de uitgangsbestanden het uitvoeren van de test het nakijken en beoordelen van de testresultaten het rapporteren over de risicos Fase Afronding, het conserveren van de diverse testproducten (testware) en het evalueren van het testproces.

Zo testen we bij 23 december 2011 22/64

4Kwaliteitsattributen

4.1

Inleiding

Een kwaliteitsattribuut is volgens de definitie "een eigenschap van het informatiesysteem". In dit hoofdstuk worden de meest bruikbare kwaliteitskenmerken gedefinieerd en toegelicht. Een uitgebreide toelichting en checklisten om deze kenmerken te beoordelen zijn te vinden in Tmap hoofdstuk 16. De begrippen die ISO 9126 gebruikt en de relatie met de Tmap begrippen zijn in bijlage B opgenomen. Belanghebbende Deze attributen zijn relevant voor de primaire belanghebbende bij het informatiesysteem de eindgebruiker, en de beheerders (systeembeheerder en applicatiebeheerder). Andere belanghebbenden kunnen hieraan nog iets toevoegen bv. SO-Uitleverbaarheid. Belanghebbenden binnen zijn: Eindgebruikers - binnen vertegenwoordigd door Senior User/Acceptatieverantwoordelijke die de belangen vertegenwoordigt van de toekomstige gebruikers en hun organisatie namens Product Management Afdeling B&O onderhoudt Afdeling SO introduceert - die het systeem voor oplevering in beheer neemt en verder - die het systeem binnen de gebruikersorganisatie

Afdeling ST - die de instaleerbaarheid en operationele werking van het systeem op de aangemerkte infrastructuur garandeert en ondersteunt Afdeling CSD - die het systeem verscheept naar de gebruikersorgranisatie voor installatie op het systeem van de organisatie

4.2

Beheerbaarheid

Beheerbaarheid Het gemak waarmee het informatiesysteem in operationele staat kan worden gebracht en gehouden. Beheerbaarheid is primair gericht op het technisch systeembeheer, veelal ondergebracht in een rekencentrum. De installeerbaarheid van hetZo testen we bij 23 december 2011 23/64

informatiesysteem is een onderdeel van beheerbaarheid. Beheerbaarheid wordt gemeten door de maatregelen en hulpmiddelen die het beheer vereenvoudigen c.q. mogelijk maken, met behulp van een checklist te beoordelen.

4.3

Beveiliging

Beveiliging Zekerheid dat raadpleging of mutatie van de gegevens uitsluitend mogelijk is door die personen die daartoe bevoegd zijn. Beveiliging kan in het werkend systeem - worden getest met behulp van de semantische testtechniek en in een eerder stadium - door de opzet en het bestaan van de beveiligingsmaatregelen te beoordelen met behulp van een checklist.

4.4

Bruikbaarheid

Bruikbaarheid De mate waarin het informatiesysteem is toegesneden op de organisatie en het profiel van de eindgebruikers voor wie het bedoeld is en bijdraagt aan het bereiken van de bedrijfsdoelstellingen. Een bruikbaar informatiesysteem komt tot uiting in een verhoogde efficiency van de bedrijfsprocessen. Zal een nieuw systeem wel of niet functioneren in de praktijk? De enige die daar uiteindelijk antwoord op kan geven is de gebruiksorganisatie zelf! Indien het aspect bruikbaarheid expliciet wordt onderkend in de teststrategie, dient hiervoor een aparte testsoort te worden ingericht: de bedrijfssimulatie of proeftuin. Tijdens een bedrijfssimulatie test een aselecte groep potentile gebruikers de bruikbaarheidaspecten van het product in een omgeving die de 'natuurlijke' omgeving waarin men het systeem gaat gebruiken, zoveel mogelijk benadert. De test vindt plaats aan de hand van een aantal praktijkgerichte opdrachten c.q. testscripts.

4.5

Connectiviteit

Connectiviteit Het gemak waarmee een koppeling met een ander informatiesysteem of binnen het informatiesysteem tot stand kan worden gebracht en kan worden gewijzigd. De connectiviteit kan sterk worden bevorderd door gebruik te maken van standaardisatie. Een veel gebruikte internationale norm op dit gebied is de OSIstandaard. Connectiviteit kan worden getest door de betreffende maatregelen met behulp van een checklist te beoordelen.

Zo testen we bij 23 december 2011 24/64

4.6

Continuteit

Continuteit 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 Continuteit kan worden uitgesplitst in attributen die achtereenvolgens van toepassing zijn bij toenemende verstoring van het informatiesysteem: Bedrijfszekerheid De mate waarin de gegevensverwerking vrij blijft van storingen. Robuustheid De mate waarin de informatievoorziening ook na een storing gewoon door kan gaan. Herstelbaarheid Het gemak en de snelheid waarmee de informatievoorziening na een storing hersteld kan worden. Degradatiemogelijkheid Het gemak waarmee de kern van de informatievoorziening kan worden voortgezet nadat een deel is uitgevallen. Uitwijkmogelijkheid Het gemak waarmee (een deel van) de informatievoorziening op een andere locatie kan worden voortgezet.

4.7ControleerbaarheidControleerbaarheid Het gemak waarmee de juistheid en de volledigheid van de informatie (in het verloop van de tijd) gecontroleerd kunnen worden.

Bekende middelen ter verhoging van de controleerbaarheid zijn controletotalen, vierkantstellingen en audit-trail. Controleerbaarheid kan worden getest gericht op de opzet van de betreffende maatregelen met behulp van een checklist en door het testen van de realisatie van de betreffende maatregelen in het systeem.

Zo testen we bij 23 december 2011 25/64

4.8

Flexibiliteit

Flexibiliteit De mate waarin de gebruiker zelf uitbreidingen of variaties op het informatiesysteem kan aanbrengen zonder dat de programmatuur wordt aangepast. Oftewel; de mate waarin het systeem door de beheerorganisatie kan worden aangepast, zonder afhankelijk te zijn van de automatiseringsafdeling voor onderhoud. Flexibiliteit kan worden getest door de betreffende maatregelen met behulp van een checklist te beoordelen.

4.9

Functionaliteit

Functionaliteit De zekerheid dat de verwerking van de gegevens juist en volledig geschiedt, conform de beschrijving in de functionele specificaties. Het kwaliteitsattribuut functionaliteit kan worden uitgesplitst in de attributen juistheid en volledigheid: Juistheid; de mate waarin het systeem de aangeboden invoer en mutaties correct volgens de specificatie verwerkt tot consistente gegevensverzamelingen; Volledigheid; de zekerheid dat alle invoer en mutaties verwerkt worden door het systeem. Bij het testen is het voldoen aan de gespecificeerde functionaliteit vaak het belangrijkste criterium om tot acceptatie van het informatiesysteem over te gaan. Met behulp van diverse testspecificatietechnieken is de functionele werking te testen.

4.10

Gebruikersvriendelijkheid

Gebruikersvriendelijkheid Het gemak waarmee de eindgebruiker kan leren omgaan met het informatiesysteem en het bedieningsgemak van het informatiesysteem voor ingeleerde gebruikers. Vaak wordt deze algemene definitie uitgesplitst in: het gemak waarmee de eindgebruiker kan leren omgaan met het informatiesysteem en het bedieningsgemak van het informatiesysteem voor ingeleerde gebruikers. Voor gebruikersvriendelijkheid is een objectieve en werkbare meeteenheid moeilijk vast te stellen. Wel is het vaak mogelijk in algemene bewoordingen een (subjectieve) mening te geven omtrent de gebruikersvriendelijkheid van hetZo testen we bij 23 december 2011 26/64

systeem. Bij het vaststellen van de gebruikersvriendelijkheid dienen de eindgebruikers uiteraard een belangrijke rol te vervullen. Gerbruikersvriendelijkheid kan impliciet worden getest door het opbouwen van statistieken tijdens het uitvoeren van functionaliteitstests. De testers dienen dan na afloop van een bepaalde testperiode, waarin met name semantische en syntactische tests zijn uitgevoerd, een vragenlijst met betrekking tot gebruikersvriendelijkheid in te vullen.

4.11

Herbruikbaarheid

Herbruikbaarheid De mate waarin delen van het informatiesysteem, of van het ontwerp, opnieuw gebruikt kunnen worden voor de ontwikkeling van andere toepassingen. Wanneer het systeem in hoge mate gebaseerd is op herbruikbare modules, zal dit ook aan de onderhoudbaarheid ten goede komen. Herbruikbaarheid kan worden getest door het informatiesysteem en/of het ontwerp met behulp van een checklist te beoordelen.

4.12

(Geschiktheid) Infrastructuur

(Geschiktheid) Infrastructuur De geschiktheid van de apparatuur, het netwerk, de systeemsoftware en het DBMS voor de betreffende toepassing en de mate waarin deze infrastructuurelementen op elkaar aansluiten. Het testen van dit aspect kan op verschillende manieren. Van groot belang is hierbij de expertise van de tester op het gebied van de betreffende infrastructuurelementen.

4.13

Inpasbaarheid

Inpasbaarheid De mate waarin de handmatige procedures aansluiten op het geautomatiseerde informatiesysteem en de werkbaarheid van deze handmatige procedures voor de organisatie. Bij het testen van inpasbaarheid wordt vaak ook het aspect tijdigheid meegenomen. Tijdigheid wordt gedefinieerd als de mate waarin de informatie op tijd beschikbaar komt om de maatregelen te nemen waarvoor die informatie was bedoeld. Inpasbaarheid wordt getest met behulp van de procescyclustest.

Zo testen we bij 23 december 2011 27/64

4.14

Onderhoudbaarheid

Onderhoudbaarheid Het gemak waarmee het informatiesysteem kan worden aangepast aan nieuwe wensen van de gebruiker, de veranderende externe omgeving of om fouten te herstellen. Er zijn dus twee aspecten van belang: foutherstel en aanpasbaarheid, uitbreidbaarheid. Inzicht in de onderhoudbaarheid kan bijvoorbeeld worden verkregen door tijdens het testen de inspanning (in uren) die nodig is om een fout op te lossen te registreren. Men kan dan de gemiddelde inspanning (Mean Time To Repair = MTTR) berekenen en de spreiding (eventueel per deelsysteem) vaststellen. Onderhoudbaarheid kan tevens worden getest door de interne kwaliteit van het informatiesysteem met behulp van een checklist te beoordelen. Inzicht in de gestructureerdheid van de programmatuur (een aspect van onderhoudbaarheid) kan worden verkregen door het uitvoeren van een directe test met behulp van de algoritmetesttechniek.

4.15

Performance

Performance De snelheid waarmee het informatiesysteem interactieve en batch-transacties afhandelt. Indien gekozen wordt voor dit kwaliteitsattribuut, zal het vaak noodzakelijk zijn ten aanzien hiervan speciale tests te definiren waarbij in een 'als-het-wareproductie' omgeving de performance representatief kan worden gemeten. Performance kan worden getest met behulp van de real-life test en/of door het opbouwen van statistieken tijdens het uitvoeren van tests gericht op functionaliteit.

4.16

Portabiliteit

Portabiliteit De diversiteit van hardware- en systeemsoftware-omgevingen waarin het informatiesysteem kan draaien, en het gemak waarmee het systeem kan worden overgebracht van de ene omgeving naar een andere omgeving. De portabiliteit naar een bepaalde omgeving kan worden gekwantificeerd door de kosten van het aanpassen uit te drukken als een percentage van de kosten van herbouw in de nieuwe omgeving. De mate van portabiliteit kan worden vastgesteld door gebruik te maken van een checklist.

Zo testen we bij 23 december 2011 28/64

4.17

Testbaarheid

Testbaarheid Het gemak en de snelheid waarmee de functionaliteit en het prestatieniveau van het systeem (na iedere aanpassing) getest kunnen worden. Testbaarheid betreft in dit geval het totale informatiesysteem. De mate van testbaarheid van de documentatie wordt indirect gemeten met behulp van de checklist intake testbasis tijdens de fase voorbereiding. Voor het meten van de testbaarheid van het totale informatiesysteem is eveneens een checklist beschikbaar Een maat voor de testbaarheid is de verhouding tussen het aantal testpunten en het aantal functiepunten.

4.18

Zuinigheid

Zuinigheid De verhouding tussen het prestatieniveau van het systeem (uit te drukken in het transactievolume en de totale snelheid) en de hoeveelheid resources (CPUcycles, I/0-tijd, geheugenbeslag, enzovoort) die daarvoor gebruikt worden. Zuinigheid kan worden getest met behulp van de real-life test en/of door het opbouwen van statistieken tijdens het uitvoeren van tests gericht op functionaliteit.

Zo testen we bij 23 december 2011 29/64

5TestsoortenTestsoort Een testsoort is een groep van testactiviteiten, die gezamenlijk wordt uitgevoerd en aangestuurd. Nu kan een 'groep van testactiviteiten' op basis van verschillende criteria samengesteld worden. Onduidelijkheid (of het niet expliciet maken) van deze criteria leidt tot verwarrende indeling van "testen". In het dagelijks spraakgebruik wordt een term uit de ene classificatie gebruikt en er kenmerken vanuit een andere ordening aan toegekend. Anderzijds lijkt het niet zinvol om hier zuiver theoretisch (indien al mogelijk) mee om te gaan, het moet werkbaar blijven. Bewustwording van de verschillen is echter wel nodig. Een onderscheid naar 'inzicht', 'aspect' en 'moment' is wel zinvol te maken. Los van andere indelingen is ook het perspectief van waaruit de test uitgevoerd gaat worden van belang. Dit kan bij de beoordeling of een product aan een kwaliteitsattribuut voldoet (of in welke mate), duidelijke accentverschillen aanbrengen. De belangrijkste gezichtpunten zijn: Ontwikkelorganisatie Verwerkingsorganisatie Gebruikersorganisatie Functionele systeemarchitectuur Technische systeemarchitectuur Gegevensinfrastructuur Fysieke beveiligingsmaatregelen Ontwikkelomgeving Productieomgeving 5.1 Testvormen

Testvorm Een groep activiteiten met het oogmerk het informatiesysteem op een aantal samenhangende kwaliteitsattributen te controleren. Stress Het laten verwerken van grote hoeveelheden en aantallen. (Ook: performance test). Middelen gebruik Het meten van de benodigde hoeveelheid middelen (disk, datacommunicatie, geheugen,...). Herstel Het testen van de herstel- en herstartfaciliteiten.Zo testen we bij 23 december 2011 30/64

Productie Het testen van de productie procedures. Standaards Het testen van conformiteit aan de standaards. Beveiliging Het testen van de beveiliging. Functionaliteit Het testen van de functionaliteit inclusief de foutafhandeling. Regressie Het testen dat alle onderdelen nog correct functioneren na het doorvoeren van een wijziging. Alle onderdelen; dus niet alleen de wijziging; en niet alleen de software maar ook bij een nieuwe versie van het operating system, database et cetera. Handmatige ondersteuning Het testen van de relatie tussen het geautomatiseerde en het handmatige deel van het systeem. Interfaces Het testen van aansluitingen met andere systemen. Controles Het testen van controles, zoals audit-trails, gegevensvalidaties, enzovoort. Schaduwdraaien Het testen of twee systemen (verschillende applicaties, versies, hardware etc) in productie bij gelijke input ook gelijke output geven.

5.2

Testmomenten

De termen die in onze organisatie zijn ingeburgerd verwijzen naar fasen in het productieproces van de software. De momenten in het proces zijn vervat in het zogenaamde V-model. Uit deze indeling blijkt ook dat we pas 'testen' als het programma klaar is. Het 'doorlezen' van een ontwerp wordt niet als testen gezien. Toch kan het proces van toetsen en testen al bij de functionele specificaties beginnen. Enerzijds wordt getoets of de specificaties kwalitatief in orde zijn. Anderzijds kan een begin gemaakt worden met de voorbereiding en specificatie van de latere testen.

Zo testen we bij 23 december 2011 31/64

Wat het plaatje (nog) niet weergeeft is: De functionele specificaties, het technisch ontwerp en de realisatie kennen diverse toetsen voordat deze producten afgerond zijn De programmatest verifieert de vertaling van technisch ontwerp in de systeem realisatie, De systeemtest verifieert de functionele specifcaties en technisch ontwerp, De acceptatietest verifieert de functionele specificaties. FO-toets Een document inspection of document review van de functionele specificaties. TO-toets Een document inspection of document review van de technische specificaties. Programmatest Programmatest De door de ontwikkelaar in de ontwikkelomgeving uitgevoerde test, die moet aantonen dat een programma aan de in de technische specificaties gestelde eisen voldoet.

Zo testen we bij 23 december 2011 32/64

Systeemtest Systeemtest De systeemtest is een door de ontwikkelaar (lees ontwikkelteam) in een (goed beheersbare) testomgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem of delen daarvan aan de in de functionele- en technische specificaties gestelde eisen voldoen. Integratietest Integratietest Een door de ontwikkelaar in de laboratoriumomgeving uitgevoerde test, die moet aantonen dat een logische serie programma's aan de in de technische specificaties gestelde eisen voldoet. Acceptatietest Acceptatietest De door de senior user (toekomstige gebruikers en beheerders) in een zoveel mogelijk 'als-het-ware-productie' omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem aan de functionele en kwalitatieve eisen voldoet. De senior user vertegenwoordigt hierin de toekomstige gebruikers en beheerders. Een 'als-het-ware-productie' omgeving is een omgeving die zoveel mogelijk overeenkomt met de klant-situatie. Dus zonder toegang tot de ontwikkelomgeving of software die niet vereist is bij de klant. Pilot Pilot De door de toekomstige gebruikers en beheerders in de eigen organisatie in een productie of 'als-het-ware-productie' omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem aan de functionele, kwalitatieve en gebruikseisen voldoet. Bij de pilot wordt ook de installatie en eventuele conversie getest. Gebruik Ook tijdens het operationeel gebruik van het systeem kan getest worden of het systeem voldoet. Zo kan de bruikbaarheid van een systeem pas echt gemeten worden nadat de gebruiker vertrouwd is met het systeem. De informatie uit het gebruik kan benut worden voor volgende versies en andere systemen. Pr-test Pr-test Het zodanig testen van de opgeleverde producten dat bepaald wordt of het zinvol is een gestructureerde test met betrekking tot het testobject uit te voeren. Voordat op enig moment aangevangen wordt met testen is het zinvol even snel te controleren of het testobject daarvoor klaar is. Dit voorkomt verspilling van resources. Deze intake kan bij een systeemtest bijvoorbeeld bestaan uit een controle of alle functies wel te starten zijn.

Zo testen we bij 23 december 2011 33/64

6Test(specificatie)techniekenDe testtechnieken worden hier beschreven waarbij de gekozen diepgang voldoende is om de techniek te herkennen. Om de techniek te kunnen toepassen is het raadplegen van andere literatuur nodig. Technieken sluiten elkaar niet altijd uit. Elke techniek wordt aan de hand van vier kopjes beschreven. Beschrijving Geeft een korte beschrijving van de techniek Toepasbaarheid Geeft aan voor welke testvormen en kwaliteitscriteria ze het meest geschikt zijn. Voorwaarden Benoemt de condities waaraan vooraf voldaan moet zijn. Werkwijze Benoemt de stappen (zonder nadere invulling) van de werkwijze. Afleiden testgevallen Binnen de specificatietechnieken worden diverse principes gebruikt om testgevallen af te leiden. Verwerkingslogica; baseert de testgevallen op een gedetailleerde kennis van verwerking in de functie of programma. Equivalentieklassen; er worden klassen van invoerwaarden gezocht die tot eenzelfde soort verwerking leiden. Grenswaardeanalyse; de waarde die de grenzen van de equivalentieklassen markeren worden in testgevallen opgenomen. Operationeel gebruik; op basis van het (verwachte) gebruik van het systeem in de praktijk worden testgevallen beschreven. CRUD (zie bijlage A); op basis van de levenscyclus van gegevens worden testgevallen opgesteld.

6.1

Algoritmetest

Beschrijving Op basis van de programmastructuur - het hierin gebruikte algoritme - worden testpaden gekozen, waarvoor testgevallen beschreven worden. Toepasbaarheid Bij uitstek geschikt bij de programmatest en/of integratietest. Voorwaarden In het (technisch) ontwerp dient het algoritme of de programmastructuur gedetailleerd gespecificeerd te zijn (stroomschema, NassiSchneidermanndiagram, beslistabel).

Zo testen we bij 23 december 2011 34/64

Werkwijze 1. Inventariseren beslispunten. 2. Bepalen testpaden. 3. Specificeren testgevallen. 4. Vaststellen initile gegevensverzameling. 5. Opstellen testscript.

6.2

Beslissingstabellentest

Beschrijving Formele techniek waarbij volgens vaste regels condities en resultaten worden vastgelegd. Toepasbaarheid Richt zich op volledigheid en juistheid van de verwerking; functionaliteit. Opstellen ervan kan als toets van ontwerp gebruikt worden. Voorwaarden Het ontwerp moet zeer gedetailleerd zijn om de beslistabellen te kunnen vullen. Werkwijze 1. Definiren logische testkolommen. 2. Specificeren logische testgevallen. 3. Specificeren fysieke testgevallen. 4. Vaststellen initile gegevensverzameling. 5. Opstellen testscript.

6.3

Checklist

Beschrijving Een lijst van controlepunten waardoor de naleving van een standaard, of de waarde van een kwaliteitsattribuut gemeten wordt. Toepasbaarheid Zeer breed toepasbaar. Voorwaarden Er moet een basis zijn waaruit de checklist is af te leiden, bij voorkeur in de vorm van standaards, normen of voorschriften. Werkwijze 1. Bepalen kritische controlepunten. 2. Formuleren van controlerende vragen of acties per controlepunt. 3. Maken van de checklist ordenen vragen, opstellen uitvoeringsrichtlijen etc.

Zo testen we bij 23 december 2011 35/64

6.4

Collegiale toets

Beschrijving Een collega (met minimaal zelfde kennis, kunde en vaardigheden) controleert of het product voldoet aan zijn/haar interpretatie van de gestelde kwaliteitseisen. De controle richt zich op naleving van standaards, best practices, basis beginselen van bijv. programmeren, et cetera. Ook meer informele afspraken of consistentie met soortgelijke producten kan dus een toetssteen zijn. Toepasbaarheid Zeer breed toepasbaar. Voorwaarden De toetser is bekend met de inhoud en vorm van het te toetsen object. Werkwijze 1. Toetsen product. 2. Vastleggen getoetste aspecten en resultaat. Op een checklistje wordt aangegeven welke aandachtpunten gekozen zijn. Het resultaat geeft slechts aan of het product voldoet, aangepast wordt en of er een hertoetsing nodig is. 3. Terugkoppeling aan maker van het product.

6.5

Dataflowtest (DFT)

Beschrijving Het uitgangspunt van de dataflowtest is de verwerking van de gegevensstromen door de diverse functies heen. Hierdoor worden de relaties tussen de functies getest. Toepasbaarheid Is met name geschikt voor de acceptatietest. Richt zich op volledigheid en juistheid van de verwerking; functionaliteit. Voorwaarden Uitgewerkt datamodel en functiemodel. Werkwijze 1. Specificeren testgevallen 1.1. Bepalen testsituaties. 1.2. Bepalen testgevallen. 1.3. Bepalen testacties. 1.4. Bepalen controles. 2. Vaststellen initiele gegevensverzameling 3. Opstellen testscript

Zo testen we bij 23 december 2011 36/64

6.6

Document Inspection

Beschrijving Door document inspection wordt vastgesteld wat de kwaliteit van het document is zonder de 'inhoud' van het document hierin te betrekken. Er wordt een steekproef van representatieve pagina's onderzocht door enkele van de beoogde gebruikers van het document. Zij noteren elke afwijking ('defect') van de criteria (begrijpelijk, eenduidig, consistent, et cetera) waaraan een document (van dat type) moet voldoen. Een document met teveel defects wordt niet geaccepteerd. Het heeft teveel risico's in zich om als basis te dienen voor vervolgactiviteiten. Toepasbaarheid Elk document; richt zich op correctheid van het document. Is als zondanig een belangrijke toetstechniek. Voorafgaand aan de document inspection wordt met behulp van een checklist gecontroleerd of het document aan de minimale eisen (entry criteria) voldoet. Voorwaarden Het document is opgesteld met inachtnemening van de criteria. Werkwijze 1. Bepalen documenten inclusief controle op 'entry criteria'. 2. Voorbereiden inspectie. 3. Uitvoeren inspectie. 4. Verzamelen 'defects'. 5. Evalueren. 6. Verbeteren document. Zie verder de SPI-pagina's op intranet en "Software Inspection; Gilb, Graham".

6.7

Document Review

Beschrijving Een gestructureerd onderzoek naar de inhoudelijke kwaliteit van documenten waarbij deze door deskundigen wordt geverifieerd. Toepasbaarheid Elk document. Richt zich op volledigheid en juistheid van de inhoud van het document. Voorwaarden De deskundigen zijn bekend met de materie van het document, anderzijds zijn ze niet direct betrokken bij het onderhavige product.

Zo testen we bij 23 december 2011 37/64

Werkwijze 1. Voorbereiding. 2. Becommentariren van document. 3. Review Meeting. 4. Verbeteren document. Zie verder de SPI-pagina's op intranet en "...Prince 2,CCTA".

6.8

Elementaire vergelijkingentest (EVT)

Beschrijving Bij de elementaire vergelijkingentest 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 hiervoor testgevallen gedefinieerd. In vergelijking tot dataflowtest veel gedetailleerder en formeler van aard. Hierdoor ook veel arbeidsintensiever. Toepasbaarheid Richt zich op de functionaliteit; door detailniveau redelijk volledig. Zinvol voor bedrijfskritische of complexe functies (hoeveelheid arbeid). Voorwaarden In het ontwerp dient een gedetailleerde beschrijving van de verwerking aanwezig te zijn. Werkwijze 1. Analyse functiebeschrijving. 2. Bepalen testsituaties. 3. Bepalen logische testgevallen. 4. Fysiek maken logische testgevallen. 5. Bepalen testacties. 6. Bepalen controles. 7. Vaststellen initile gegevensverzameling. 8. Opstellen testscript.

6.9

Error Guessing

Beschrijving Error Guessing is in wezen ongestructureerd testen, het gissen naar fouten. De ervaring, kennis en kunde van de tester zijn van groot belang. Hij/zij moet niet alleen de zwakke plekken kennen of kunnen afleiden, maar ook weten hoe die te testen zijn en eventuele fouten herkennen.

Zo testen we bij 23 december 2011 38/64

Toepasbaarheid Als aanvulling op gestructureerde testen altijd zinvol. Kan voor elke testvorm en kwaliteitsattribuut gebruikt worden. De herhaalbaarheid van gevonden fouten is vaak moeilijk. Voorwaarden Geen Werkwijze 1. Identificeer (mogelijk) zwakke plek en ga aan de slag.

6.10

Gegevenscyclustest

Beschrijving De gegevenscyslustest is een testtechniek die wordt gebruikt om de levensloop van gegevens te testen. Gegevens ontstaan, worden geraadpleegd en gewijzigd en veelal ook verwijderd. Geverifieerd wordt of de gegevens door de functies correct verwerkt worden en of aan de referentile relatiecontroles (van het datamodel) voldaan wordt. Toepasbaarheid Is met name geschikt voor de acceptatietest. Doordat de gegevenscyclus doorheen het hele systeem gaat is het tevens een integrale test van het systeem. Het test de referentile constraints van het datamodel, niet de beperkingen die in de functies zijn opgenomen. Voorwaarden Een uitgewerkt datamodel. Werkwijze 1. Inventariseren CRUD-matrix en relatiecontroles. 2. Vervaardigen testgevallen per entiteit. 3. Vaststellen testacties en controles. 4. Vaststellen initile gegevensverzameling. 5. Opstellen testscript.

6.11

Heuristic Evaluation

Beschrijving Een kleine groep experts (2-5) beoordeelt onafhankelijk van elkaar de usability van een product op basis van de ten usability heuristics (van Jakob Nielsen). Toepasbaarheid Is al toepasbaar als de ontwerpen van de user-interface, taken en context (A.O.) klaar zijn.Zo testen we bij 23 december 2011 39/64

Voorwaarden Er zijn meerdere experts aanwezig (nu nog niet bij ). De user-interface, de taken en de context zijn uitgebreid beschreven. Werkwijze 1. Experts beoordelen in 2 tot 4 uur het product. 2. Bevindingen verzamelen en ordenen. 3. Bevindingen presenteren. 4. Aandragen van verbeteringen.

6.12

Intake Testbasis

Beschrijving Tijdens de 'intake testbasis' wordt de testbaarheid van de testbasis beoordeeld. Met testbaarheid wordt in dit kader bedoeld de volledigheid, eenduidigheid en consistentie van de documentatie waarop de test wordt gebaseerd. Toepasbaarheid Tijdens de testvoorbereiding, voordat men testgevallen gaat specificeren. Omdat het specificeren van testgevallen kan (moet) plaatsvinden voordat er een werkend systeem is, hoort deze techniek met name bij het toetsen. Voorwaarden Geen. Werkwijze 1. Bepalen relevante documentatie. 2. Opstellen checklist. 3. Documentatie beoordelen op testbaarheid. 4. Rapporteren.

6.13

Procescyclustest (PCT)

Beschrijving Heeft tot doel de inpasbaarheid van het geautomatiseerde deel van het informatiesysteem binnen de AO-procedures te controleren, waarbij met name gekeken wordt naar de raakvlakken tussen de geautomatiseerde processen en handmatige procedures. Toepasbaarheid Richt zich met name op de inpasbaarheid van het systeem, eventueel tevens op gebruikersvriendelijkheid en beveiliging. De testgevallen worden niet afgeleid uit de ontwerpspecificaties maar uit de procedure-flow. Deze moeten dus wel beschikbaar zijn.

Zo testen we bij 23 december 2011 40/64

Voorwaarden Beschikbaarheid van procedures. Werkwijze 1. Inventariseren beslispunten. 2. Bepalen padcombinaties en paden. 3. Specificeren testgevallen. 4. Vaststellen initile gegevensverzameling. 5. Opstellen testscript.

6.14

Programma interfacestest (PIT)

Beschrijving Test de interfaces tussen programma's en modules. Er wordt vanuit gegaan dat de programma's/modules al zelfstandig getest zijn eventueel met gesimuleerde gegevensstromen (stubs/drivers) via de interfaces. Zowel interfaces met directe als indirecte gegevensstromen worden getest. Bij indirecte gegevensstromen worden de gegevens in (tijdelijke) bestanden opgeslagen voordat het volgende programma ze verwerkt. Toepasbaarheid Met name gebruikt in de integratietest. Voorwaarden De onderdelen zijn al afzonderlijk getest. Werkwijze 1. Identificeren gegevensstromen. 2. Bepalen equivalentie klassen. 3. Bepalen testgevallen. 4. Bepalen testacties en controles. 5. Vaststellen initile gegevensverzameling. 6. Opstellen testscripts.

6.15

Real-life test

Beschrijving Het doel van de real-life test, soms uitgevoerd in de vorm van schaduwproductie, 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. Toepasbaarheid Uitvoering is vaak moeilijk vanwege beschikbaarheid van werkelijke aantallen eindgebruikers, transacties en dergelijke. Ook het beoordelen van de resultaten is moeilijk doordat vele testgevallen parallel worden uitgevoerd.Zo testen we bij 23 december 2011 41/64

Voorwaarden Beschikbaarheid van resources om de testomgeving in te richten, is een moeilijk in te vullen voorwaarde. Werkwijze 1. Profielschets systeemgebruik. 2. Specificeren en realiseren testgevallen.

6.16

Sumi

Beschrijving De werkende versie van de software wordt beoordeeld door een tiental representatieve gebruikers. Op basis van de vragenlijst wordt de score van een product bepaald. Deze score wordt vergeleken met gestandaardiseerde scores uit een referentie database. Door gebruik van statische metrieken wordt een betrouwbaar rapportcijfer voor het product gegeven. De referentiedatabase wordt door een internationale gebruikersgroep up-to-date gehouden. Toepasbaarheid Pas werkende software wordt getest, dus erg laat in het proces. Het vergelijken van producten en versies is mogelijk; wordt de usability beter of slechter. Voor wellicht zinvol om te controleren of beter scoort dan zijn voorgangers en . Voorwaarden Niet iedereen kan SUMI-toetsen uitvoeren, de terugkoppeling met het internationaal platform is gewenst. Inhuur van kennis is dus nodig. Werkwijze 1. Bepalen gebruikers en relevante delen van het systeem. 2. Invullen vragenlijst door gebruikers. 3. Verwerken en analyseren van resultaten. 4. Rapporteren.

6.17

Syntactische en Semantische test

Beschrijving De syntactische 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 worden de geldende standaards en de scherm beschrijving in het ontwerp gebruikt. De semantische test heeft tot doel de relaties tussen de gegevens bij het invoeren te verifiren. Deze relaties liggen tussen de gegevens binnen eenZo testen we bij 23 december 2011 42/64

scherm, tussen gegevens op verschillende schermen onderling en tussen de (invoer)gegevens en reeds in de database aanwezige gegevens. Toepasbaarheid Met name zinvol bij on-line systemen tijdens de programmatest of systeemtest. De test is vooral gericht op functionaliteit maar ook beveiliging en de gehele user-interface (o.a. navigatie, helpsysteem) kunnen worden getest. Voorwaarden De gebruikte lay-out navigatie standaards dienen beschikbaar te zijn evenals het datamodel in verband met de gegevenstype en lengte van de rubrieken. Werkwijze 1. Rubrieken en controles inventariseren. 2. Opnemen in testscript aan welke standaard-checklists de schermen en overzichten moeten voldoen. 3. Opnemen in testscript welke functie-specifieke controles er zijn. 4. Inventariseren relatiecontroles. 5. Uitwerken relatiecontroles. 6. Vaststellen testacties en controles. 7. Vaststellen initile gegevensverzameling. 8. Uitbreiden (opstellen) testscripts.

6.18

Use cases

Beschrijving Door een beschrijving in scenarios wordt getoetst of de gebruikerstaken met het systeem kunnen worden uitgevoerd. Toepasbaarheid Vanwege de benodigde inspanning (kosten hoog) zijn use cases alleen voor de belangrijkste functionaliteiten zinvol. Voorwaarden Use cases worden ook gebruikt in analyse en ontwerpfase van software. Gebruik van use cases als toets- en testtechniek is met name zinvol als deze in de verschillende fasen van het onwikkelproces hergebruikt worden. Voorwaarden De taakuitvoering door de toekomstige gebruiker moet gedetailleerd bekend zijn. Werkwijze 1 Identificeer users (actors) van het systeem. 2 Identificeer use case voor elke actor. 3 Identificeer scenarios voor elke use case. 4 Selecteer use cases voor testen. 5 Stel testscript op.Zo testen we bij 23 december 2011 43/64

7De combinatie kwaliteitsattributen, testvormen, testspecificatie technieken.De tabellen in de volgende paragrafen geven combinaties weer welke logisch zijn. Dit betekent geenzins dat andere combinaties niet zullen voorkomen. Zo is er een breed scala van checklists mogelijk. Een collegiale toets kan bjjna op elk moment en bij elke actie plaatsvinden. Overal waar documenten beschikbaar komen kan een document review of inspection uitgevoerd worden. Zo kan bijvoorbeeld een document review ook bij systeemtest, acceptatietest en pilot plaatsvinden. Dan met name voor de installatie, beheer en gebruikersdocumentatie. De tabel (7.5) legt het accent echter bij FO- en TOtoets. Daar moet het zeker en is de meeste winst te halen. In de combinaties zijn vaak twee lijnen te herkennen. Een voor het toetsen en een voor het testen.

7.1

Testsoorten per kwaliteitsattribuut Stress Standaards Testsoort ondersteuningHandmatige Schaduwdraaien. X X X X X X X X X X X X XZo testen we bij 23 december 2011 44/64

Middelen gebruik

Herstel

Interfaces X X

Functionaliteit

Beveiliging

Kwaliteitsattributen Beheerbaarheid Beveiliging Bruikbaarheid Connectiviteit Continuteit Controleerbaarheid Flexibiliteit Functionaliteit Gebruikersvriendelijkheid Herbruikbaarheid Infrastructuur Inpasbaarheid Onderhoudbaarheid Performance Portabiliteit Testbaarheid Zuinigheid X X X X X X X X X X X X X X

Regressie

X X X X X X X X X X

Controles

Productie

7.2

Testmoment per kwaliteitsattribuut Programmatest FO-toets TO-toets Pilot 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 X X X X X X X X Integratietest Systeemtest Testsmoment Acceptatietest Gebruik X X

Kwaliteitsattributen Beheerbaarheid Beveiliging Bruikbaarheid Connectiviteit Continuteit Controleerbaarheid Flexibiliteit Functionaliteit Gebruikersvriendelijkheid Herbruikbaarheid Infrastructuur Inpasbaarheid Onderhoudbaarheid Performance Portabiliteit Testbaarheid Zuinigheid

X X

X

Zo testen we bij 23 december 2011 45/64

7.3 k

Testtechniek per kwaliteitsattribuut Algoritmetest Checklist Heuristic Evaluation Real-life test Syntactisch/semantisch X X X X X Beslistabel Document review Collegiale toets Intake testbasis Procescylcus Dataflowtest Element. Vergel. test Gegevenscyclustest Document inspection Prog. Interfacetest Error guessing Teststechnie Use cases X Sumi X X X X X X X X X X X X X X X

Kwaliteitsattributen Beheerbaarheid Beveiliging Bruikbaarheid Connectiviteit Continuteit Controleerbaarheid Flexibiliteit Functionaliteit Gebruikersvriendelijkheid Herbruikbaarheid Infrastructuur Inpasbaarheid Onderhoudbaarheid Performance Portabiliteit Testbaarheid Zuinigheid

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 X X X X X X X X X X X

X

X X X X

Zo testen we bij 23 december 2011 46/64

7.4Testmoment per Testsoort FO-toets TO-toets Programmatest Integratietest Systeemtest Acceptatietest Testsmom ent Gebruik X X Pilot X X X X X X X X X X X X X X X X

Testsoort Stress Middelen gebruik Herstel Productie Standaards Beveiliging Functionaliteit Regressie Handmatige ondersteuning Interfaces Controles Schaduwdraaien

X X X X

X X X

Zo testen we bij 23 december 2011 47/64

7.5Testmoment per Testtechniek FO-toets TO-toets Programmatest Integratietest Systeemtest Acceptatietest Testsmom ent Gebruik X X X X X X Pilot X X X

Teststechniek Algoritmetest Beslistabel Checklist Collegiale toets Dataflowtest Document Inspection Document Review Element. vergel. test Error Guessing Gegevenscyclustest Heuristic Evaluation Intake testbasis Procescyclustest Progr. interfacetest Real-Life test Sumi Syntactisch /Semantisch Use cases

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

X X X X

X X

X

Zo testen we bij 23 december 2011 48/64

8Bijlage A BegrippenlijstAcceptatietest De door de toekomstige gebruikers en beheerders in een zoveel mogelijk 'alshet-ware-productie' omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem aan de functionele en kwalitatieve eisen voldoet. Audit-trail Vastlegging van een spoor met behulp waarvan uit de resultaten van een gegevensverwerking de basisgegevens kunnen worden gevonden en van daaruit de resultaten kunnen worden gecontroleerd. Bedrijfszekerheid De mate waarin het informatiesysteem vrij blijft van storingen. Beheerbaarheid Het gemak waarmee het informatiesysteem in operationele staat kan worden gebracht en gehouden. Beveiliging De zekerheid dat raadpleging of mutatie van de gegevens uitsluitend mogelijk is door die personen die daartoe bevoegd zijn. Bruikbaarheid De mate waarin het informatiesysteem is toegesneden op de organisatie en het profiel van de eindgebruikers voor wie het bedoeld is en bij draagt aan het bereiken van de bedrijfsdoelstellingen. CASE Computer Aided Software Engineering. CAST Computer Aided Software Testing. Connectiviteit Het gemak waarmee een koppeling met een ander informatiesysteem of binnen het informatiesysteem tot stand kan worden gebracht. Continuteit De zekerheid dat de gegevensverwerking ongestoorde voortgang kan vinden, dat wil zeggen ook na ernstige storingen binnen redelijke termijn kan worden hervat. Controleerbaarheid Het gemak waarmee de juistheid en volledigheid van de informatie (in het verloop van de tijd) gecontroleerd kan worden.Zo testen we bij 23 december 2011 49/64

CRUD-matrix Een matrix waarbij op de assen horizontaal de entiteiten 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. Degradatiemogelijkheid Het gemak waarmee de kern van de informatievoorziening kan worden voortgezet nadat een deel is uitgevallen. Driver Een simulatieprogramma dat een programma vervangt dat de sturing c.q. aanroep van het testobject verzorgt. Dummy Een dummy is een FPA-functie waarvan de functionaliteit niet behoeft te worden gespecificeerd en/of gerealiseerd, maar beschikbaar is omdat dit reeds is gebeurd buiten het project. Dynamische productdimensie Het geheel van gebruikseigenschappen van een informatiesysteem, ofwel de kwaliteit van de informatievoorziening in werking c.q. gebruik. Flexibiliteit De mate waarin de gebruiker zelf uitbreidingen of variaties op het informatiesysteem kan aanbrengen zonder dat de programmatuur wordt aangepast. FPA-functie Onderverdeling van een gebruikersfunctie in FPA-functies: logische gegevensverzamelingen, koppelingen, invoer-, uitvoer- en opvragingsfuncties. Deze FPA-functies zijn de elementaire bouwstenen op basis waarvan de omvang van de functionaliteit van een systeem wordt bepaald. Functiepuntanalyse Functiepuntanalyse (FPA) is een methode met de mogelijkheid om een technologie onafhankelijke meting te doen van de omvang van de door een geautomatiseerd systeem geboden functionaliteit en deze meting te gebruiken als basis voor productiviteitsmeting, het schatten van de benodigde middelen en projectbeheersing. Functiepunt Meeteenheid voor de functionaliteit c.q. omvang van de applicatiesoftware.

Zo testen we bij 23 december 2011 50/64

Functionaliteit De zekerheid dat de verwerking van de gegevens juist en volledig geschiedt, conform de beschrijving in de functionele specificaties. Fysiek testgeval Fysieke beschrijving van de testgegevens op het niveau waarop ze kunnen worden uitgevoerd. De beschrijving omvat tevens de uit te voeren testacties en de wijze waarop het verwachte en werkelijke resultaat kunnen worden vergeleken. Gebruikersfunctie Een door de gebruiker onderkende eigenschap, waaraan het op te leveren product dient te voldoen. Gebruikersfuncties laten zich in het algemeen spraakgebruik het best omschrijven als objecten en processen. Gebruikersvriendelijkheid Het gemak waarmee de eindgebruiker kan leren omgaan met het informatiesysteem en het bedieningsgemak van het informatiesysteem voor ingeleerde gebruikers. Geschiktheid Infrastructuur De geschiktheid van de apparatuur, het netwerk, de systeemsoftware en het DBMS voor de betreffende toepassing en de mate waarin deze infrastructuurelementen op elkaar aansluiten. Herbruikbaarheid De mate waarin delen van het informatiesysteem, of van het ontwerp, opnieuw gebruikt kunnen worden voor de ontwikkeling van andere toepassingen. Herstelbaarheid Het gemak en de snelheid waarmee de informatievoorziening na een storing hersteld kan worden. Initile gegevensverzameling De gegevensverzameling (bestanden of database) die dient te worden geladen bij de aanvang een testuitvoering. In de initile gegevensverzameling zijn de testgevallen en de overige benodigde gegevens (fysiek) vastgelegd. In principe wordt de initile gegevensverzameling eenmalig ingevoerd en bij iedere test opnieuw geladen. Inpasbaarheid De mate waarin de handmatige procedures aansluiten op het geautomatiseerde informatiesysteem en de werkbaarheid van deze handmatige procedures voor de organisatie. Intake testbasis Het beoordelen van de betreffende specificaties op de testbaarheid.

Zo testen we bij 23 december 2011 51/64

Integratietest Een door de ontwikkelaar in de laboratoriumomgeving uitgevoerde test, die moet aantonen dat een logische serie programma's aan de in de technische specificaties gestelde eisen voldoet. Juistheid De mate waarin het systeem de aangeboden invoer en mutaties correct volgens de specificatie verwerkt tot consistente gegevensverzamelingen. Kloon Een kloon is een FPA-functie die reeds is gespecificeerd en/of gerealiseerd binnen een andere of dezelfde gebruikersfunctie binnen het project. Kwaliteit (ISO) Het geheel van eigenschappen en kenmerken van een product of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoeften. Kwaliteit Mate waarin een product voldoet aan de gestelde functionele eisen en prestatieeisen. Kwaliteitsattribuut Eigenschap van een informatiesysteem. Kwaliteitsborging Het geheel van alle geplande en systematische acties nodig om in voldoende mate het vertrouwen te geven dat een product of dienst voldoet aan de gestelde kwaliteitseisen. Onderhoudbaarheid Het gemak waarmee het informatiesysteem kan worden aangepast aan nieuwe wensen van de gebruiker, de veranderende externe omgeving of om fouten te herstellen. On-line Wijze van functioneren van een informatiesysteem waarbij het informatiesysteem opdrachten direct uitvoert en het antwoord (de uitvoer) direct op het scherm of anderszins wordt getoond. Performance De snelheid waarmee het informatiesysteem interactieve en batch-transacties afhandelt. Portabiliteit De diversiteit van het hardware- en software-platform waarin het informatiesysteem kan draaien, en het gemak waarmee het systeem kan worden overgebracht van de ene omgeving naar een andere.

Zo testen we bij 23 december 2011 52/64

Pr-test Het zodanig testen van de opgeleverde producten dat bepaald wordt of het zinvol is een gestructureerde test met betrekking tot het testobject uit te voeren. Programmatest De door de ontwikkelaar in de laboratoriumomgeving uitgevoerde test, die moet aantonen dat een programma aan de in de technische specificaties gestelde eisen voldoet. Regressietest Bij een regressietest wordt een test opnieuw uitgevoerd, bijvoorbeeld om de gevolgen van een doorgevoerde wijziging te controleren. Regressie is de zekerheid dat de kwaliteit van het systeem niet terugloopt. Een beschrijving van de mate waarin het systeem voldoet aan de gestelde kwaliteitseisen en de risico's die verbonden zijn aan het in productie nemen van een bepaalde versie, inclusief eventueel beschikbare alternatieven. Robuustheid De mate waarin de informatievoorziening ook na een storing gewoon door kan gaan. Statische productdimensie Het geheel van beheereigenschappen van een informatiesysteem, ofwel de kwaliteit die wordt ervaren door het systeembeheer en onderhoudspersoneel. Stub Een simulatieprogramma dat een programma vervangt, inclusief de bijbehorende in- en uitvoerstromen, en wordt aangeroepen door het testobject. Systeemtest De systeemtest is 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 specificaties gestelde eisen voldoen. Testactie Een handeling in een van tevoren gedefinieerde uitgangssituatie die goed of fout kan verlopen. Testbaarheid Het gemak en de snelheid waarmee de functionaliteit en het prestatieniveau van het systeem (na iedere aanpassing) getest kunnen worden.

Zo testen we bij 23 december 2011 53/64

Testbasis Alle documenten, waaruit de eisen zijn af te leiden, die aan een informatiesysteem worden gesteld. De documentatie waarop de test is gebaseerd. Indien een document nog slechts via de formele wijzigingsprocedure kan worden gewijzigd, spreekt men van een gefixeerde testbasis. Testbasisbevindingen Meldingen van incorrecte specificaties die met name geconstateerd worden tijdens de fasen Voorbereiding en Specificatie. Testdraaiboek Een planning van de uit te voeren testscripts; de testscripts zijn in het testdraaiboek in onderlinge samenhang en uit te voeren volgorde aangegeven. Testeenheid Een verzameling processen, transacties en/of functies die gezamenlijk worden getest. Testen Testen is het proces van plannen, voorbereiden en meten dat ten doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen de actuele en de vereiste status aan te tonen. Testfilosofie De gedachten die ten grondslag liggen aan de gestructureerde testaanpak en de daarbij behorende testfasering inclusief de verschillende activiteiten daarin. Testgeval Een logische of fysieke omschrijving van een uit te voeren test, gericht op een specifiek testdoel en gerelateerd aan een bepaalde testeenheid. Testinfrastructuur De 'omgeving' waarin de test wordt uitgevoerd, bestaande uit apparatuur, systeemsoftware, testtools, procedures, kantoorruimte, enzovoort. Testobject Het te testen (deel van het) informatiesysteem. Testorganisatie Een testorganisatie is het scheppen van doelmatige verhoudingen tussen testfuncties, testfaciliteiten en testactiviteiten teneinde tijdig een goed kwaliteitsadvies uit te brengen.

Zo testen we bij 23 december 2011 54/64

Testplan In een testplan worden de globale opzet en de strategische keuzes met betrekking tot de uit te voeren test vastgelegd. Het testplan vormt het referentiekader gedurende de uitvoering van de test en dient tevens als instrument om met de opdrachtgever van de test te communiceren. Het testplan is een beschrijving van het testproject, inclusief een beschrijving van de activiteiten en de planning; dus niet een beschrijving van de tests zelf. Testscript Opeenvolging van samenhangende acties en controles, gerelateerd aan fysieke testgevallen, waarvan de volgorde van uitvoering is aangegeven. Een beschrijving hoe er getest gaat worden. Testset Een verzameling testgevallen specifiek gericht op n of meer kwaliteitsattributen en n of meer testeenheden. Testsoort Een testsoort is een groep van testactiviteiten, die gezamenlijk wordt uitgevoerd en aangestuurd. Testspecificatie Een beschrijving van de wijze waarop de logische testgevallen zijn geselecteerd, alsmede een beschrijving van de logische testgevallen. Een beschrijving wat er getest gaat worden. Testspecificatietechniek Een gestandaardiseerde manier om vanuit uitgangsinformatie testgevallen af te leiden. Teststrategie De teststrategie is de verdeling van de testinspanning en dekkingsgraad over de te testen delen of aspecten van het testobject, met als oogmerk de belangrijkste fouten zo vroeg en goedkoop mogelijk te vinden. Deze verdeling is afhankelijk gemaakt van risicos op het gebied van business, systeemontwikkeling en testen. Testteam Een samenwerkingsverband dat, onder leiding van een testmanager, de testactiviteiten voor haar rekening neemt. Testtechniek Een testtechniek is een samenstel van acties om op universele wijze een testproduct te produceren. Testvorm Een groep activiteiten met het oogmerk het informatiesysteem op een aantal samenhangende kwaliteitsattributen te controleren.

Zo testen we bij 23 december 2011 55/64

Testware Alle testdocumentatie, zoals testspecificaties, testscripts en een beschrijving van de testinfrastructuur, die tijdens het testproces wordt geproduceerd. Als eis geldt dat deze testdocumentatie voor onderhoudsdoeleinden gebruikt moet kunnen worden en daarom overdraagbaar en onderhoudbaar moet zijn. Tijdigheid De mate waarin de informatie op tijd beschikbaar komt om de maatregelen te nemen waarvoor die informatie is bedoeld. Time-boxing Planningstechniek waarbij de tijd een leidende rol speelt. De hoeveelheid tijd die een activiteit is toegemeten wordt niet overschreden. Hierdoor is het moment waarop de activiteit beindigd wordt bekend, het resultaat niet. Uitwijkmogelijkheid Het gemak waarmee (een deel van) de informatievoorziening op een andere locatie kan worden voortgezet. Volledigheid De zekerheid dat alle invoer en mutaties verwerkt worden door het systeem. Zuinigheid De verhouding tussen het prestatieniveau van het systeem (uit te drukken in transactievolume en de totale snelheid) en de gebruikte hoeveelheid resources.

Zo testen we bij 23 december 2011 56/64

9Bijlage B Tmap kwaliteitsattributen in relatie tot ISO 9126In deze bijlage wordt de relatie van de TMap-kwaliteitsattributen met het kwaliteitsmodel ISO 9126 beschreven.

9.1Definities ISO 9126 kwaliteitsattributen Functionality Aanwezigheid van bepaalde functies die (uitgesproken en onuitgesproken) behoeften vervullen en de eigenschappen van die functies. Suitability Aanwezigheid en toepasselijkheid van functies voor (nader vast te stellen) taken. Accuracy Voortbrenging van juiste of overeengekomen resultaten en gevolgen. Interoperability Het vermogen om met bepaalde (nader vast te stellen) systemen een wisselwerking aan te gaan. Security Het vermogen om (al dan niet opzettelijke) onbevoegde toegang tot programmatuur en data te voorkomen. Reliability Het vermogen om gedurende een vastgestelde periode onder vastgestelde omstandigheden het prestatieniveau te handhaven. Beperkingen aan de betrouwbaarheid worden opgelegd door fouten in de requirements, het ontwerp en de implementatie, en worden niet bepaald door veroudering of ouderdom. Maturity Vrijwaring van storingen door fouten in de software. Fault tolerance Het vermogen om een bepaald niveau van functioneren te handhaven in geval van software fouten of schending van de gespecificeerde interface. Recoverability Het vermogen om in geval van een storing het niveau van functioneren en de direct aangetaste data te herstellen, en de tijd en inspanning die daarvoor nodig is.

Zo testen we bij 23 december 2011 57/64

Usability Inspanning benodigd voor het gebruik en de beoordeling daarvan door (mogelijke) gebruikers. De bruikbaarheid moet beoordeeld worden voor alle verschillende gebruikerstypen die bij de toepassing van het software- product betrokken zijn. Understandability De inspanning benodigd om het logische concept en zijn toepasbaarheid te herkennen. Learnability De inspanning benodigd om de toepassing en het gebruik van de software te leren. Operability De inspanning benodigd voor de operatie van de software en voor het beheersen daarvan. Attractiveness Het vermogen van het software product om aantrekkelijk te zijn voor de gebruiker. Efficiency De relatie tussen het prestatieniveau en het middelenbeslag, onder vastgestelde omstandigheden. Middelen zijn onder meer software-producten, hardwarefaciliteiten, materialen en diensten van personeel. Time behaviour De responsie- en uitvoeringstijden en verwerkingssnelheden bij het vervullen van de functies. Resource utilization De hoeveelheid gebruikte middelen en de tijdsduur van dat gebruik bij het vervullen van de functie(s). Maintainability De benodigde inspanning voor het aanbrengen van bepaalde modificaties. Onder modificaties kunnen correcties, verbeteringen of aanpassingen van de software aan veranderingen in de omgeving worden verstaan. Analysability De benodigde inspanning voor diagnose van tekortkomingen of foutoorzaken, of voor de identificatie van te modificeren onderdelen. Changeability De benodigde inspanning voor aanpassing, het verwijderen van fouten of voor omgevingsveranderingen. Stability Het risico van onverwachte gevolgen van modificaties. Testability De benodigde inspanning om de gemodificeerde software te valideren.

Zo testen we bij 23 december 2011 58/64

Portability Het vermogen om van de ene omgeving naar de andere overgebracht te kunnen worden. Omgeving houdt in: organisatorische, hardware of software omgeving. Adaptability De mogelijkheden voor aanpassing aan verschillende gespecificeerde omgevingen, zonder andere acties of middelen toe te passen dan die welke daartoe door het product geboden worden. Installability De benodigde inspanning voor het installeren van de software in een gespecificeerde omgeving. Co-existence Het vermogen van het software product om in samenhang met andere onafhankelijke software in een gemeenschappelijke omgeving gemeenschappelijke middelen te gebruiken. Replaceability De mogelijkheden en benodigde inspanning om het product te gebruiken in de plaats van gespecificeerde andere software in de omgeving daarvan.

Zo testen we bij 23 december 2011 59/64

9.2Vertaaltabel ISO 9126 - Nederlands Functionality Suitability Accuracy Interoperability Security Reliability Maturity Fault tolerance Recoverability Usability Understandability Learnability Operability Attractiveness Efficiency Time behaviour Resource utilisation Maintainability Analysabilty Changeability Stability Testability Portability Adaptability Installability Co-existence Replaceability Functionaliteit Geschiktheid Juistheid en volledigheid Koppelbaarheid Beveiligbaarheid Betrouwbaarheid Bedrijfszekerheid Foutbestendigheid Herstelbaarheid Bruikbaarheid Duidelijkheid Leerbaarheid Bedieningsgemak Aantrekkelijkheid Efficintie Transactiesnelheid Middelenbeslag Onderhoudbaarheid Analyseerbaarheid Wijzigbaarheid Stabiliteit Testbaarheid Portabiliteit Aanpasbaarheid Installeerbaarheid Samenwerkbaarheid Vervangbaarheid

Zo testen we bij 23 december 2011 60/64

9.3Vertaaltabel ISO 9126 - TMap Functionality Suitability Inpasbaarheid Bruikbaarheid Controleerbaarheid (specifieke functies) Flexibiliteit (specifieke functies) Functionaliteit (juistheid en volledigheid) Connectiviteit Beveiliging Continuteit Bedrijfszekerheid Robuustheid Degradatiemogelijkheid Herstelbaarheid Uitwijkmogelijkheid Gebruikersvriendelijkheid Bruikbaarheid Gebruikersvriendelijkheid Bruikbaarheid Bruikbaarheid (eindgebruiker) Beheerbaarheid (systeembeheerder) Gebruikersvriendelijkheid Gebruikersvriendelijkheid Performance Zuinigheid Onderhoudbaarheid Onderhoudbaarheid Testbaarheid Portabiliteit Portabiliteit -

Accuracy Interoperability Security Reliability Maturity Fault tolerance Recoverability Usability Understandability Learnability Operability Attractiveness Efficiency Time behaviour Resource utilisation Maintainability Analysabilty Changeability Stability Testability Portability Adaptability Installability Co-existence Replaceability

De TMap-kwaliteitsattributen Geschiktheid infrastructuur en Herbruikbaarheid hebben geen equivalent binnen ISO 9126.Zo testen we bij 23 december 2011 61/64

9.4Vertaaltabel TMap - ISO 9126 Beheerbaarheid Beveiliging Bruikbaarheid Operability Security Learnability Suitability Understandability Operability Interoperability Reliability Maturity Fault tolerance Recoverability Fault tolerance Recoverability Suitability Suitability Accuracy Attractiveness Learnability Operability Understandability Suitability Analysability Changeability Time behaviour Adaptability Installability Testability Resource utilisation

Connectiviteit Continuteit - bedrijfszekerheid - robuustheid - herstelbaarheid - degradatiemogelijkheid - uitwijkmogelijkheid Controleerbaarheid Flexibiliteit Functionaliteit Gebruikersvriendelijkheid

Herbruikbaarheid Geschiktheid infrastructuur Inpasba