Acceptatietesten in de praktijk

Optimaliseren van de testorganisatie Geen bedrijf is in staat om goed te kunnen functioneren zonder ICT. Veel bedrijven ontwikkelen hun applicaties en programma’s zelf, andere bedrijven besteden deze werkzaamheden (deels) uit. In beide gevallen is het goed functioneren van programmatuur voor het bedrijfsproces van cruciaal belang.

Acceptatietesten in de praktijk helpt bij het opzetten en inrichten van een acceptatietestomgeving. Daarnaast biedt het boek handvatten voor het testen, controleren, meten, evalueren en optimaliseren. Dit boek gaat onder andere uit van de testmethodiek TMAP®/Next (Test Management APproach) en ook het Agile-model is in dit boek opgenomen, zodat de lezer zelf een keuze van implementatie kan bepalen. Dit boek draagt bij aan kwaliteitsverbetering rondom acceptatietesten binnen organisaties en helpt zo kosten te besparen en de doorlooptijd (time to market) te versnellen. ‘In de praktijk’ is een reeks van titels met onderwerpen uit het hart van de praktijk, met de nadruk op de toepassing van de theorie in de IT-praktijk.

978 94 6245 082 0

Acceptatietesten in de praktijk Optimaliseren van de testorganisatie

Arie van Stam en Patrick van ’t Hek

Goed functioneren is synoniem voor goed testen. Slechte programmatuur gaat ten koste van de kwaliteit en het verstoort en belemmert de gewenste bedrijfsvoering. Het soepel implementeren van (nieuwe) software en softwaresystemen is een belangrijke fase in het ontwikkelproces. Veel bedrijven testen ongestructureerd waarbij ervaring en gevoel van de medewerkers richtinggevend is. Veel fouten worden pas bij het in productie geven van systemen zichtbaar, de aanpassingen hiervan hebben vaak vele herinvoeringen tot gevolg.

Acceptatietesten in de praktijk

Optimaliseren van de testorganisatie



9 789462 450820

980

Acceptatietesten in de praktijk cover v2.indd Alle pagina's

06-08-14 12:27

Acceptatietesten in de praktijk Optimaliseren van de testorganisatie Auteurs Arie van Stam Patrick van ’t Hek

Acceptatietesten opmaak_5.indd 1

05-08-14 17:17

Meer informatie over deze en andere uitgaven kunt u verkrijgen bij: BIM Media B.V. Postbus 16262 2500 BG Den Haag tel.: (070) 304 67 77 www.bimmedia.nl © 2014 BIM Media B.V., Den Haag Academic Service is een imprint van BIM Media B.V. U kunt de checklisten in deze uitgave ook downloaden op www.academicservice.nl/downloads Vormgeving, redactie & omslagontwerp: AZ Grafisch Serviceburo, Den Haag Druk- en bindwerk: Drukkerij Wilco, Amersfoort ISBN 978 94 6245 082 0 NUR 980 Alle rechten voorbehouden. Alle intellectuele eigendomsrechten, zoals auteurs- en databankrechten, ten aanzien van deze uitgave worden uitdrukkelijk voorbehouden. Deze rechten berusten bij BIM Media B.V. en de auteur. Behoudens de in of krachtens de Auteurswet gestelde uitzonderingen, mag niets uit deze uitgave worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Voor zover het maken van reprografische verveelvoudigingen uit deze uitgave is toegestaan op grond van artikel 16 h Auteurswet, dient men de daarvoor wettelijk verschuldigde vergoedingen te voldoen aan de Stichting Reprorecht (Postbus 3051, 2130 KB Hoofddorp, www.reprorecht.nl). Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet) dient men zich te wenden tot de Stichting PRO (Stichting Publicatie- en Reproductierechten Organisatie, Postbus 3060, 2130 KB Hoofddorp, www.cedar.nl/pro). Voor het overnemen van een gedeelte van deze uitgave ten behoeve van commerciële doeleinden dient men zich te wenden tot de uitgever. Hoewel aan de totstandkoming van deze uitgave de uiterste zorg is besteed, kan voor de afwezigheid van eventuele (druk)fouten en onvolledigheden niet worden ingestaan en aanvaarden de auteur(s), redacteur(en) en uitgever deswege geen aansprakelijkheid voor de gevolgen van eventueel voorkomende fouten en onvolledigheden. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the publisher’s prior consent. While every effort has been made to ensure the reliability of the information presented in this publication, BIM Media B.V. neither guarantees the accuracy of the data contained herein nor accepts responsibility for errors or omissions or their consequences. Eerste uitgave


05-08-14 17:17

Inhoud

Voorwoord

9

1

Inleiding

11

2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13

Acceptatietesten De testvisie in een notendop Zo vroeg mogelijk fouten vinden Testen van de functionaliteit Het testen van de inpasbaarheid Inzet Acceptatietesters Voorkomen van doublures en blinde vlekken Delen van kennis Metrics Kwaliteitsattributen Relatie kwaliteitsattribuut/testtechniek Checklists Relatie testsoorten/testontwerptechnieken Toelichting hoe een stroomschema moet worden gemaakt

15 15 15 16 17 17 17 18 18 20 22 24 25 26

3 3.1 3.2 3.3

Positionering acceptatietest Inleiding Taken afdeling AT Teststrategie

27 27 28 28

4 4.1 4.2 4.3 4.4 4.5 4.6 4.7

Rollen en taken binnen het testproject Testleider Testbegeleider Tester Testondersteuner Testprofessional Opleidingen Tijdsverantwoording

31 31 31 32 32 32 33 34

5 5.1

Algemene uitgangspunten voor de acceptatietest Omgevingen

35 35 3


05-08-14 17:17

acceptatietesten in de praktijk

6 6.1

Overleg Testteamoverleg 6.1.1 Projectoverleg 6.1.2 Bevindingenoverleg

39 39 39 39

7 7.1 7.2 7.3 7.4

Bevindingenadministratie Bevindingenbeheer Bevindingenprocedure Overzicht Bevindingen Categorie bevinding

41 41 42 43 44

8 8.1

Testbasis Versiebeheer testbasis

45 46

9 9.1 9.2 9.3 9.4 9.5 9.6 9.7

Testware Doel Omschrijving testware Ontwikkelen testware Beheren Testware Centraal archiveren testware Testdata Wijzigingsprocedure Testware

47 47 47 48 49 49 50 50

10 10.1 10.2

Testgevallen Uitgangssituaties en creatiescripts Maken testgevallen

51 51 51

11 11.1

Kwaliteitsbewaking en methodische ondersteuning Quality Assurance

55 55

12 12.1

Testactiviteiten Fase planning en beheer 12.1.1 Opdrachtformulering 12.1.2 Oriëntatie en documentatie 12.1.3 Bepalen strategie 12.1.4 Inrichten organisatie 12.1.5 Regelen autorisaties 12.1.6 Definiëren infrastructuur 12.1.7 Rapportage 12.1.8 Definiëren testeenheden 12.1.9 Bepalen planning 12.1.10 Fixeren testplan

57 57 58 59 59 60 61 61 61 63 63 64

4


05-08-14 17:17

inhoud

12.2

12.3

12.4

12.5

13 13.1 13.2

13.3

13.4

Fase voorbereiding 12.2.1 Aanmaken werkmap 12.2.2 Detail intake testbasis 12.2.3 Inventariseren documentatie 12.2.4 Risico’s 12.2.5 Bepalen teststrategie c.q. testaanpak 12.2.6 Bepalen detailplanning Fase specificatie 12.3.1 Opstellen testspecificaties 12.3.2 Uitvoer brieven aanbieden aan de printstraat 12.3.3 Definiëren uitgangssituatie 12.3.4 Opstellen testdraaiboek 12.3.5 Review testset Fase uitvoering 12.4.1 Vullen uitgangsbestanden 12.4.2 Intake testobject 12.4.3 Uitvoeren testdraaiboek 12.4.4 Controleren en beoordelen testresultaten Fase afronding 12.5.1 Evaluatie testobject 12.5.2 Eindrapport 12.5.3 Conserveren testware 12.5.4 Decharge

64 64 65 66 66 67 67 67 68 68 69 70 70 71 71 72 72 73 73 74 75 75 76

Agile en Acceptatietesten Agile Methodes binnen Agile 13.2.1 Scrum 13.2.2 DSDM/Atern 13.2.3 Extreme Programming (XP) 13.2.4 Lean Software development 13.2.5 RUP Agile testen 13.3.1 Werkwijzen Agile testproces 13.3.2 De voorbereiding 13.3.3 Product risico analyse 13.3.4 Definition of Done 13.3.5 Agile mastertestplan De uitvoering 13.4.1 Continue integratie 13.4.2 Unittesten 13.4.3 Geautomatiseerd testen en regressietesten 13.4.4 Agile testtechnieken

77 77 78 78 78 79 79 80 80 81 81 81 82 82 83 83 83 83 83

5


05-08-14 17:17


13.8 13.9 13.10 13.11

Hoe organiseer ik een Agile testproces? 13.5.1 Start van het project Iteratie 13.6.1 Tijdens een iteratie 13.6.2 Einde van een iteratie 13.6.3 Na een iteratie De Agile tester 13.7.1 Inleiding 13.7.2 Vaardigheden Agile tester 13.7.3 Faciliteren van testwerkzaamheden 13.7.4 Inzicht 13.7.5 Inschatten, analyseren en evalueren. 13.7.6 Snel schakelen Testleider (optioneel) Testmanager (lijnmanagement) Agile vs traditionele methodes Acceptatietesten vs Agile

14 14.1 14.2 14.3 14.4 14.5 14.6 14.7

Handleiding mastertestplan Opdrachtformulering (I) Oriëntatie en documentatie (II) Bepalen strategie (III) Definiëren organisatie (IV) Definiëren infrastructuur (V) Bepalen planning (VI) Fixeren mastertestplan (VII)

91 94 99 100 104 106 109 110

15 15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 15.9 15.10

Handleiding testplan Opstellen testplan Opstellen algemeen Opstellen opdrachtformulering Uitgangsdocumentatie Bepalen teststrategie Definiëren organisatie Definiëren infrastructuur Op te leveren producten Opstellen planning Resultaten en afronding

129 129 130 131 134 135 137 138 141 141 141

13.5 13.6

13.7

84 84 84 84 84 85 85 85 86 87 87 87 87 87 88 88 88

6


05-08-14 17:17

inhoud

16 16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8 16.9 16.10 16.11 16.12 16.13 16.14 16.15 16.16

Bijlagen Testdossier Fase specificatie Fase uitvoering Fase afronding Directory structuur Decharge Voortgangformulier Kwaliteitsattribuut: degelijkheid Kwaliteitsattribuut: doelgerichtheid Kwaliteitsattribuut: doelmatigheid Kwaliteitsattribuut: ergonomie Kwaliteitsattribuut: veranderbaarheid Kwaliteitsattribuut: zekerheid Checklist Quality Assurance Checklist – Intake testobject Checklist – Intake functioneel ontwerp

143 143 147 148 149 150 151 152 153 160 165 167 179 188 194 196 199

Begrippenlijst

201

Literatuur

207

Register

209

7


05-08-14 17:17

8


05-08-14 17:17

Voorwoord

Testen is cruciaal Geen bedrijf is in staat om goed te kunnen functioneren zonder ICT. Veel bedrijven ontwikkelen hun applicaties en programma’s zelf, andere besteden deze werkzaamheden (deels) extern uit. In beide gevallen is het goed functioneren van programmatuur voor het bedrijfsproces van cruciaal belang. En goed functioneren is synoniem voor goed testen. Na oplevering van de programmatuur dient immers met (acceptatie)testen aangetoond te worden dat de programmatuur in de praktijk goed functioneert. Waarom dit boek? Over de theorie van het testen zijn inmiddels bibliotheken vol geschreven. Dit boek is een vertaalslag van de theorie naar de praktijk en hoe dit binnen een organisatie kan worden toegepast. Wie zijn de auteurs? Patrick van ’t Hek heeft zich sinds 1997 gespecialiseerd in het testvak, waarin hij de functies als testanalist, testadviseur en trainer heeft bekleed. Zijn kennis en ervaring op het testgebied worden met regelmaat bij verschillende organisaties gebruikt. Patrick heeft diverse cursussen, onder andere testtechnieken, ketentesten, agile en testing en gebruikersacceptatietesten ontwikkeld en gegeven. Arie van Stam heeft na zijn studie AMBI veel ervaring opgedaan in het veranderingsmanagement van organisaties. Hij heeft de functies applicatiebeheer, projectleider en vestigingsmanager bekleed. Met het veranderingsmanagement heeft hij onder andere gebruikgemaakt van en kennis opgedaan met TPI, ISTQB, TMap, Agile en Lean Six Sigma. Met dank aan De auteurs hebben bij het uitbrengen van dit boek kunnen rekenen op verschillende mensen. Voor het ontwikkelen is hun hulp onontbeerlijk geweest. Velen hebben naast hun normale werkzaamheden het manuscript gereviewd. Zonder hun inzet zou dit boek niet tot stand zijn gekomen. Speciaal dank zijn zij verschuldigd aan de volgende mensen: dhr. E. van Veenendaal, dhr. N. Radmanoviç, mw. M.E.G. van Lonkhuijzen, mw. E.J.M. van Gelderen, dhr. N. Smit, dhr. J.J. Wagemans, dhr. J. Martina, mw. L. Lucke en dhr. F. Schoot Uiterkamp. De auteurs mogen zich ook gelukkig prijzen met de collega’s waar zij in het verleden mee samen hebben gewerkt. Door onder andere hun kennis en invloed is uiteindelijk dit boek tot stand gekomen. Daarom ook dank aan die vele anderen die hier niet speciaal genoemd zijn. 9


05-08-14 17:17

1

Inleiding

Hoe is dit boek ontstaan? Bij het uitvoeren van werkzaamheden bij opdrachtgevers viel het op dat er een groot verschil bestaat in de lifecycle van een (test)proces. ‘Hoe kan het dat het ene bedrijf kwalitatief goede software kan implementeren binnen één maand en dat een ander bedrijf daarvoor een halfjaar nodig heeft.’ Na veel onderzoek, praktijkervaring, implementaties en reorganisaties is dit boek ontstaan. De basis is gericht op het testvak met tips voor verdere optimalisatie. Dit boek beschrijft een groot aantal randvoorwaarden en templates die een testorganisatie kan gebruiken. Aangezien elk project uniek is, moeten vooraf de randvoorwaarden en acceptatiecriteria worden bepaald. Dit boek geeft hiervoor handvatten en uitgangspunten. Kostenbesparing Slechte programmatuur gaat ten koste van de kwaliteit, verstoort en belemmert de gewenste bedrijfsvoering en kan daardoor leiden tot verlies van omzet en klanten en een verhoging van de eigen kosten. De kosten van testactiviteiten kunnen omlaag. Een voorwaarde is wel dat er een (permanente) testorganisatie in het leven wordt geroepen. Bij bedrijven die een testorganisatie hebben ingericht, blijkt een aanzienlijke besparing op de testkosten mogelijk te zijn. Testorganisatie Om de testkosten te verminderen bestaat de basis uit hergebruik van testdata, testinfrastructuur, testaanpak, testkennis, testware, enzovoort. Dit in tegenstelling tot gebruik per project in plaats van algemeen hergebruik. De gevolgen zijn een kortere doorlooptijd, een verlaging van de kosten en verhoging van de testkwaliteit. Dit wordt bereikt door het inrichten van de testorganisatie. De testorganisatie faciliteert en stelt een testinfrastructuur beschikbaar. Hiermee moet het mogelijk zijn om testtrajecten tegelijkertijd uit te voeren. De testorganisatie gaat over het logisch beheer van de testinfrastructuur en de testomgeving en systeembeheer gaat over het fysiek beheer. 11


05-08-14 17:17


Succesfactoren De succesfactoren van de testorganisatie: – Er moet commitment zijn van het management van de organisatie. – Om commitment te hebben en te houden moet regelmatig de baten van de testorganisatie aan het management worden getoond. – Het aanbod van de testorganisatie moet aansluiten bij de klanten van de organisatie. – Het inrichten van de testorganisatie moet stap voor stap uitgevoerd worden. – De testorganisatie moet betrokken zijn bij het maken van projectvoorstellen. – De testorganisatie moet betrokken zijn bij het maken van de planning van projecten. – Zorg ervoor dat de kennis van de testorganisatie in balans is. Voor wie is dit boek bedoeld? Dit boek moet een handvat bieden aan iedereen die zich bezighoudt met acceptatietesten. Het helpt de kwaliteit van de acceptatietesten te verbeteren, de doorlooptijd (time to market) te versnellen en daardoor kosten te besparen. De auteurs zijn zich bewust van het feit dat dit boek enkel is gericht op acceptatietesten. Voor een volledige optimalisatie zal de scope vergroot moeten worden naar andere bedrijfsonderdelen. Onafhankelijk hoe uitgebreid u het testproces binnen uw organisatie wilt inrichten dan wel wilt optimaliseren, kan in alle situaties gebruikgemaakt worden van de kennis uit dit boek. U kunt voor uw organisatie de onderdelen gebruiken die u denkt nodig te hebben; het is verstandig om wijzigingen stapsgewijs in te voeren. Uw organisatie in balans met de VOP-methode Er dient rekening mee te worden gehouden dat de kwaliteit van een testproces niet alleen afhankelijk is van het inrichten en gebruik van een testproces. De bedrijfsprocessen Vakmanschap, Organisatie en Proces spelen hierin ook een grote rol. Deze bedrijfsonderdelen dienen in balans te zijn. Bij een gezonde bedrijfsvoering (kwaliteit binnen een organisatie) dient er een goede VOP-balans te zijn. Indien er een goede balans aanwezig is, zal een optimalisatie het meeste rendement opleveren. Een opwaartse spiraal van kwaliteit zal ontstaan. Om de balans te toetsen, hebben wij de VOP-methode geïntroduceerd. Waar de ene organisatie in staat is om maximaal rendement uit haar inspanningen te behalen, blijft het voor het andere woekeren.

12


05-08-14 17:17

inleiding

De VOP-methode bestaat uit drie onderdelen: – Vakmanschap • kennis • ervaring • documentatie – Organisatie • methode • technieken • aansturing • cultuur – Proces • uitvoering • inrichting • kwaliteit

Vakmanschap – kennis – ervaring – documentatie

Organisatie – methoden – technieken – aansturing – cultuur

Proces – uitvoering – inrichting – kwaliteit

Wanneer elk onderdeel apart en onderling in balans is, gaan de kosten omlaag en het rendement omhoog. Opbouw Dit boek bestaat uit vier onderdelen: – Acceptatietesten. – Mastertestplan handleiding. Plan van aanpak met bedrijfsoverkoepelende invalshoek. – Testplan handleiding. Plan van aanpak van het acceptatietesten. – Bijlagen. Bijlagen en uitwerkingen met default templates. Tools Er zijn binnen dit boek geen testtools opgenomen om geautomatiseerd te kunnen testen. Om geautomatiseerd te kunnen testen dient eerst de basis van het testproces structureel te zijn opgezet. Algemene randvoorwaarden Om de acceptatietesten te kunnen uitvoeren en de kwaliteit te kunnen garanderen, zijn we afhankelijk van vele factoren die in dit boek zijn opgenomen, zoals: – afbakening werkzaamheden; – versiebeheer; – teststraat; – hardware; – functies; – rollen; – kennis. Om de acceptatietesten te kunnen uitvoeren en de kwaliteit te kunnen garanderen is er voor de ICT een mastertestplan toegevoegd die is opgezet voor onder andere de opdrachtgever, opdrachtnemers, projectmanagers, projectleiders, teamleiders en het bedrijfs- of planningsbureau. 13


05-08-14 17:17


Samengevat Een optimale kwaliteit kan alleen worden bereikt door een gebalanceerd samenspel tussen: – vakmanschap (kennis, ervaring en documentatie); – organisatie (methoden, technieken, tools, aansturing, bevoegdheden en cultuur); – proces (uitvoering, inrichting, kwaliteit, optimaliseren); Templates De lezer zal na het doornemen van dit boek, de besproken checklists en formulieren willen aanpassen aan eigen omgeving. De templates kunnen worden gedownload van de site www.overthefence.nl.

14


05-08-14 17:17

2 Acceptatietesten

2.1

De testvisie in een notendop

De methode voor acceptatietesten is gebaseerd op de volgende uitgangspunten: – Doorlooptijd: In het heden van meten is weten dienen doorlooptijden van testtrajecten te worden vastgelegd. Heel belangrijk zijn doorlooptijden van een project. Om onze concurrentiepositie te behouden/versterken, is een korte ‘time to market’ cruciaal. Daarom moet gestreefd worden naar verkorting van de doorlooptijd van een project. Aan de hand van de opgebouwde ervaringscijfers binnen de afdeling zal de doorlooptijd beter te voorspellen zijn. De afdeling AcceptatieTesten (AT) moet ernaar streven om de doorlooptijd zo kort en reëel mogelijk te houden – Kwaliteit van de systemen: De Afdeling AT streeft ernaar om inzichten en advies te geven over de risico’s ten aanzien van de kwaliteit van een systeem. De twee vorige punten worden aan de hand van de volgende lijst in detail uitgewerkt: – fouten in een zo vroeg mogelijk stadium vinden; – bewust nadenken over waarop de test zich richt; – de verantwoordelijke voor de functionaliteit; – de verantwoordelijke voor de kwaliteitsattributen; – inzet acceptatietesters eerder in het project; – testen op elkaar afstemmen (zo weinig mogelijk doublures en blinde vlekken); – resultaten meetbaar maken; – delen/beschikbaar maken van kennis; – uitwerking gestructureerd testen in faseringen; – opzet testware; – uitwerking relatie kwaliteitsattributen/testtechnieken; – sjablonen en checklists; – handleidingen mastertestplan en testplan.

2.2

Zo vroeg mogelijk fouten vinden

De algemeen geldende opvatting over testen is dat problemen in een zo vroeg mogelijk stadium dienen te worden ontdekt en eventueel opgelost. Testen is dan ook niet een fase die na 15


05-08-14 17:17


de ontwikkeling moet komen. Testen bevat een reeks activiteiten die uitgevoerd dienen te worden in een vroeg stadium van ontwikkeling. Door hiermee zo vroeg mogelijk te beginnen, zal uiteindelijk veel tijd en geld bespaard worden. De grafiek van Boehm laat zien dat het loont om fouten in een zo vroeg mogelijk stadium te signaleren. De kosten van herstel lopen namelijk exponentieel op wanneer het moment van detectie later ligt. Zowel effectiviteit als de efficiëntie van maatregelen wordt groter naarmate ze vroeger wordt ingegrepen. Herstelkosten van fouten Relatieve herstelkosten

100 90 80 70 60 50 40 30 20 10 0 Definitiestudie

Ontwerpfase

Bouwfase

Lage prioriteit

Systeemtest

Acceptatietest

Productie

Hoge prioriteit

Grafiek volgens Boehm

Daarnaast speelt ook het leereffect een rol. Wanneer bijvoorbeeld problemen snel gevonden worden, leveren deze bruikbare feedback voor het ontwikkelproces. Als de fouten pas gevonden worden op het moment dat de ontwikkelaar elders werkt, wordt er niets geleerd van de gemaakte fouten.

2.3

Testen van de functionaliteit

Systeemontwikkeling (SO) is verantwoordelijk voor de functionaliteit. De SO heeft de verantwoordelijkheid om te zorgen dat het ontwikkelde systeem zo functioneert als in het functioneel ontwerp (FO) is beschreven. De afdeling AT toetst aan de hand van het FO het systeem op zijn functionaliteit (juistheid) door middel van acceptatietesten. In dit boek wordt voor het acceptatietesten uitgegaan van twee soorten testomgevingen: – FIST (FIST Functionele Integratie Systeemtest); – GAT (GebruikersAcceptatieTest). Het is afhankelijk van de organisatie of hier afgeweken wordt.

16


05-08-14 17:17

acceptatietesten

Wanneer tijdens het testen afwijkingen gevonden worden die bij systeemontwikkeling zouden moeten zijn geconstateerd, zal de SO hierop aangesproken moeten worden. Zij moet dan ook maatregelen treffen, zodat deze afwijkingen niet meer zullen optreden.

2.4

Het testen van de inpasbaarheid

De afdeling Acceptatietesten (AT) is verantwoordelijk voor de kwaliteitsattributen. Naast de functionaliteit is de inpasbaarheid het belangrijkste kwaliteitsattribuut waarop de afdeling AT moet letten. Het testen van de inpasbaarheid gebeurt op basis van de werkinstructies. Het testen op de inpasbaarheid heeft als doel te beoordelen of er te werken valt met het geheel van geautomatiseerde en handmatige procedures, documentatie en formulieren. Bij een basisinvoering van de inpasbaarheid wordt vaak gestart met de testontwerptechnieken Procescyclustest of Datacombinatietest (DCT) of Beslissingtabeltest (BTT), enzovoort. Afhankelijk van de ervaring kunnen de technieken aangepast worden.

2.5

Inzet Acceptatietesters

Een belangrijk uitgangspunt voor het verhogen van de kwaliteit is om afwijkingen c.q. fouten zo vroeg mogelijk in een ontwikkeltraject te vinden. Om dit te bereiken moet het specificeren van de test zo vroeg mogelijk beginnen. Dit betekent dat de fase testspecificatie moet beginnen, wanneer het FO afgerond is. Een van de belangrijkste uitgangspunten van testen is het streven naar het vinden van fouten in een zo vroeg mogelijk stadium van het ontwikkeltraject. De beste manier om dit te bereiken, is zo vroeg mogelijk beginnen met het specificeren van de test. Dit betekent voor de acceptatietest dat de testspecificatie begint nadat het FO afgerond is. Bij het maken van testgevallen uit de testbasis komen namelijk vaak fouten aan het licht; deze kunnen in dit stadium nog relatief makkelijk worden hersteld. Belangrijk! Omdat de acceptatietest ten aanzien van het kwaliteitsattribuut inpasbaarheid wordt gebaseerd op de werkinstructies, is het van groot belang dat de werkinstructies tijdig (liefst tegelijk met het FO) worden opgeleverd. Het is de taak van de testleider (zie paragraaf 4.1) en de projectleider om hierop toe te zien.

2.6

Voorkomen van doublures en blinde vlekken

Vermeden moet worden dat zaken ‘dubbel’ getest worden. Als je in de gebruikersacceptatietest (GAT) geregeld fouten vindt, die bijvoorbeeld in de FIST ontdekt hadden moeten worden, dan is de verleiding groot om de GAT steeds meer diepgang te geven. Daardoor ontstaat uiteindelijk de situatie dat de acceptatietest alle voorgaande testen nog eens overdoet. Dit is niet de bedoeling en in strijd met het principe om fouten in een zo vroeg mogelijk stadium te ontdekken. 17


05-08-14 17:17


Als iedere test afzonderlijk bepaalt wat er getest gaat worden, dan is de kans heel groot dat bepaalde delen tussen wal en schip vallen. (De FIST-testleider denkt dat het wel in de GAT wordt afgedekt en de GAT-leider denkt dat het wel in de FIST afgedekt wordt). In de ideale situatie is daarom duidelijk afgestemd wie wat test. Dit gebeurt al in een vroeg stadium van het ontwikkeltraject door het opstellen van een mastertestplan. Worden er tijdens een bepaalde test fouten ontdekt die vallen onder de verantwoordelijkheid van een eerdere test, dan wordt dit gemeld aan de testleider van die eerdere test. Hij/zij dient uit te zoeken waarom de fout niet is ontdekt en moet daarna maatregelen nemen om te voorkomen dat een dergelijke fout in de toekomst niet meer voorkomt. Met de eerdere aangemaakte herbruikbare testset dient men te bepalen of het knelpunt verholpen is. De acceptatietest bestaat dan uit: – een aantal toetsen uitvoeren of de aanpassingen naar behoren uitgevoerd zijn (door review van de testware en eventuele steekproefsgewijs uitvoeren van een aantal van deze testen) – een test ten aanzien van een aantal kwaliteitsattributen waarvan afgesproken is dat ze in de acceptatietest worden opgepakt. Deze test dient minder uitgebreid te zijn dan bijvoorbeeld de FIST

2.7

Delen van kennis

Het delen van kennis heeft als doel: – Mogelijk maken van een continu verbeterproces: Het testproces is niet iets dat eenmalig wordt vastgesteld, maar dient voortdurend te worden geëvalueerd. Als tijdens de acceptatietesten blijkt dat bepaalde technieken, checklists en hulpmiddelen verbeterd kunnen worden, dan moet dit soort informatie worden gecommuniceerd met de beheerder van de testmethode. Als blijkt dat de voorgestelde verbetering ook nuttig kan zijn voor anderen, dan dient de documentatie te worden aangepast, zodat anderen ook kunnen profiteren van de verbetering. – Flexibelere inzet van medewerkers: Nieuwe medewerkers of medewerkers die tijdelijk van een andere afdeling komen helpen met testen, moeten snel ingewerkt kunnen worden in de testmethode. Door de aanwezige testkennis niet alleen in hoofden van mensen maar ook op een voor anderen toegankelijke manier beschikbaar te hebben, kan veel flexibeler worden omgegaan met de inzet van medewerkers.

2.8

Metrics

De afdeling AT streeft naar een situatie waarin continu verbetering van het gehele systeemontwikkelingsproces mogelijk is, waarin geleerd wordt van fouten. Voorwaarde hiervoor is dat je objectieve informatie hebt over het proces waar je mee bezig bent; immers, als je niet kunt 18


05-08-14 17:17

acceptatietesten

vaststellen in hoeverre iets beter of slechter is geworden, kun je objectief gezien niet van verbetering spreken. Omdat de doorlooptijd van projecten en de op te leveren kwaliteit de belangrijkste elementen zijn waarop de afdeling AT wil sturen (zie paragraaf 2.1), moet ieder acceptatietesttraject de volgende metrics kunnen opleveren (in de tabel wordt aangegeven of de metric betrekking heeft op het aspect doorlooptijd (DT) dan wel kwaliteit (Q)): Metric

Omschrijving

DT/Q

Toelichting

DTV

Doorlooptijd testvoorbereiding

DT

Datum waarop de testvoorbereiding is gereedgekomen minus de datum waarop de testvoorbereiding is gestart.

DTS

Doorlooptijd testspecificatie

DT

Idem testspecificatie.

DTU

Doorlooptijd testuitvoering

DT

Idem testuitvoering.

DTA

Doorlooptijd testafronding

DT

Idem testafronding.

DNO

Doorlooptijd testomgeving(en) na oplevering bouw

DT

Datum decharge minus opleverdatum bouw.

UTV

Uren besteed aan testvoorbereiding

DT

Totaal aantal uren, besteed aan de voorbereiding van een test van een testeenheid (zie paragraaf 12.1.8).

UTS

Uren besteed aan testspecificatie

DT

Idem, specificatie.

UTU

Uren besteed aan testuitvoering

DT

Idem, testuitvoering.

UTA

Uren besteed aan testafronding

DT

Idem, testafronding.

BEC

Aantal bevindingen per ernstcategorie

Q

Zie bevindingenadministratie.

BFS

Aantal bevindingen per soort bevinding

Q


BTS

Aantal bevindingen per testactiviteit

Q


GHT

Gemiddelde hersteltijd

Q/DT

De hersteltijd wordt als volgt gedefinieerd: – Datum gereed voor hertest minus – Datum bevinding aangemeld. – De gemiddelde hersteltijd wordt berekend door de hersteltijd van alle bevindingen van een testeenheid te delen door het aantal bevindingen voor diezelfde testeenheid.

BTP

Aantal bevindingen tijdens productie

Q

Aantal bevindingen die zijn geconstateerd tijdens de eerste vier weken na inproductiename van de testeenheid.

19


05-08-14 17:17


Alle metrics dienen te worden verzameld op het niveau van testeenheid. In de praktijk betekent dit per applicatie/proces. Totaliseren over meerdere testeenheden tot maximaal projectniveau moet mogelijk zijn. Elk bestaand ‘uren verantwoordingsyteem’ kan gebruikt worden voor het opleveren van de acceptatiedoorlooptijd van het testen. Mits uren overzichten per fasering maar ook per (deel) project op elk moment kunnen worden opgeleverd (zie paragraaf 4.7 en hoofdstuk 12). Een algemeen tool “Basismodule Doorlooptijd AcceptatieTesten” kan gedownload worden. Zie templates, bladzijde 14.

2.9

Kwaliteitsattributen

Voor het vaststellen van de kwalitatieve acceptatiecriteria (= kwaliteitsattributen) waaraan de te testen producten moeten voldoen, kan een keus worden gemaakt uit de onderstaande lijst. Deze keuze moet worden gemaakt in overleg met de opdrachtgever van de test. Kwaliteitsattribuut

Omschrijving

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.

Traceerbaarheid/ Reproduceerbaarheid

Buiten de checklist om moet de integriteit per stap te allen tijde kunnen worden vastgesteld.

Degelijkheid Bedrijfszekerheid

De mate waarin het systeem vrij blijft van vooraf beschreven storingen (bedrijfszekerheid), bestand is tegen bedoeld of onbedoeld onjuist gebruik (bestendigheid) en in staat is zichzelf na storingen te herstellen (veerkracht).

Beschikbaarheid

De mate waarin het systeem voor iedere gebruiker beschikbaar is op het tijdstip waarop dat gewenst is.

Degradatiemogelijkheid

Het gemak waarmee de essentiële functie(s) van het systeem na een storing hervat kan/kunnen worden.

Herstelbaarheid

Het gemak waarmee de werking van het systeem na een storing hersteld kan worden.

Robuustheid

De mate waarin de informatievoorziening ook na een storing gewoon door kan gaan.

Doelgerichtheid Koppelbaarheid (connectiviteit)

Het gemak waarmee koppelingen kunnen worden gelegd, zodat het systeem gegevens kan uitwisselen met andere systemen.

Flexibiliteit

Het gemak en de mate waarin de (eind)gebruiker zelf uitbreidingen of variaties op het systeem kan aanbrengen, zonder dat de programmatuur wordt aangepast.

20


05-08-14 17:17

acceptatietesten

Kwaliteitsattribuut

Omschrijving

Herbruikbaarheid

De mate waarin het systeem geheel of gedeeltelijk opnieuw kan worden toegepast in andere systemen.

Infrastructuur

De geschiktheid van de apparatuur, het netwerk, de systeemsoftware en de database voor de desbetreffende toepassing en de mate waarin deze infrastructuurelementen op elkaar aansluiten.

Inpasbaarheid

De mate waarin de handmatige procedures aansluiten op het geautomatiseerde informatiesysteem en de werkbaarheid van deze handmatige procedures voor de organisatie.

Doelmatigheid Verwerkingssnelheid (performance)

De snelheid waarmee bij bepaalde gebruiksbelasting interactieve (responsiesnelheid) en batch (snelheid batchverwerking) transacties worden afgehandeld. De snelheid waarmee de gebruiker interactieve transacties afhandelt (transactiesnelheid).

Middelenbeslag

De hoeveelheid infrastructurele middelen die nodig is om het systeem op de vooraf vastgestelde wijze te kunnen gebruiken.

Ergonomie Aantrekkelijkheid

Het vermogen van het softwareproduct om aantrekkelijk te zijn voor de gebruiker.

Bedieningsgemak

Het gemak waarmee het informatiesysteem kan worden bediend door ‘ingeleerde’ gebruikers.

Begrijpelijkheid

Het gemak waarmee de gebruiker het logisch concept van het softwareproduct kan doorgronden en toepassen.

Behulpzaamheid

De mate van het softwareproduct om de gebruiker informatie over het (juiste) gebruik aan te geven.

Gebruikersvriendelijkheid

De mate waarin de gebruiker met tevredenheid het softwareproduct kan gebruiken.

Installeerbaarheid

Het gemak waarmee het systeem in een gespecificeerde omgeving kan worden geïnstalleerd.

Inzichtelijkheid

De mate waarin inzichtelijk is wat de status (voortgang, proces, enzovoort) van het softwareproduct is.

Leerbaarheid

Het gemak waarmee de eindgebruiker kan leren omgaan met het informatiesysteem.

Overzichtelijkheid

De mate waarin het softwareproduct de gebruiker kenbaar maakt welke functies het uit kan voeren.

Veranderbaarheid Beheerbaarheid

De mate waarin de beheerder zelf uitbreidingen of variaties op het informatiesysteem kan aanbrengen zonder dat de programmatuur wordt aangepast.

Instelbaarheid

De mate waarin het softwareproduct door de gebruiker aangepast kan worden aan zijn/haar wensen om de gebruiksinspanning te verlagen en de gebruikerstevredenheid te verhogen.

21


05-08-14 17:17


Kwaliteitsattribuut

Omschrijving

Onderhoudbaarheid

Het gemak waarmee een gebrek van het systeem kan worden opgelost (corrigeerbaarheid) en de functionaliteit gewijzigd of de kwaliteit verbeterd kan worden (wijzigbaarheid).

Portabiliteit

Het gemak waarmee het systeem overgezet kan worden naar een andere hardware- en systeemsoftwareomgeving (platform) of naar een nieuwe versie.

Testbaarheid

Het gemak en de snelheid waarmee kan worden vastgesteld of de functionaliteit en kwaliteit kunnen worden getest.

Zekerheid Beveiligbaarheid

De mate van zekerheid dat toegang, in de vorm van raadpleging of mutatie van gegevens, tot het systeem of de daarmee bewerkte gegevens uitsluitend mogelijk is voor personen die daartoe bevoegd zijn.

Controleerbaarheid

Het gemak waarmee de juistheid van de gegevensverwerking op de vereiste punten kan worden gecontroleerd.

Juistheid (functionaliteit)

De mate van zekerheid dat de aangeboden invoer en de mutaties volgens de specificaties worden verwerkt tot consistente gegevensverzamelingen, zelfs als bewust wordt getracht om het systeem anders te laten functioneren.

Het is wellicht nodig om interviews met meerdere betrokkenen te houden om tot een goede selectie te komen. Voor de beeldvorming en strategiebepaling is dit in ieder geval nuttig. Vooraf dient het relatief belang (noodzaak) van een kwaliteitsattribuut bepaald te worden. Nadat het relatief belang is bepaald, kan de keuze worden gemaakt welke kwaliteitsattributen moeten worden uitgetest. Vanuit de ontwikkeldocumentatie dienen normen te worden opgezet waaraan de kwaliteitsattributen moeten voldoen. De testaanpak richt zich vervolgens op het toetsen aan deze normen. Voor het bepalen van de waardering ten aanzien van de kwaliteitsattributen zijn tevens checklists beschikbaar. Het is mogelijk dat bij wijzigingen c.q. toevoegingen op bestaande systemen voor acceptatiecriteria al afspraken zijn vastgelegd in (service)afspraken. Dit betekent dat voor deze acceptatiecriteria geen normen meer hoeven te worden bepaald, tenzij om redenen deze norm voor de wijzigingen/toevoegingen niet acceptabel is.

2.10

Relatie kwaliteitsattribuut/testtechniek

Er zijn diverse testtechnieken die tijdens de tests toegepast kunnen worden. Niet iedere testtechniek is voor iedere kwaliteitsattribuut even geschikt. Per kwaliteitsattribuut moet bepaald worden welke testtechniek wordt gehanteerd.

22


05-08-14 17:17

Optimaliseren van de testorganisatie Geen bedrijf is in staat om goed te kunnen functioneren zonder ICT. Veel bedrijven ontwikkelen hun applicaties en programma’s zelf, andere bedrijven besteden deze werkzaamheden (deels) uit. In beide gevallen is het goed functioneren van programmatuur voor het bedrijfsproces van cruciaal belang.

Acceptatietesten in de praktijk helpt bij het opzetten en inrichten van een acceptatietestomgeving. Daarnaast biedt het boek handvatten voor het testen, controleren, meten, evalueren en optimaliseren. Dit boek gaat onder andere uit van de testmethodiek TMAP®/Next (Test Management APproach) en ook het Agile-model is in dit boek opgenomen, zodat de lezer zelf een keuze van implementatie kan bepalen. Dit boek draagt bij aan kwaliteitsverbetering rondom acceptatietesten binnen organisaties en helpt zo kosten te besparen en de doorlooptijd (time to market) te versnellen. ‘In de praktijk’ is een reeks van titels met onderwerpen uit het hart van de praktijk, met de nadruk op de toepassing van de theorie in de IT-praktijk.

978 94 6245 082 0

Acceptatietesten in de praktijk Optimaliseren van de testorganisatie


Goed functioneren is synoniem voor goed testen. Slechte programmatuur gaat ten koste van de kwaliteit en het verstoort en belemmert de gewenste bedrijfsvoering. Het soepel implementeren van (nieuwe) software en softwaresystemen is een belangrijke fase in het ontwikkelproces. Veel bedrijven testen ongestructureerd waarbij ervaring en gevoel van de medewerkers richtinggevend is. Veel fouten worden pas bij het in productie geven van systemen zichtbaar, de aanpassingen hiervan hebben vaak vele herinvoeringen tot gevolg.


Optimaliseren van de testorganisatie



9 789462 450820

980

Acceptatietesten in de praktijk cover v2.indd Alle pagina's

06-08-14 12:27

Acceptatietesten in de praktijk

Recommend Documents