Docentenhandleiding. Leerboek resultaatgedreven softwaretesten

Docentenhandleiding

TestGoal

Leerboek resultaatgedreven softwaretesten Versie 1.2

Derk-Jan de Grood

978 90 395 2561 D

Collis B.V. De heijderweg 1 2314 XZ Leiden T 071-5183636 F 071-5813630 E [email protected] www.collis.nl www.testgoal-educatief.nl

Deze docentenhandleiding behoort bij: Titel: TestGoal – Leerboek resultaatgericht softwaretesten Auteur: Derk-Jan de Grood Uitgegeven door: Academic Service, Den Haag ISBN: 978 90 395 2561 6 © 2008 Sdu Uitgevers bv, Den Haag Academic Service is een imprint van Sdu Uitgevers bv 978 90 395 2561 D Hoewel deze docentenhandleiding met zeer veel zorg is samengesteld, aanvaarden schrijver(s) noch uitgever enige aansprakelijkheid voor schade ontstaan door eventuele fouten en/of onvolkomenheden in dit materiaal.

Inhoud Introductie ...................................................................................................................... 1 1 Testen, een vak in ontwikkeling ............................................................................. 7 2 Resultaatgedreven Testen ....................................................................................... 8 3 Testgoal en de tien testprincipes ........................................................................... 14 4 Testexpertise ......................................................................................................... 24 5 De Aanpak ............................................................................................................ 29 6 Aan De Slag .......................................................................................................... 37 7 Inventarisatie Beoogd Resultaat ........................................................................... 37 8 Testrisicoanalyse .................................................................................................. 42 9 Begroten en Plannen ............................................................................................. 52 10 Testplan ............................................................................................................. 61 11 Intake Testbasis ................................................................................................. 66 12 Logisch Testontwerp ......................................................................................... 74 13 Het Fysieke Testontwerp ................................................................................ 123 14 Testdata ........................................................................................................... 129 15 Testomgeving .................................................................................................. 134 16 Testautomatisering .......................................................................................... 137 17 Intake Systeem ................................................................................................ 141 18 Testuitvoering ................................................................................................. 144 19 Bevindingenregistratie en –Beheer ................................................................. 148 20 Testrapportage................................................................................................. 152 21 Borging ........................................................................................................... 156 22 Dankwoord ...................................................................................................... 158 23 Referenties ...................................................................................................... 159

Docentenhandleiding TestGoal – Leerboek resultaatgericht softwaretesten

Introductie Didactische verantwoording Bij het schrijven van dit leerboek voor het hoger onderwijs is het uitgangspunt gehanteerd dat de student zich een goed beeld moet kunnen vormen van het vak software testen. Het boek bevat daarom nuttige, in het werkveld beproefde, theorie. Maar kennis alleen is niet voldoende. Bij het leren gaan lezen, denken en doen hand in hand. Elk hoofdstuk bevat naast de nodige theorie, een zelftoets die gebruikt kan worden om te toetsen of de student de theorie goed gelezen heeft. Opdrachten zorgen ervoor dat de student de theorie kan toepassen. Daarnaast wordt hij aan de hand van de opdrachten uitgedaagd om met zijn mede studenten de discussie aan te gaan en zodoende niet alleen kennis, maar ook begrip op te bouwen. Dit leerboek is zodanig opgezet dat het op verschillende manieren gebruikt kan worden: Als ondersteuning bij de colleges Elke belangrijke activiteit in en product van het testproces is in een apart hoofdstuk behandeld. Dit maakt het voor de docent en student gemakkelijk om die passages te vinden die aansluiten bij de in het college behandelde stof. Elk hoofdstuk is voorzien van vragen en opgaven die beantwoord kunnen worden zonder de overige hoofdstukken te hoeven kennen. Binnen het hoofdstuk worden echter ook de relaties aangegeven met andere activiteiten in het testproces. Dit vergroot het inzicht en maakt verder studeren mogelijk, zowel in groepsverband als individueel. Als integrale lesmethode voor een minor gewijd aan software testen. Het boek doorloopt alle belangrijke activiteiten en hun bijbehorende producten in een logische volgorde. Hierdoor is het boek zeer geschikt als integrale methode voor een minor gewijd aan software testen. De student krijgt inzicht in de activiteiten die nodig zijn en hun onderlinge relatie, en krijgt een schat aan praktische tips en handvatten. De opdrachten stellen de student in staat ook daadwerkelijk te oefenen met de materie. Dit kan onder meer gedaan worden aan de hand van de integrale case die door het hele boek loopt. Inzichtvragen stimuleren discussie zorgen voor kennis en begrip. Als ondersteuning bij projectonderwijs Als studenten aan de hand van een project ervaring op doen met de testtheorie, wordt deze vaak vooraf gedoceerd en geoefend. De indeling van het boek maakt het voor de docent gemakkelijk de voorbereidende lesstof te vinden. De bijbehorende opgaven kunnen daarbij gebruikt worden voor het oefenen. Na bestudering van de theorie en de daarin opgenomen voorbeelden, kan de student de verkregen kennis toepassen op de projectopdracht. Eventueel kan in het boek opgenomen integrale case gebruikt dienen projectcase op zich.

1/159

Hoofdstuk - Introductie

Gerelateerde publicaties De ideeën van TestGoal zijn gepubliceerd in een drietal boeken. Allereerst natuurlijk het „Leerboek resultaatgedreven testen‟ waarbij deze docentenhandleiding behoort. Dit leerboek is geschreven met doel een goede ondersteuning te gegeven bij het onderwijs. Daarom zijn bevat het boek een aantal introducerende hoofdstukken, en is bij elk hoofdstuk de „leerdoelstelling‟, een zelftoets en verschillende opgaven opgenomen. Het standaard TestGoal-boek is gericht op de testprofessional. Dit boek gaat uit van meer voorkennis en mist daarom de introducerende onderdelen. De uitwerkingen van het stappenplan gaan verder dan in het leerboek het geval is, en is daarmee een goed naslagwerk voor de testprofessional. Deze publicatie bevat geen vragen en opdrachten. Van bovenstaande TestGoal boek is ook beschikbaar in het Engels. Omdat de ideeën achter alle drie de boeken gelijk is, zou dit in aanvulling op het leerboek gebruikt kunnen worden door Engelstalige studenten, die zijn aangeschoven bij de testcollege‟s.

TestGoal, Leerboek resultaatgedreven testen. (met docentenhandleiding)

TestGoal, Result-driven testing (Engels)

TestGoal, resultaatgedreven testen

ISBN 978-9-039-52561-6

ISBN: 978-3-540-78828-7 ISBN: 978-9-012-11883-5

2/164


Volgorde van het behandelen van de stof Binnen TestGoal is ervoor gekozen om alle activiteiten te behandelen in een sequentiële volgorde. De stappen van een testtraject worden in het boek doorlopen in dezelfde volgorde als deze ook in praktijk worden toegepast. Ervaring leert dat studenten het vaak moeilijk vinden om zich voor te stellen hoe testen in de praktijk gedaan worden. Ikzelf krijg regelmatig de vraag „Jij bent een tester, wat doe je nu de hele dag?‟ Door voor deze opzet te kiezen, help ik de student deze vraag voor zich zelf te beantwoorden. Het antwoord is dat de activiteiten veranderen gedurende het testtraject, maar dat de opeenvolging van de activiteiten logisch is en een geheel vormen. Deze opzet maakt het boek inzichtelijk en leesbaar, er kleeft ook een nadeel aan. Worden de stappen gedurende de lessen in chronologische volgorde behandeld, dan wordt er in het begin stil gestaan bij voor de student meer abstractere activiteiten. „Hoezo, moet ik een planning opstellen, ik weet nog niet eens wat testen is‟, is een te verwachte reactie, net als „Wat moet ik in een testplan zetten, kun je me niet eerst vertellen hoe een testgeval eruit ziet?‟ Het kan vanuit dit oogpunt ook wenselijk zijn om te beginnen met de praktische hands-on hoofdstukken en deze ervaring de student uitleggen dat er randvoorwaarden en voorbereidende stappen nodig zijn voor een „gedegen testproject‟. De hoofdstukken 1 t/m 5 bevatten basis kennis die te allen tijde relevant is. Graag laat ik aan de docent over welke hoofdstukken van het boek hij in de colleges opneemt en in welke volgorde deze behandeld worden. Onderstaande figuur kan hierbij helpen. De figuur helpt de docent een andere logische volgorde te bepalen die beter aansluit bij de beleving van de student.

3/159


Resultaatgedreven zijn 1. Een vak in ontwikkeling

2. Resultaatgedreven testen

3. Testprincipes

5. Verschillende toepassingen van testen

4. Testexpertise

Een gedegen testtraject doen 14. Testdata

11. Intake testbasis

Wordt gebaseerd op

Maakt gebruik van

17. Intake systeem

15. Testomgeving

Snel een klein project doen Maakt gebruik van

13. Fysiek testontwerp

Entry criterium

Is nodig voor

Worden uitgevoerd

18. Uitvoering

Leid tot

19. Bevindingen registratie

Levert op

12. Logisch testontwerp

Wordt gebaseerd op

Wordt gebaseerd op

Wordt gebaseerd op

Bevat informatie over

8. TRA Wordt gebruikt bij

16. Test automatisering

20. Testrapportage

10. Testplan

9. Begroten en plannen Wordt gebruikt bij

7. Inventaris beoogd resultaat

Wordt gebruikt bij

Wordt gebruikt bij

21.Borging

Hoofdstukken die tijdens de colleges niet behandeld worden, kunnen als naslag werk gebruikt worden als de student testen weer tegenkomt bij opdrachten en projecten.

4/164


Het eerste college (Een eerste ervaring met testen) Om een eerste gevoel te krijgen bij wat testen nu inhoud, kan het effectief zijn om de student eerst op zijn gevoel te laten testen, bv aan de hand van onderstaande reisverzekeringapplicatie. (zie ook https://www.anwb.nl/verzekering/pages/reiskort/reiskortverzekering.jsf)

Vraag de studenten om zonder voorkennis of voorbereiding de premie berekening te testen. Belangrijke vragen zijn: 1. Welke 10 testen zou je kunnen uitvoeren, welke testen zou je kunnen 2. 3. 4. 5.

6.

uitvoeren, maar doe je niet? Geef voor elk van de bij 1. bedachte testen aan waarom je deze test wil uitvoeren, Stel je gaat achter de computer zitten om deze testen daadwerkelijk uit te voeren. Omschrijf welke handelingen jij of een andere tester moet verrichten Welke getallen voer je in? Wat heb je verder nog nodig om deze test te kunnen uitvoeren (bv een computer met internet, een niet-standaard browser en een stopwatch om de performance te meten) ? Wat doe je met je resultaten van je test?

Ad 1: leg uit dat het onmogelijk is om alles te testen en dat er keuzen gemaakt dienen te worden. Er zijn  de afbakening van de opdracht (wat wordt er van mij verwacht, dien ik alleen het getoonde scherm te testen, of moet ik de context ook mee testen, zijn er andere aandachtpunten die buiten de scope vallen, wie neemt deze voor zijn rekening)  de keuze in wat belangrijk is (de link naar de test-risico-analyse) de test die het snelst een bevinding oplevert („kijk ik ben een goede tester, ik heb een belangrijke fout gevonden).

5/159


Ad 2: leg uit dat er logische testen zijn (wat) en fysieke testen zijn (hoe). Het antwoord op deze vraag kan heel goed een logische test zijn, of de formulering van het „doel van de test‟ in het fysieke testgeval. Ad 3: het antwoord op deze vraag, zijn de test actie omschrijvingen uit de fysieke test. Ad 4: leg een link met testdata en verschillende typen testdata die er zijn. Ad 5: De benodigdheden zul je tijdig moeten regelen, dit zijn typisch dingen die je in een testplan adresseert en geregeld moet hebben voordat je begint met de test uitvoering. Ad 6: Leg een link met „bevindingen registratie‟ en „testrapportage‟. Hierin licht al besloten dat er betrokkenen zijn die graag willen weten wat de kwaliteit van de applicatie is. Sta stil bij „waarom‟ ze dat willen weten, en de reden voor hun interesse. Blijkbaar hebben ze een (business) belang bij de applicatie. Dit is de inleiding tot het resultaatgedreven testen. Interessante eigenschappen van deze applicatie (zoals geconstateerd op 1 april 2008):  Er kunnen 999 verzekerden vanaf 5 jaar worden ingevoerd, en 99 onder de 5 jaar  29-02-2009 wordt automatisch 01-03-2009  Een verzekering in de toekomst kan niet worden berekend (probeer bv een datum na 2010)  Negatieve reissom wordt geaccepteerd, dien ik nu bij te betalen als ik mijn reis annuleer?  De foutmelding bij een alfanumerieke reissom, spreekt over een nummer in plaats van een bedrag. Technisch correct, maar niet erg mooi.  Performance is niet erg hoog.

6/164


1

Testen, een vak in ontwikkeling

1.1

Aantekeningen

7/159

Hoofdstuk - Resultaatgedreven Testen

2

Resultaatgedreven Testen

2.1

Algemeen

Ratio testers tot ontwikkelaars De verhouding tussen de testers tot ontwikkelaars loopt uit een. Er kan geen concrete uitspraak hierover gedaan worden. Er kan ook geen vaste verhouding gebruikt worden, omdat er bepaalde aspecten hierbij een rol spelen die deze verhouding kunnen beïnvloeden. Deze aspecten zijn onder andere: • Complexiteit van het project • Omvang van het project • Type project • Hoeveelheid code • Kwaliteitsattributen van het product • Project planning • Hoeveelheid functionaliteit van het product • Capaciteiten medewerkers (ontwikkelaar en testers) Uit meerdere bronnen blijkt dat de industrie standaard voor de verhouding tester/ontwikkelaar op dit moment 1:3 is. Uit een onderzoek gedaan in 2000 over de verhouding tussen de testers en de ontwikkelaars is dit ook naar voren gekomen. Aan dit onderzoek hebben 29 bedrijven deelgenomen. De onderstaande grafiek toont de resultaten van dit onderzoek.

Hieruit wordt geconcludeerd dat 1:3 een ideale verhouding is. Toch moet een organisatie haar eigen situatie goed analyseren om de beste verhouding te kiezen. Referenties:  http://www.riceconsulting.com/articles/tester-developer-ratio.htm  http://www.stickyminds.com/sitewide.asp?ObjectId=3397&Function=DETAIL BROWSE&ObjectType=ART  Sizing the QA Group - Theory and Application 8/164


  

http://testmuse.spaces.live.com/Blog/cns!FCF2D51D333DA1FD!141.entry http://www.kiberle.com/pnsqc1/estimate.doc http://www.jrothman.com/Papers/ItDepends.html

2.2

Zelftoets

Vraag 1. 

Binnen TestGoal wordt de definitie gebruikt zoals deze in Van Dale staat: Een test is een toetsing van de kwaliteit, geschiktheid van personen of zaken [Van Dale].

Er zijn echter meer definities in omloop, bijvoorbeeld: 

Activiteiten die uitgevoerd worden om een of meer kenmerken van een product, proces, of dienst vast te stellen volgens een gespecificeerde procedure [ISO/IEC Guide 2, 1991].



Testen is een manier om in te schatting welke risico`s worden genomen wanneer een applicatie in gebruik wordt genomen. [www.wireitup.nl]



In general, testing is finding out how well something works. In computer hardware and software development, testing is used at key checkpoints in the overall process to determine whether objectives are being met. [http://64.233.183.104/search?q=cache:vlsezNwCqgQJ:searchwindevelopm ent.techtarget.com/sDefinition/0,,sid8_gci534970,00.html+testing+definition &hl=nl&ct=clnk&cd=1&gl=nl&client=firefox-a]

Vraag 2. Als testtrajecten goed ingericht worden, hebben ze veel toegevoegde waarde voor de organisatie : 1. Draagt bij aan de totstandkoming van „fit for purpose‟-systemen die werken conform de vastgestelde requirements, kwaliteitsattributen en (impliciete) verwachtingen. Het draagt bij aan het resultaat. 2. Voorkomt schade op het moment dat het systeem in productie is, doordat de tijdens het testen gevonden fouten voortijdig zijn opgelost. Het neemt de oorzaak weg 3. Voorkomt schade op het moment dat het systeem in productie is. De fouten in het systeem zijn bekend en er wordt geanticipeerd op de gevolgen van de fout. Het reduceert de impact. 4. Levert inzicht in de kwaliteit van het testobject, waardoor er vertrouwen in het testobject ontstaat. 5. Levert inzicht in de kwaliteit van het testobject en de voortgang van de realisatie, waardoor er effectieve projectsturing mogelijk is [Black, 2002]. Vraag 3.

9/159


Risico‟s die optreden als er niet getest wordt zijn onder meer: 









 

  

Het product is van onvoldoende kwaliteit, het bevat harde bugs, fouten waarvan iedereen zonder discussie instemt dat deze niet in het systeem horen te zitten; bijvoorbeeld een auto die niet start, een kopieer apparaat dat elke keer vast loopt, een fototoestel dat niet scherpstelt, een routenavigatie die de verkeerde weg wijst. De totale kosten die nodig zijn om het product in een werkende toestand te krijgen, inclusief de noodzakelijke bug-fixes nadat het systeem in productie is genomen, bedragen vele male meer de noodzakelijke kosten. Omdat conform de curve van Boehm, fouten in productie oplossen vele malen minder efficiënt is dan deze in een vroegtijdig stadium verwijderen. Het systeem wordt wel in productie genomen, maar levert niet het beoogde resultaat op. Niet zelden word de klantwens onvoldoende goed begrepen, waardoor het systeem technisch wel werkt, maar niet het klantprobleem oplost. Testen is een van de processen die dit controleert en kijkt of het systeem „fit for purpose‟ is. Er worden beslissingen genomen op basis van „gut-feeling‟. Dit houdt in dat de projectmanager wel beslist naar productie gaat, maar niet kan uitleggen waarom hij denkt dat het systeem goed is, of welke risico‟s de organisatie loopt. Het project legt accenten op de verkeerde zaken, omdat het geen informatie heeft of de werkelijke status en kwaliteit van ontwikkeling. Bijvoorbeeld een project waarbij de ontwikkelaar gepusht worden op meer modules op te leveren, terwijl testen had kunnen aantonen dat de kwaliteit van de opgeleverde modules onder de maat is. Het was verstandiger geweest om eerst te zorgen dat met de reeds ontwikkelde programmatuur, in productie gegaan kan worden. Voordeel hiervan zou kunnen zijn dat er voor een deel al efficiënter gewerkt kan worden en er kosten uitgespaard worden, of dat de gebruikers al kunnen wennen aan het nieuwe systeem. Argument voor systeemtest, of functionele acceptatie test: Bij integratie van systemen, breekt de keten, maar het is niet te achterhalen waar het proces fout gaat, omdat het gedrag van de betrokken systemen onbekend is. Gebruikers weigeren met het systeem te werken omdat ze in de aanloop hebben ervaren dat het systeem niet lekker werkt. Nadat deze fouten zijn opgelost is het imago van het pakket aangetast en is de weerstand voor het gebruik ontstaan. Dit had voorkomen kunnen worden door deze fouten, voordat de gebruikers met het systeem in aanraking zouden komen, te vinden en verwijderen. Een organisatie kan niet aantonen dat hij kwaliteit serieus neemt en kan daarom claims niet afhouden. Een organisatie verliest zijn ISO 9001 certificaat, of moet boete betalen omdat hij niet voldoet aan de gestelde normen, zoals SOx. En last but not least: Het bedrijf behaald zijn beoogde doelen niet, klanten zijn ontevreden en lopen weg, de bedrijfsnaam loopt schade op.

Vraag 4. Het is belangrijk om de betrokkenen, of de belanghebbenden van het software ontwikkeltraject te kennen, omdat het testproces faciliterend is aan de business en het ontwikkel proces. De belanghebbenden kunnen aangeven welke zaken echt belangrijk 10/164


zijn en welke zorgen/vragen zij hebben. Door deze goed te kennen kan het testproces zo aangepakt worden, dat de vragen beantwoord worden en het testen toegevoegde waarde heeft. Vraag 5. De volgende betrokkenen zijn te onderscheiden, met hun persoonlijk belang: Gebruikers Beheerders

Controller

Ontwikkelaars Analisten en systeemontwerpers

IT-architecten

Projectmanagers

Ongestoord hun taken uitvoeren of deze met nieuw systeem beter en efficiënter doen Met zo weinig mogelijk inspanning zorgen dat de bedrijfsprocessen en dienstverlening het afgesproken niveau blijft houden of zelfs verbeterd Kunnen aantonen dat het bedrijf voldoet aan de verplichtingen en zo efficiënt mogelijk de hiervoor benodigde gegevens kan produceren en reproduceren. Het maken van goedwerkende code, met voldoende functionaliteit binnen de gestelde deadline. Het zodanig ontwerpen van een systeem dat dit allereerst bijdraagt aan het beoogde resultaat, maar ook de aan de eisen en wensen van de andere belanghebbenden voldoet, zoals gebruikersvriendelijk, gemakkelijk onderhoudbaar, flexibel zodat het aan te passen is aan toekomstige ontwikkelingen in de markt, echt. Het uizetten van een lange termijnvisie opdat de bedrijfsprocessen en dienstverlening ook in de toekomst kan blijven doorontwikkelen zonder dat grote redesign acties nodig zijn. Het realiseren van de afgesproken functionaliteit binnen de gestelde deadline en het afgesproken budget

Vraag 6. Je bent resultaat gedreven als je Of het resultaat van de business centraal zet in elke stap van het testproces. En de focus legt op het leveren van toegevoegde waarde voor het beoogde businessresultaat en voor het softwareontwikkelproject. Ofwel als je bewust en actief bezig bent om:  het beoogde resultaat te kennen en te begrijpen;  alleen die activiteiten te ondernemen die bijdragen aan het beoogde resultaat, of die de gewenste informatie oplevert over de mate waarin dit resultaat gehaald is;  de belanghebbenden tijdig te voorzien van begrijpbare informatie.

2.3

Opdrachten

Opdracht 1. Het antwoord van deze vraag kan alles zijn, afhankelijk van de keuzes die de student heeft gemaakt. Het maakt niet zozeer uit wat voor een bedrijf er gekozen wordt, of welke verbeteringen er voorgesteld worden. Belangrijk is dat de student beseft dat er een bedrijfsresultaat en techniek is. De student dient in zijn antwoord de techniek

11/159


aandacht te geven. Verificatie, het aantonen dat er een correct werkend systeem gemaakt is. De student dient ook te laten zien dat hij begrijpt dat het systeem met een reden wordt gemaakt/aangepast en met testen wordt getoetst of het systeem de oorzaak achter de behoefte wegneemt. Deze vraag kan individueel gemaakt worden, maar ook goed in groepsverband. Laat de studenten samen een bedrijf kiezen en een korte brainstorm houden. In de brainstorm dient iedereen zoveel mogelijk ideeën aan te dragen. Laat de groep vervolgens een paar van de verbeteringen kiezen en voor deze aangeven wat hiervoor getest dient te worden. De docent kan de groepen begeleiden in: 1) het voordragen van een bedrijf (als de groep hier zelf niet uitkomt). In het boek staan een aantal voorbeelden genoemd. 2) het time-boxen van de brainstorm sessie 3) het ervoor zorgen dat de studenten niet te diep in een functioneel/technische discussie belanden. Het risico bestaat dat de studenten erg oplossinggericht aan de slag gaan en willen bepalen hoe een verbetering zou moeten werken. Dit is prima, als het past binnen de gestelde tijd en als de studenten hier plezier aan beleven. Echter de „vertaling naar de testen in relatie tot het resultaat‟ mag niet vergeten worden.

De opdracht kan eventueel worden uitgebreid met  Mindmapping: de brainstorm sessie kan worden uitgevoerd aan de hand van een mindmap. Dit werkt vooral goed als het een groepsopdracht betreft. Stel een „scribe‟ aan die op een flip-over de suggesties van de groep opschrijft.  De vraag „wat ga je testen?‟ Uitbreiden met „Hoe ga je het testen?‟

12/164


2.4

13/159

Aantekeningen

Hoofdstuk - Testgoal en de tien testprincipes

3

Testgoal en de tien testprincipes

3.1

Algemeen

Toelichting bij de leerdoelen aan de hand van figuur 3.1. Een resultaatgedreven timmerman zal als hij geen hamer tot zijn beschikking heeft, toch naar manieren zoeken om de spijkers in het hout te krijgen en zo zijn beoogde doel te realiseren.

3.2

Zelftoets

Vraag 1. Methodieken hebben het voordeel dat:  Je kunt profiteren van andermans ervaringen (best practises)  Je kunt confirmeren aan een voorgeschreven aanpak, maar als je besluit om hier van af te wijken, kunt aangeven welke risico‟s hiermee gemoeid zijn  Je kunt communiceren over je aanpak, zonder deze aan het begin helemaal zelf te hoeven ontwikkelen.  Het makkelijker is om mensen te selecteren en uit te wisselen, omdat er een gezamenlijk begrippenkader is. Vraag 2. Een tester die zijn vak beheerst beschikt over een goede inhoudelijke kennis van onder meer IT, systeemontwikkeling, testmethodieken en de processen in een organisatie. Daarnaast heeft hij kennis van businessdomeinen zodat hij een gesprekspartner is voor de betrokkenen. Hij heeft kennis van de gangbare teststandaarden, -methodieken en -technieken. Dit laatste houdt in dat hij  Standaarden als T-map en ISTQB kent  De testontwerptechnieken zoals omschreven in dit boek kan toepassen  Weet hoe hij goede testgevallen kan formuleren  Weet wat risicogebaseerd testen is  Verschillende testsoorten kent en kan omschrijven  Enz. Vraag 3. Een mogelijke fasering is die van het V-model: Moduletest, module-integratietest, systeemtest, functionele acceptatietest, gebruikersacceptatietest, ketentest, productie acceptatie test, pilot. Of binnen een testtraject de fasering van TestGoal:

14/164


of T-map (afkomstig van de Sogeti Website):

Of testframe (afkomstig van Wikipedia):

15/159


Vraag 4. Alleen als je je werk leuk vindt, kun je je ook echt inzetten voor je taak. Mensen die plezier in hun werk hebben meer energie, zijn beter geconcentreerd en meer betrokken. Een tester die plezier en enthousiasme uitstraalt, overtuigt anderen sneller en werkt efficiënter. Zal betere resultaten boeken en daarom sneller stijgen op de carrièreladder. Deze positieve bevestiging maakt het werkt natuurlijk weer leuker en zo ontstaat er een positieve vicieuze cirkel. Vraag 5. Vertrouwen wordt opgebouwd door  Je werk goed te doen! Dit kan door kwaliteit te leveren en de goede dingen te doen (in context van het beoogde resultaat) en hier duidelijk over te communiceren.  Niet alleen fouten te zoeken, maar ook aan te geven welke zaken goed zijn  Inzicht te geven in zijn werk en werkwijze (transparantie)  Fouten toe te geven Vraag 6. Een tester kan zich inleven in beide werelden. Hij heeft voldoende IT kennis om te communiceren met de ontwikkelaars en analisten. Zijn systeem kennis helpt hem om de technische issues te vertalen naar de wereld van de businessmanager en gebruiker. De tester heeft kennis van het domein en de processen binnen de organisatie. Met deze kennis is hij in staat om de gebruikers te begrijpen en een vertaling te maken van beoogd resultaat naar techniek. Een tester ziet daarnaast vaak als eerste het gehele systeem. Programmeurs zien vaak allen stukken van het systeem, en denken in modules in plaats van bedrijfsprocessen. Gebruikers zien (vaak in een later stadium) wel het hele proces maar hebben vaak minder gedegen technische kennis. Dit plaatst de tester in een unieke positie waarbij hij kennis en overzicht heeft van zowel de techniek achter het systeem en de toepassing ervan. Een ideale positie om te bemiddelen en bruggen te slaan. 16/164


Vraag 7. Overzicht en inzicht geven is een belangrijk instrument om vertrouwen te krijgen, daarnaast helpt het om de toegevoegde waarde van het testen inzichtelijk te maken. Overzicht en inzicht worden gegeven aan de belanghebbenden. In de regel wordt inzicht meer gegeven aan de inhoudelijk betrokkenen, zoals ontwikkelaars, technisch projectleiders en analisten, en overzicht aan de minder inhoudelijk betrokkenen, zoals businessmanagers. Overzicht en inzicht zijn twee begrippen die haaks op elkaar staan. Overzicht houdt in dat de tester een „helicopter view‟ heeft. De resultaten en de bevindingen met elkaar in verband kan brengen, en kan vertalen naar de belevingswereld van de belanghebbenden. Dit is een breed, maar niet diepgaand verhaal. Indien nodig kan de tester echter ook inzicht geven: Inzicht houdt in dat de tester de technische details weet en zijn globale verhaal kan onderbouwen met steekhoudende argumenten. Inzicht is „smal maar diep‟ georiënteerd.

Vraag 8. De doelstelling van de resultaatgedreven tester reikt verder dan het bijdragen aan het verbeteren van de softwarekwaliteit. De testen die de resultaatgedreven tester uitvoert, moeten kunnen vertellen of het systeem gaat bijdragen aan de resultaten die de organisatie nastreeft. Het is de focus op het resultaat die de toegevoegde waarde van het testen optimaal zichtbaar maakt voor de belanghebbenden. Het zichtbaar maken van de toegevoegde waarde maakt dat de tester een belangrijke partner wordt van het management. Hierdoor is het gemakkelijker om de benodigde middelen en tijd te krijgen, waardoor de testen beter uitgevoerd kunnen worden. Dit leidt weer tot meer toegevoegde waarde en meer resultaat, waardoor de tester zijn bijdrage aan de organisatie op zich ook weer kan groeien. Dit is bevredigend en maakt het testen extra leuk. Vraag 9.  Slechte inventarisatie klantwens  Ondoordacht ontwerp  Onvoldoende kwaliteit programmeerwerk  Slecht configuratie- en versiebeheer

17/159


Vraag 10. Het hergebruiken van producten en kennis zorgt ervoor dat alle tijd en moeite die nodig was om de producten te realiseren en de kennis op te bouwen, bij een vervolg traject niet opnieuw nodig zijn. De investering wordt beter terugverdiend. Typische producten die goed hergebruikt kunnen worden zijn:  Testgevallen (voor de regressietest)  Simulatoren, stub en drivers (voor de regressietest)  Kennis van het systeem en de systeemconfiguratie (voor training en beheerorganisatie die het productie systeem moet configureren)  Ervaring van de bottleneck in het ontwikkelproject (voor de projectmanager van het volgende project)  Ervaring van het testtraject (Ter verbetering van de algemene teststrategie) Producten die mindergoed te hergebruiken zijn  De risicoanalyse (omdat de risico‟s in de loop van de tijd veranderen)  De testaanpak (omdat de beste aanpak en het beoogde resultaat voor elk project anders is)  De bevindingen (omdat deze als het goed is zijn opgelost)  Begroting (omdat het volgende project anders is) In het testplan wordt de overdracht gedefinieerd van producten en kennis. In de gerelateerde paragraaf worden voorbeelden gegeven van de overdracht. Een aantal zaken die genoemd worden in bovenstaand antwoord hebben een link met de projectevaluatie. Deze is behandeld in stap 6 van het TestGoal stappenplan. Tijdens het college kan eventueel naar beide hoofdstukken worden verwezen. Dit bevordert het inzicht in de samenhang van de activiteiten. In de betreffende hoofdstukken zijn ook voorbeelden te vinden die deze punten concreter maken. Vraag 11. Sla een brug naar bijvoorbeeld  de beheerorganisatie ten behoeve van de regressietest en de configuratie van het productie systeem.  de verantwoordelijken voor de training van de gebruikers. Geef hen informatie over de eigenschappen, known issues en eigenaardigheden van het systeem, zodat dit in de training meegenomen kan worden. Binnen het voorbeeld project Connecta (zie voorbeeld 7.1) zijn 4 deelprojecten ingericht,  Processen  Software ontwikkeling  Testen  Implementatie Bruggen kunnen geslagen worden naar bv de procesontwerpers, de ontwikkelaars en analisten. Het deelproject „Implementatie‟ is verantwoordelijk voor de training van de gebruikers. Naar de trainer en de gebruikers kunnen bruggen geslagen worden.

18/164


3.3

Opdrachten

Opdracht 1. Zet het nummer van de omschrijving bij de juiste letter van het icoontje. A

F

1: Beheers het testvak 6: Test gefaseerd

B

G

2: Testen is leuk

7: Bouw aan vertrouwen

C

H

3: Sla bruggen

8: Geef overzicht en inzicht

D

I

4: Focus op resultaat

9: Neem verantwoordelijkheid

E

J

5: Zorg voor herbruikbaarheid

10: Testers faciliteren de gehele ICT-lifecycle

Letter A B C D E F G H I J

Nummer 2 5 9 10 3 4 1 8 7 6

Opdracht 2. Het antwoord op deze vraag is een persoonlijke mening, dus er zijn verschillende antwoorden mogelijk. Overweeg om de opdracht als groepsopdracht uit te voeren. Laat de studenten onderling een paar favorieten keizen. Welke is niet echt van belang, het doel van de opdracht is dat de studenten nadenken over de principes en de betekenis ervan. Eventueel kan er een spel element worden toegevoegd waarbij de elke groep een

19/159


principe krijgt toegewezen met de opdracht de andere groepen te overtuigen dat hun principe inderdaad het allerbelangrijkste principe van allemaal is. Dit doet een appèl op hun verkoopkwaliteiten, maar dwingt hun ook om met een paar goede inhoudelijke argumenten te komen. Op www.testgoal-educatief.nl is een „Mijn principe is het belangrijkst, omdat...‟ template beschikbaar ter ondersteuning van deze oefening.

Opdracht 2. Met de ICT lifecycle wordt het proces bedoeld dat begint met het definiëren van de wens, daarna gevolgd wordt door de definitie, bouw en testen. Dit wordt weergegeven in onderstaand figuur. Deze figuur geeft de relatie tussen de ontwikkelcyclus aan en het testproces.

Wish

Result

Requirements

Test plan & strategy

Design

Review (intake Test base)

Coding

Test design Setting up environment

Testing

Deployment

Test execution

Release advice

Na deployment zal het project vaak stoppen, maar tot de ICT lifecycle hoort ook het in product nemen en hebben van het product. Verschillende ontwikkelmethoden hebben een verschillende fasering. Bovenstaande fasering behoord bij een waterval aanpak. Bij meer agile aanpakken zal de fasering meer iteraties kennen en de scheiding tussen definitie en bouw minder duidelijk zijn.

20/164


Verkoop

De ICT lifecycle is de ontwikkelcyclus, deze wordt vaak verward met de Product lifecycle. Deze laatste geeft de afzet van het aantal producten tijdseenheid weer als functie van de verschillende fasen in de cyclus. .

Introductie

Groei

Volwassenheid

Afname

Zie voor meer informatie over de Productlevenscyclus: http://nl.wikipedia.org/wiki/Productlevenscyclus Opdracht 3. Focus op resultaat

Zorgt ervoor dat je resultaten neerzet en meer bereikt, dit maakt niet alleen het vak leuk, het zorgt er ook voor dat je meer vertrouwen geniet van je omgeving.

Bouw aan vertrouwen

Doe je onder andere door focus te hebben op resultaat, overzicht en inzicht te geven aan de hand van een duidelijke fasering, door te laten zien dat je het vak beheerst en bruggen slaat naar betrokkenen, etc.

Neem verantwoordelijkheid Draagt bij aan vertrouwen, maar is nodig om resultaat te behalen. Verantwoordelijkheid neem je door o.a. door overzicht te geven (ook als dit over fouten gaat) en door de lifecycle te facilteren. Beheers het testvak

21/159

Draagt bij aan vertrouwen, maar is nodig om resultaat te behalen


Sla bruggen

Draagt bij aan o.m. inzicht en overzicht, maar ook aan vertrouwen

Test gefaseerd

Draagt bij aan o.m. inzicht en overzicht

Faciliteer de gehele ICTlifecycle

Draagt bij aan o.m. het resultaat, zal het nodig maken om bruggen te slaan.

Geef overzicht en inzicht

Draagt bij aan o.m. het vertrouwen, geeft overzicht en inzicht in die zaken die gerelateerd zijn aan het resultaat, zal het nodig maken om bruggen te slaan.

Zorg voor herbruikbaarheid Draagt bij aan o.m. het resultaat

Bedenk: testen is leuk

Als je het werk leuk vind, kom je overtuigender over, dus dit wekt vertrouwen, het zal je motiveren om je vak goed te beheersen en een resultaat neer te zetten.

22/164


3.4

23/159

Aantekeningen

Hoofdstuk - Testexpertise

4

Testexpertise

4.1

Zelftoets

Vraag 1. De testmanager

Heeft zicht op de businessbehoeften en -wensen. Daarnaast beschikt hij over projectmanagementvaardigheden én heeft hij ervaring als tester

De testcoördinator

een ervaren tester zijn én over projectleidersvaardigheden beschikken.

De testanalist

De testanalist kent zijn testontwerptechnieken en weet in welke situatie bepaalde technieken effectief zijn. Omdat hij veel communiceert met de analisten en ontwerpers en het systeemontwerp als zijn beschouwingsgebied heeft, kent hij ook systeemontwerptechnieken

De testengineer

heeft hij kennis van de testontwerptechnieken Kritisch

De testautomatiseerder

heeft kennis van testen en van programmeren Bekend is met de relevante tooling kan hij testscripts programmeren en parametriseren. Hij heeft technische kennis van het systeem

De performancetester

simulators en load-generatoren foutanalyse en significantie technische kennis in staat om samen met de systeemspecialisten vast te stellen welke systeemparameters de performance beïnvloeden. IT-architectuur, database-inrichting en de werking van de systemen

De securitytester

heeft kennis van de belangrijkste „security vulnerabilties en exploits‟ (Dus de gaten in de security en de programmaatjes die gemaakt zijn met het doel om misbruik te maken van de gaten in de security) herkent de meestgemaakte securityfouten dan ook snel, heeft brede kennis van hardware en software heeft kennis van de testontwerptechnieken

Vraag 2. De testcoördinator is verantwoordelijk voor één testtraject (of testsoort), de testmanager is verantwoordelijk voor meerdere testsoorten.

24/164


Analoog hieraan, de testcoördinator stuurt een aantal testers aan, de testmanager een aantal testcoördinatoren. Vraag 3. De testengineer voert de testen uit. Hij heeft systeemkennis die hij tevens gebruikt voor het vertalen van een logisch testontwerp naar een fysiek testontwerp. De testanalist is minder direct bij het systeem betrokken en stelt het logische testontwerp op. Merk op dat beide rollen ook vaak in een persoon zijn vertegenwoordigd. Alleen bij grote organisaties / projecten zullen deze rollen erg sterk uit elkaar getrokken zijn. Vraag 4. In testgoal zijn de volgende specialismen behandeld: securitytesten, SOA, testautomatisering, performancetesten en conformancetesten.

4.2

Opdrachten

Opdracht 1. Betrokkenheid testrollen

mate van betrokkenheid

4

3

De testmanager

2

De testcoördinator 1

0 Resultaat

Aanpak

Ontw erp fase

25/159

Inrichten

Uitvoering

Borging


Betrokkenheid testrollen


4

3

De testanalist

2

De testengineer 1

0 Resultaat

Aanpak

Ontw erp

Inrichten

Uitvoering

Borging

fase

Betrokkenheid testrollen


4

3 De testautomatiseerder 2

De performancetester De securitytester

1

0 Resultaat

Aanpak

Ontw erp

Inrichten

Uitvoering

Borging

fase

Opdracht 2. Deze opdracht heeft meerdere goede antwoorden. Doel van de vraag is dat de student goed nadenkt over de competenties van de tester en kan uileggen waarom deze belangrijk zijn. Het is prima als de student bronnen raadpleegt op het internet. Hierdoor leert de student de bedrijven kennen die testers zoeken en ervaart hij dat testers gewild zijn op de arbeidsmarkt. Als de studenten een vacature tekst kopiëren, dienen ze nog wel geprikkeld te worden om de testprincipes te herkennen. Vraag ook naar de motivatie van hun keuzes. Waarom heb je bepaalde elementen in de vacaturetekst opgenomen? Onderstaande vacature tekst (bestaande vacature) bevat een groot aantal verwijzingen naar de testprincipes.

26/164


Deze opdracht kan ook goed in groepsverband worden uitgevoerd. Opdracht 3. De antwoorden op deze vraag staan door het hele boek gegeven. Denk in argumenten als „toolbox‟, methodekennis, kunnen sparren met IT‟ers, kunnen uitleggen waarom je van de methodiek afwijkt, het testprincipe vertrouwen en het deel inzicht in „ overzicht en inzicht‟.

27/159


4.3

Aantekeningen

28/164


5

De Aanpak

5.1

Algemeen

Toelichting op het stappenplan De weergave van het stappenplan bestaat uit een vijfhoek met daaromheen vijf zeshoeken. De vijfhoek is in het midden geplaatst en staat voor Resultaat. Het resultaat dient tijdens alle vervolgstappen voor ogen gehouden te worden. De vervolgstappen Aanpak, Ontwerp, Inrichting, Uitvoering, en Borging zijn weergegeven als zeshoeken. In de weergave van het model heeft elke zeshoek een raakvlak met de centrale vijfhoek. Dit staat symbool voor het contact dat er binnen elke vervolgstap moet zijn met het in de eerste stap vastgestelde resultaat. Voordelen van het hanteren van een stappenplan De voordelen van het stappenplan zijn hierna weergegeven.  Goede dingen doen Het stappenplan definieert welke activiteiten binnen het testtraject gedaan moeten worden en in welke volgorde deze het beste uitgevoerd kunnen worden.  Communiceren aanpak Het stappenplan biedt een concreet voorstel voor de testaanpak. Aan de hand van het stappenplan kan snel invulling gegeven worden aan het testtraject. Het stappenplan geeft aan wat de geplande stappen zijn en welke producten worden opgeleverd. Hierdoor kan de tester de opdrachtgever en de overige belanghebbenden duidelijk uitleggen wat hij wil gaan doen. Dit bevordert het afstemmen van de verwachtingen en geeft de opdrachtgever handvatten om aan te geven wat hij wil.  Maakt risico’s bespreekbaar Het stappenplan is geen dwingend keurslijf, maar vormt een referentie. Het is altijd mogelijk om een stap over te slaan, maar men dient zich wel bewust te zijn van de risico‟s die hiermee gepaard gaan. De keuze dient dus gemaakt te worden na het bespreken van de risico‟s.  Testrapportage Het stappenplan geeft duidelijk aan wanneer welke producten opgeleverd worden. Bij het bewaken van de voortgang is duidelijk welke producten er in elke stap afgerond moeten zijn.  Generieke aanpak Het hanteren van het stappenplan maakt het mogelijk om een generieke testaanpak te hanteren voor de verschillende testtrajecten. Dit maakt de testtrajecten beter stuurbaar en vergelijkbaar.

Toelichting op het Tolstoi-citaat ‘Alle gelukkige gezinnen lijken op elkaar, elk ongelukkig gezin is ongelukkig op zijn eigen wijze’- Leo Tolstoi in Anna Karenina. Het boek Anna Karenina gaat over een ongelukkig huwelijk en de lezer krijgt gedurende het boek begrip van waarom het huwelijk van Anna niet goed is. Het boek

29/159

Hoofdstuk - De Aanpak

opent met het bovenstaande citaat. Met dit citaat wil Tolstoi uitleggen dat een relatie, huwelijk of gezin aan veel voorwaarden moet voldoen om gelukkig te zijn. Een gezin is pas gelukkig als aan alle voorwaarden voldaan is, en daarom lijken alle gelukkige gezinnen wel een beetje op elkaar. Als aan één of meer voorwaarden niet is voldaan, is het gezin minder of niet gelukkig. Omdat er zoveel voorwaarden zijn, is het aantal variaties in ongelukkige relaties, huwelijken of gezinnen zo groot. Vanuit dit citaat zijn vele parallel te trekken. Elke succesvol testtraject zal aan een aantal voorwaarden voldoen. Deze voorwaarden zijn zoveel mogelijk gebruikt bij de totstandkoming van dit boek. Het citaat is ook toepasbaar op testmethodes. Om goed te testen, zijn er een aantal dingen die je altijd zal moeten doen. Dit verklaart ook waarom op; het eerste gezicht veel testboeken op elkaar lijken. Ze vertellen meestal wel iets over het V-model, risico‟s, bevatten een vorm van stappenplan, etc. Voor een nieuw boek is het geen diskwalificatie als dit ook deze elementen bevat, het kan zich echter onderscheiden in de wijze hoe het deze generieke geaccepteerde voorwaarden voor een goed testtraject uitlegt en handvatten geeft.

5.2

Zelftoets

Vraag 1. Resultaat, Aanpak, Ontwerp, Inrichten, Uitvoering, Borging Vraag 2. Als testwerk een hoog repeterend gehalte heeft, zoals dat bijvoorbeeld het geval is bij het testen van een onderhouds- of bugfixrelease van een reeds operationeel systeem, worden de testen vaak in de lijn belegd. Dit heeft het voordel dat de testorganisatie ook na het testen blijft bestaan en de kennis behouden blijft. Als de wijzigingen echter ingrijpender zijn kan, of er zelfs een nieuw systeem gebouwd wordt, is er meer organisatie nodig. Vaak wordt er dan gekozen om dit met een apart, dedicated team te realiseren. Testen vindt dan vaak plaats in een project omgeving. Typisch van een projectteam is dat deze wordt ontbonden als de klus geklaard is. Dit houdt natuurlijk niet in dat overdracht naar de lijn niet belangrijk is. Mede hierom is overdracht als apart onderwerp opgenomen in het TestGoal Testplan. Archetypen testorganisaties Er zijn drie archetypen voor testorganisaties, deze zijn weergegeven in onderstaande figuur, afkomstig uit het TestGrip boek [TestGrip, 2007]

30/164


Afhankelijk van de volwassenheid van de organisatie zullen de verschillende archetypen gebruikt worden om de testen te organiseren. Een jonge organisatie met weinig testervaring zal in de regel het testen in de projecten beleggen. Als er behoefte staat aan een stabielere aanpak ontstaat een staforganisatie, die bewaakt of de algemene aanpak goed gehanteerd wordt. Staf organisaties hebben in de regel geen verantwoordelijkheid, dus groeit de organisatie verder, worden testen vaak in een lijnorganisatie belegd. Deze lijn organisatie zorgt voor de resourcing en borgt alle testkennis en ervaring. Toch zal er altijd de behoefte bestaan om bepaalde zaken binnen het project te testen, als is het maar omdat veel projecten zulke specifieke kennis vereisen dat de lijn organisatie die binnen de algemene organisatie niet beschikbaar is. De zwarte beogen pijl in het midden geeft aan dat er daarom vaak een hybride vorm onstaat, waarbij testen sommige testen in het project gebeuren, er een staf organisatie is en bepaalde testen vanuit een lijn organisatie worden georganiseerd.

Vraag 3. Kwaliteitsattributen omschrijven eigenschappen van het systeem die de kwaliteit bepalen. In feite is dit een opdeling van „Het systeem heeft kwaliteit‟ naar specifieke eigenschappen, zoals functionaliteit, onderhoudbaarheid, performance security, enz. Deze opdeling maakt kwaliteit beter bespreekbaar omdat we de vraag kunnen beantwoorden, hoe belangrijk is onderhoudbaarheid voor dit systeem, zijn de eisen t.a.v. performance strikt? Etc. De kwaliteitseisen kunnen worden vastgelegd aan de hand van het Extended ISOmodel Quint. Quint is een uitbreiding op de ISO-9126 standaard en beschrijft de kwaliteit van software door middel van zes hoofdkarakteristieken (functionality, usability, efficiency, reliability, maintainability en portability) en 33 subkarakteristieken [Zeist, 1996]. Vraag 4. Een testsoort is een afbakening van testactiviteiten met een gezamenlijk doel, aandachtsgebied en systeemgrens. Vraag 5. MT, MIT, ST, FAT, GAT, PAT, KT, Pilot.

31/159


Vraag 6. ISO9126 of anders het extended ISO model: QUINT. Niet genoemd in het boek, maar ook een model is : SQUA3RE Andere modellen ISO 9126 is een model dat software kwaliteit omschrijft. Daarnaast bestaan er ook modellen voor informatie kwaliteit en de kwaliteit van processen in organisaties. KING, het model voor Kwaliteit van Informatie en Gegevens omschrijft een zestal hoofdsattributen voor datakwaliteit, deze zijn Juistheid, de mate waarin informatie correct is vastgelegd Tijdigheid, Da mate waarin rekening gehouden is met tijdsaspecten, zoals de actualiteit Doeltreffendheid, de mate waarin de informatie zinvol en bruikbaar is Exclusiviteit, de mate waarin informatie beveiligd kan worden Controleerbaarheid, de mate waarin informatie geschikt is voor controle Onderhoudbaarheid, De mate waarin de informatie nu en in de toekomst beschikbaar en bruikbaar gehouden kan worden KPO het model voor Kwaliteit van Processen in de Organisatie bevat de volgende hoofkarakteristieken: Doelmatigheid, de mate waarin het proces de beoogde doelen realiseer en bijdraagt aan het bedrijfsresultaat Werkbaarheid, mate en gemak waarmee het proces uitvoerbaar is Flexibiliteit, de mate waarin het proces onder verschillende omstandigheden werkbaar blijft Efficiëntie, Mate waarin het proces zuinig is met resources en materialen Bestuurbaarheid, de mate waarin het proces transparant, meetbaar en te sturen is Organisatie, de mate waarom de organisatie en medewerkers berekend zijn op het uitvoeren van de processen. [Bouman, 2008]

Vraag 7. De voordelen van het stappenplan zijn hierna weergegeven.  Goede dingen doen  Communiceren aanpak  Maakt risico‟s bespreekbaar  Testrapportage  Generieke aanpak Zie ook bij de introductie van dit hoofdstuk. Vraag 8. In de stap ontwerpen wordt het testontwerp gemaakt. Het is belangrijk dat deze wordt gereviewd en dat de belanghebbenden vertrouwen hebben in de ontworpen testen. Daarom is het verstandig deze te laten reviewen en een akkoord te vragen. In het 32/164


hoofdstuk Testplan, staat een uitgebreid verhaal over hoe dit georganiseerd kan worden. Een alternatief antwoord zou kunnen zijn, tijdens de intake testbasis, in stap 2 Aanpak, hier wordt het systeemontwerp en de specificaties door het testteam gereviewd op testbaarheid , volledigheid en correctheid. Echter, meestal zal de tester vaak geen formele acceptatie van het ontwerp doen. Vraag 9. Binnen een nieuwbouw project wordt er een nieuw testproject ingericht. En in een beheeromgeving is dit niet het geval. Hier gaat het om kleine wijzigingen waarvoor geen nieuw project ingericht wordt. In een beheeromgeving worden meerdere kortere testtrajecten uitgevoerd. De doorlooptijden zijn korter. Bij een beheeromgeving is er al testware beschikbaar die hergebruikt kan worden. En bij een nieuwbouwproject moet het testware nog aangemaakt worden. Vraag 10. Interoperabiliteit is het kunnen samenwerken van een systeem met andere systemen. Er kunnen interoperabiliteittesten uitgevoerd worden, om zeker te stellen dat een systeem kan samenwerken met andere onderliggende systemen. Bijvoorbeeld een bankpas, waarmee het mogelijk is om in meerdere landen geld op te nemen van verschillende geldautomaten. Vraag 11. Bij embedded software; systemen worden in grote aantallen geproduceerd en gedistribueerd. Bij organisatieoverschrijdende infrastructuur, waarbij meerdere leveranciers producten afleveren die binnen dezelfde infrastructuur moeten werken. Vraag 12. Bij een nieuwbouw project wordt veel aandacht besteed aan aanpak en het uitwerken van testgevallen (binnen de TestGoal-stappenplan). En bij conformiteits- en interoperabiliteitstesten ligt het zwaartepunt juist bij Inrichten en Uitvoering. In een nieuwbouw project moet men rekening houden met veranderende requirements wat het onderhoud van testontwerp veel tijd kost. Bij conformiteits- en interoperabiliteitstesten spelen de normen een grote rol. En omdat de normen vaak vrij stabiel zijn is het beheren makkelijker (kost weinig tijd). De specificaties van conformiteits- en interoperabiliteitstesten zijn niet per se gericht op de risico‟s, maar meer op de normen. En bij een nieuwbouwproject wordt zo veel mogelijk geprobeerd om de productrisico‟s af te dekken. Vraag 13. Performance testen is het valideren van requirements ten aanzien van tijd en snelheid

33/159


en gebruik van resources van een specifiek informatiesysteem. Hierbij is de hoofdvraag „hoe snel reageert het systeem op request?‟ Vraag 14. Omdat het bij een performancetest om het uitvoeren van veel transacties gaat (om voldoende dekking te geven aan het testproces), is het niet mogelijk om dit handmatig bij te houden (hoe snel verloopt een transactie)? En waar liggen de bottlenecks?). Daarom is tooling een onmisbaar hulpmiddel bij een performancetest. Vraag 15. Curve van Boehm geeft aan, dat hoe eerder een fout gevonden wordt in het ontwikkelproces, hoe minder de kosten zijn om deze fout te herstellen. Door module test uit te voeren, kan in een vroeg stadium achterhaald worden of wijzigingen effect heeft op het systeem.

Vraag 16. Moduletesten kan en door een programmeur en door een tester uitgevoerd worden. Voor een goede module testen zou een tester enige ontwikkelkennis moeten hebben. En de programmeur zou kennis van testen moeten hebben.

5.3

Opdrachten

Opdracht 1. Resultaat Test Risico Analyse (TRA) Testplan Intake testbasis Ontwerp Intake systeem Testrapportage Borging Inrichting Configureren testomgeving Aanpak eisen testomgeving Uitvoering Testscenario Definiëren Testdata

Stap Stap 1

Activiteit

Product Stap 2 Stap 2

Stap 3 Stap 3 Stap 4 Stap 5 Stap 6 Stap 4 Stap 4 Stap 2 Stap 3 Stap 5 Stap 3 Stap 3

Opdracht 2. a) Deze vraag is op twee verschillende niveaus te beantwoorden. We kunnen de PDA zelf beschouwen met de hierop geïnstalleerde route-applicatie. We kunnen ook het gehele systeem beschouwen. Afhankelijk van de keuze zal de definitie van een module verschillen. Als we de route applicatie beschouwen, onderkennen we hierin 34/164


programma componenten die we in de module test willen testen. Beschouwen we het hele systeem, is de route applicatie in zijn geheel een component. Les hieruit is dat het belangrijk is om deze zaken goed te definiëren en vervolgens af te stemmen of de andere betrokkenen dezelfde definitie gebruiken. Beschouwen we het gehele systeem, zouden de volgende zaken kunnen getest worden: Testsoort Module test

Systeem test

Keten test

Gebruikersacceptatie test

Te testen De route applicatie, de geheugen kaart, de PDA, de GPS module de antenne. Test per module de correcte werking onafhankelijk van de toepassing ervan. BV de GPS module geeft de goede coördinaten door in het juiste formaat. De Route applicatie geïnstalleerd op een computer. Test bijvoorbeeld de correcte berekening van routes afhankelijk van twee ingegeven GPS coördinaten. Test de invoer van bestemming, de foutafhandeling, etc. Draai de s/w op de PDA, Maak gebruik van de antenne en GPS module in een real-life situatie. Test of de routeberekening en de route instructies ook op de weg naar behoren functioneren Kijk naar gebruikersvriendelijkheid. Vinden de gebruikers de stem prettig die de instructies geven, hoe duidelijk en tijdig zijn de instructies, laat het systeem zich gemakkelijk installeren en bedienen, enz.

b) Bij een conformiteitstest zou er bijvoorbeeld gekeken kunnen worden naar  Geeft de GPS module de coördinaten door in de standaard notatie  Worden de algemeen geldende symbolen gebruikt voor de points of interest (hotel, benzine pomp, enz.)  Voldoet het systeem aan de algemeen geldende veiligheidsnormen voor „apparatuur in de auto‟ Opdracht 3. Zie de uitwerking van opdracht 3.4. Hierin worden de verschillende stappenplannen getoond.

35/159


5.4

Aantekeningen

36/164


6

Aan De Slag

Bij deze sectie horen geen opdrachten of vragen

7

Inventarisatie Beoogd Resultaat

7.1

Zelftoets

Vraag 1. De Resultaatomschrijving wordt opgesteld om een duidelijk begrip te krijgen van de werkelijke reden van het project. Welke businessdoelen worden nagestreefd en wat zijn de beoogde effecten van het project? Belangrijk is dat we als testers begrijpen hoe we met de testactiviteiten kunnen bijdragen aan deze effecten. Vraag 2. Het business resultaat, het resultaat van het softwareontwikkelproject en het testtraject heeft op zichzelf ook een beoogd resultaat Vraag 3. De volgende onderdelen zijn opgenomen in de resultaatomschrijving:  Trajectnaam  Beoogd resultaat  Opdrachtgever  Opdrachtnemer  Beschouwingsgebied  Testsoort  Verwachte einddatum/beschikbaar budget  Opdrachtomschrijving  Afgesproken rapportage  Knelpunten en risico‟s. Vraag 4. MT, MIT, FAT, GAT, PAT, KT, Pilot. Vraag 5. Nee, we schrijven nooit voor dat iets altijd moet. We doen dingen omdat ze toegevoegde waarde hebben. De inventarisatie van het beoogde resultaat is een relatief kleine, maar wel uiterst belangrijke stap die de kern vormt van TestGoal. Als je niet weet welk resultaat je nastreeft is het moeilijk om dit te behalen en helemaal om te rapporteren over de mate waarin je je doel nadert. Dus bij voorkeur wordt de resultaatomschrijving wel uitgevoerd. In beheeromgevingen waar veel bugfixes worden getest, zal het beoogde resultaat op hoog niveau gelijk blijven, het is dan minder relevant om nog een keer een resultaatomschrijving op te stellen. Al hoewel, als je een systeemtest doet van een complexe change...? Wanneer is de wijziging succesvol? Deze vraag dient wel beantwoord te worden. Vraag 6. Succesfactoren die het succes van een activiteit of project bepalen.

37/159

Hoofdstuk - Inventarisatie Beoogd Resultaat

De succesfactoren formuleren die punten waarop het testtraject wordt beoordeeld. Zij zijn in principe het antwoord van de opdrachtgever op de vraag „Wanneer vind jij het testtraject geslaagd‟. Vraag 7. Bij een groot en complex traject waarbij het soms enige weken duurt voordat het Testplan is afgerond, is het belangrijk om de opdrachtgever tot die tijd inzicht te geven in de activiteiten Vraag 8. Focus op resultaat

Bouw aan vertrouwen

Tijdens de inventarisatie resultaat wordt het beoogde resultaat in kaart gebracht, opdat dit in het gehele verdere testtraject centraal kan staan Door in het begin aan te geven dat je staat voor resultaat, bouw je aan vertrouwen.

Neem verantwoordelijkheid De resultaatomschrijving legt in principe de testopdracht vast. Dit is waar de testcoördinaat zich verantwoordelijk voor stelt. Beheers het testvak Inzicht in het testen als vak en proces maakt dat de testcoördinator tijdens de inventarisatie de goede vragen kan stellen en alvast mogelijke knelpunten kan signaleren. Sla bruggen Spreken met de opdrachtgever is het slaan van een brug. Test gefaseerd

Minder van toepassing, tenzij de testcoördinator tijdens de inventarisatie al zijn beoogde aanpak communiceert.

Faciliteer de gehele ICTlifecycle

Minder van toepassing, tenzij de testcoördinator tijdens de inventarisatie uitgebreid bespreekt hoe bijvoorbeeld de borging en overdracht naar de beheerorganisatie geregeld gaat worden. Minder van toepassing, tenzij de testcoördinator tijdens de inventarisatie al zijn beoogde aanpak communiceert.

Geef overzicht en inzicht

Zorg voor herbruikbaarheid De resultaatomschrijving wordt direct hergebruikt in het testplan en later bij de evaluatie Bedenk: testen is leuk

Alleen van toepassing als de testcoördinator zijn werk leuk vind en dit laat merken tijdens de inventarisatie. 38/164


7.2

Opdrachten

Opdracht 1 Als deze opdracht als groep wordt uitgevoerd maak dan een rol verdeling. Een is de opdrachtgever, de anderen in de groep zijn de testers. Maak een afspraak met je opdrachtgever, bereid deze sessie voor en lever de resultaatomschrijving op. Indien informatie ontbreekt, mag je zelf aannames maken, dit geldt specifiek voor de persoon die de opdrachtgever speelt. Het is jouw project, dus als jij besluit dat het morgen kaal moet zijn, is dat jouw beslissing.

Voor het uitwerken van de resultaatomschrijving kan het bijbehorende template gebruikt worden. Deze is beschikbaar op www.testgoal-educatief.nl. Tevens is er een fact-sheet beschikbaar met informatie voor de „opdrachtgever‟. Op basis van deze informatie kan de student zijn rol als opdrachtgever goed invullen. De resultaatomschrijving zou er bijvoorbeeld als volgt uit kunnen zien: Resultaatomschrijving

Trajectnaam:

Systeemtest Centrale Sanctie Systeem (CSS)

Beoogd resultaat:

Opdrachtgever:

In de huidige situatie worden de registraties in verschillende systemen verwerkt en beheerd. Het CSS zal de huidige systemen vervangen, met als doel:  Het verhogen van de inkomsten door het verminderen van het percentage sancties die momenteel niet verstuurd worden.  Het besparen op portokosten door het vervangen van de huidige (papieren) brieven met e-mails.  Het voldoen aan de wettelijke verplichting m.b.t traceerbaarheid.  Reduceren van de benodigde resources door: o Het verminderen van klachten door het verminderen van de hoeveelheid foutief verstuurde sancties. o Het automatiseren van de registratieprocedure en het verminderen van de fouten die zich daarbij voordoen. Hoofd afdeling IT (L. Harmsma)

Opdrachtnemer:

Testcoördinator QA en Testen (F. Rostami)

Beschouwingsgebied:

Het CSS-systeem, incl. mail server De flitspalen behoren niet tot de scope van de systeemtest.

Testsoort:

Systeemtest

39/159

Hoofdstuk - Inventarisatie Beoogd Resultaat

Verwachte einddatum / beschikbaar budget:

De betreffende staatssecretaris eist dat het nieuwe systeem uiterlijk 1 januari 2009 operationeel is. Hierdoor dient het testen, waarbij 2x FTE testers betrokken zijn, vóór 1 december 2009 afgerond te zijn. Opdrachtomschrijving: Organiseer & voer de systeemtest uit. Toon aan dat het CSSsysteem voldoet aan de opgestelde functionele- en performance eisen. Het traject heeft tot doel een vrijgaveadvies te geven t.a.v. het CSS-systeem. Hieruit moet ook blijken in hoeverre de doelen, die onder „Beoogde resultaat‟ zijn benoemd, gerealiseerd zijn/zullen worden.Op punten waar dit beoogde resultaat risico loopt zullen maatregelen worden voorgesteld voor reduceren van de oorzaak of het beperken van de impact. Hoe ga je om met de Pilot en GAT? Welk doel hebben die? Afgesproken rapportage:

Gedurende het testtraject zullen een aantal rapportages opgeleverd worden. Deze rapportages zullen in de DTP gedefinieerd worden. DTP zal naar verwachting over twee weken aan de heer Harmsma overhandigd worden. Wekelijks wordt er een voortgangsrapportage opgeleverd die vervolgens tijdens de wekelijkse bespreking aan de heer Harmsma mondeling toegelicht. Hierin zullen de volgende zaken aanbod komen:  De status van de deliverables (WBS, Planning, TRA & Testplan)

Merk op: Andere testsoorten die genoemd kunnen worden zijn bijvoorbeeld de Functionele acceptatietest, GAT en pilot, of zelfs een combinatie van deze. Als er meerder testsoorten in de resultaatomschrijving zitten zou er eigenlijk ook per testsoort het doel en de systeemgrens aangegeven dienen te worden. In dit geval zal waarschijnlijk de flitspaal geen onderdeel van het SUT zijn, tijdens een systeem testen. Berichten worden ingeschoten via een simulator. Bij de pilot is het logisch als de flitspaal wel meegenomen wordt. Een van de voor de hand liggende doelen van de pilot zou kunnen zijn, om aan te tonen dat er gedurende de pilot inderdaad minder klachten binnen kwamen. Dat is een doel dat moeilijk te testen is tijdens de ST. Dus ook de doelen zullen per testsoort enigszins verschillen. De resultaatomschrijving komt dus het beste tot zijn recht voor één testsoort.

40/164


7.3

41/159

Aantekeningen

Hoofdstuk - Testrisicoanalyse

8

Testrisicoanalyse

8.1

Algemeen

Voor het maken van de testboom kan goed free mind gebruikt worden. Dit is een freeware tool dat te downloaden is op: http://sourceforge.net/project/showfiles.php?group_id=7118&package_id=188772

Toelichting bij het toekennen van punten in de TRA Bij het toekennen van punten hebben de deel nemers wel eens moeite om onderscheid te maken tussen de functies en aandachtspunten. Ze hebben de neiging om alles belangrijk te vinden en het liefst geven ze alle items in de testboom 9 punten. Dit kan worden opgelost door de belanghebbenden een gelimiteerd aantal punten te geven. In het bovenstaande voorbeeld in het boek is dit toegepast. De deelnemers aan de sessie hebben maximaal 45 punten te verdelen over 12 risicogebieden. Er kunnen maar 5 x 9 punten worden uitgedeeld (verdeling 1). Wil de deelnemer meer dan vijf risicogebieden aanwijzen, dan wordt hij gedwongen ook minder hoge punten toe te kennen (verdeling 2). Mocht een deelnemer toch al zijn punten gelijk willen verdelen, dan kan dat (zie verdeling 3). Echter doordat er een maximum aantal punten toe te kennen is, minimaliseert hij zijn invloed op het totaal. Door de deelnemer hierop te wijzen, zal hij waarschijnlijk toch besluiten een andere verdeling toe te kennen.

8.2

Zelftoets

Vraag 1. Risico gebaseerd testen: de delen van software testen die grootste kans hebben op fouten, of waarbij de fouten de grootste impact hebben beter testen dan onbelangrijke delen. Test inspanning is gevarieerd per functie. Vraag 2. Risico gebaseerd testen wint aan populariteit vanwege:  toename complexiteit software  toename hoeveelheid software in consumentenelektronica. Anders gezegd, het kwaliteitsprobleem: het niet verlagen van foutintensiviteit (= aantal fouten per 1000 regels code)  kortere Time-to-Market Vraag 3. Voordelen van risico gebaseerd testen:  tijdbesparing. Deze tijd kan dan besteed worden voor het testen van cruciale functies  betere test resultaten. De delen die overall toegevoegde waarde hebben worden het beste getest.  In totaal minder tijd besteden aan testen [Discutabel] Vraag 4. 42/164


Als er niet risico gebaseerd wordt getest dan zullen alle functies even veel aandacht krijgen. Dus ook de onbelangrijke functies zullen mogelijk zwaar getest worden. Er is geen mogelijkheid om de volgorde waarin de testen uitgevoerd worden aan te passen aan het belang dat aan de testen gehecht wordt. Hierdoor kan het zijn dat als de testen vroegtijdig worden afgebroken, de belangrijke testen nog niet zijn uitgevoerd. Tevens kan het zijn dat er pas laat in de testrun inzicht onstaat in de kwaliteit van enkele cruciale functies. Vraag 5. In de regel zijn de volgende belanghebbenden betrokken bij een TRA:  Afnemers (gebruikers, businessmanagers/beheerders)  Bouwers (analisten, systeemontwerpers, programmeurs)  Projectverantwoordelijken (projectmanagers of opdrachtgevers) Vraag 6. 1D TRA is bruikbaar voor het bepalen van het relatieve belang van de verschillende onderdelen van het testobject.1D TRA is toepasbaar zodra er inzicht is in de functies en aandachtgebieden van het systeem (bv als er een systeemontwerp is opgesteld). Dus wanneer je weet uit welke functies het systeem bestaat (bijvoorbeeld de systeemspecificaties). Vraag 7. Een testboom is een mindmap die aangeeft welke functies en aandacht punten een systeem heeft. Het is een decompositie naar functies en aandacht punten. De testboom wordt binnen de TRA gebruikt voor het  controleren of alle functies en aandachtgebieden zijn geïdentificeerd en  het prioriteren van de risicogebieden. Vraag 8. De testboom wordt gebruikt als structuur voor het fysieke testontwerp. Hierdoor zijn resultaten gemakkelijk terug te leiden naar de TRA. Vraag 9. 2D TRA is bruikbaar voor het bepalen welke testen er uitgevoerd moeten worden en wanneer non-functionele kwaliteitsattributen getest moeten worden. Wanneer de organisatie voldoende discipline heeft om deze uitgebreidere vorm toe te passen en wanneer men beseft dat er risico‟s zijn die niet uit de testbasis af te leiden zijn. Vraag 10. Fishbone-diagram is weergave van verband tussen oorzaak en gevolg, met andere woorden het verband tussen die risicovormen. Deze wordt gebruik om voor elk van de gestelde doelen te herleiden welke gebeurtenissen dit doel bedreigen. Daarna kan voor elk van deze gebeurtenissen worden geschat wat de kans en de impact ervan is op het gestelde doel. Vraag 11. De TRA wordt daarnaast gebruikt voor de volgende zaken:  De TRA ondersteunt de keuze voor de toe te passen testontwerptechnieken.  Bij reviews en intakes kan op basis van de TRA worden besloten belangrijke onderdelen beter te reviewen dan de minder belangrijke.

43/159






Tijdens de testuitvoering wordt de TRA gebruikt om de volgorde vast te stellen waarin de testen uitgevoerd worden. Het is gebruikelijk om te beginnen met de belangrijkste testen. Dit vergroot de kans dat de belangrijkste bevindingen snel worden gevonden. Daarnaast heeft dit het voordeel dat als de testuitvoering vroegtijdig wordt afgebroken, de belangrijke testen zijn uitgevoerd. In de testrapportage wordt verwezen naar de risico‟s. Dit heeft als voordeel dat de testrapportage verhaalt over zaken die de belanghebbenden aanspreekt, namelijk de risico‟s voor het beoogde resultaat.

8.3

Opdrachten

Opdracht 1 1D TRA

Voordeel Vormt een checklist van functies

Nadeel Niet-ervaren deelnemers hebben neiging alles functies hoog te waarderen. Echter, dit kan worden voorkomen door :  Nogmaals noodzaak tot onderscheid maken benadrukken  Het totale aantal punten die kunnen worden toegewezen beperken

Is structuur voor fysieke testontwerp Gemakkelijk om over risico‟s te rapporteren naar belanghebbenden

Relatief eenvoudig te begrijpen en in te voeren

2D TRA

Geeft een overzicht van welke testen er uitgevoerd moeten worden. Geeft inzicht in de risico‟s die het beoogde resultaat bedreigen (een duidelijke relatie met resultaat) Gemakkelijk om over risico‟s te rapporteren naar belanghebbenden

Business management denkt vaak wel in risico‟s en resultaat, maar hoeft niet per se kennis te hebben van functies. Daarom sluit 2D beter aan bij hun beleving. Omdat de 1-D in principe gebaseerd is op de testbasis, gaat het mogelijk voorbij aan risico‟s die niet in de testbasis zijn geadresseerd.

Kost meer discipline en tijd. Is ingewikkelder en daarom moeilijker in te voeren.

44/164


Opdracht 2 Businessmanager: voldoen aan wettelijke verplichting  Termijn waarin het test en aanpassingen gedaan worden moet binnen 8 maanden zijn Beheerder: de instellingen  Instellingen  wat verandert er nog meer Programmeur: de onderdelen moeten nog steeds compatibel zijn met bestaande onderdelen Projectmanager: de hoeveelheid testen zullen in minder dan 8 maanden af moeten zijn. Opdracht 3 Factor Complexiteit van het onderdeel van het testobject

Omvang van het onderdeel van het testobject

Mate waarin er nieuwe onbeproefde technologieën worden gebruikt

Relaties met andere onderdelen

Kwaliteit van het bouwteam

Frequentie waarmee het onderdeel wordt gebruikt

45/159

Voorbeeld Wanneer de software te complex is zou het moeilijk zijn de oorzaak van de fout te traceren Bij het realiseren van Complexe systemen worden sneller fouten gemaakt. Het zou dan langer duren om de fout te traceren Bij grotere systemen geld in de regel dat ze hierdoor ook complexer worden. Het zou mogelijk zijn dat de nieuwe technologie faalt en daardoor de bron van de fout hier ligt en niet in de software. + Minder ervaring in de valkuilen van de techniek. Als een systeem veel verbanden heeft met andere onderedelen zou dit onderdeel vaak gebruikt worden m.a.g. een grotere faalkans Als de kwaliteit van het bouwteam niet goed genoeg is zou het ontwikkelen van software langer duren en meer kosten dan noodzakelijk, m.a.g. kleiner budget en minder tijd voor testen. Daarnaast zou ook de kwaliteit van de code ook minder zijn, m.a.g. hogere foutintensiteit. Voor een onderdeel dat vaak wordt gebruikt is het van cruciaal belang dat deze goed functioneert. De faalkans is hierdoor groter bij zulke onderdelen.


Opdracht 4 Op de langere termijn zou nu een TRA organiseren een tijden kostenbesparing zijn, omdat er gerichter kan worden gezocht naar zwakke punten in de software, waardoor het uiteindelijke testen sneller gedaan kan worden. De tijdsbesparing zit er o.m. in dat er geen tijdverloren gaat aan het grondig reviewen van de onbelangrijke onderdelen van de systeemdocumentatie, het specificeren van grondige testen voor onbelangrijke functies, bv door het gebruik van overbodig zware technieken, het uitvoeren van testen op functies die onbelangrijk zijn, het tegenhouden van de release terwijl de fout in een niet kritische functie zit. Opdracht 5 Definities: Conformiteittest = test met als doel aan te tonen dat een testobject conform de gestelde eisen werkt. Interoperabiliteitstest= test met als doel aan te tonen dat een testobject kan samenwerken met of aangesloten worden op andere systemen. De set van conformiteit- en interoperabiliteitstesten die vereist is voor een product kan afhankelijk zijn van de specifieke instellingen en configuratie van dat product. De selectie van de uit te voeren testen is dan niet per se gebaseerd op risico‟s. TRA speelt bij deze testen dus geen rol Opdracht 6 Er zijn verschillende testbomen mogelijk, onderstaande testboom is een voorbeeld van een mogelijke uitwerking. Het is een functionele decompositie waarbij de belangrijkste functies duidelijk te herkennen zijn. Hierdoor krijgen de belanghebbenden snel een gevoel bij de zaken die getest worden. Per functie is een uitsplitsing gemaakt naar sub-functies en aandachtspunten. Een aantal van de nonfunctionele eisen zijn aan de linkerkant opgenomen, zoals de Performance, Traceerbaarheid en besparing resources. Dit zijn dermate belangrijke punten dat deze een eigen plek hebben gekregen in de testboom. Ook deze items kunnen naar wens worden uitgesplitst naar sub-items.

46/164


In het boek wordt aangegeven dat aan de linkerkant de kwaliteitsattributen kunnen worden opgenomen. In het voorbeeld zijn niet zozeer de kwaliteitsattributen opgenomen maar wel een aantal van de business resultaten. Hier wordt dus feitelijk afgeweken van het boek. Dit punt kan worden aangegrepen om te accentueren dat: a) Het (een) methode volgen leuk is maar dat dit nooit blind moet gebeuren. Afwijken ervan is prima, zolang je maar bewuste keuzes maakt en deze kan uitleggen b) Dat binnen resultaatgedreven testen, het natuurlijk erg mooi is om als je de beoogde resultaten kent, deze in je testopzet terug te laten komen. Merk verder op dat:  De resultaten niet altijd zo duidelijk geformuleerd zijn als in de CSSspecificatie in de appendix, in dat geval is het voor de hand liggend om de kwaliteitsattributen te gebruiken  Door de kwaliteitsattributen of de beoogde resultaten op te nemen in de testboom deze in principe ook terug komen in de testrapportage (overzicht en inzicht)  Er in een testboom altijd overlap zal zitten. Om de performance te testen zul je functies gebruiken die ook in de rechter helft van de testboom staan. Hoe je de testboom indeelt, dit zal altijd wel het geval zijn.  In het boek zie je bij bepaalde takken in de testboom kleine rondjes staan. Deze betekenen dat er nog meer niveaus gedefinieerd zijn, maar dat deze zijn „ingeklapt‟. De onderliggende takken zijn dus niet zichtbaar.

47/159


Opdracht 7 Het inschatten van het risico verschilt natuurlijk per persoon. Bepaalde belanghebbenden zullen specifieke aandachtpunten hebben. Als verschillende studenten een TRA invullen zullen de uitkomsten verschillen. Ervaring leert dat er tussen de verschillende inschattingen ook vaak overeenkomsten zitten. Dit zijn logische keuzen, waaraan men blijkbaar dezelfde waarde hecht. Logische afwegingen zouden kunnen zijn: 

Automatische afhandeling is belangrijker dan handmatige, omdat er meer sancties via de flitspalen worden geregistreerd. Om dezelfde reden is de performance van de schermen minder belangrijk dan die van de automatische berichtafhandeling. Het testen van combinatie overtredingen heeft meer prioriteit dan de individuele overtredingen, omdat als er een fout in de individuele overtredingen zit, deze waarschijnlijk ook gevonden word in de combinatie. Batch verwerking is belangrijker dan handmatige verwerking omdat als de batch verwerking niet werkt er meer onverzonden beschikkingen achter blijven dan het geval is als de handmatige verwerking niet werkt. Er zullen naar verwachting meer sancties betaald worden, dan dat deze geseponeerd worden, deze laatste functie wordt dus minder grondig getest en komt lager uit op de TRA lijst. Naar verwachting is de situatie redelijk stabiel. Beheerfuncties staan daarom niet boven aan de prioriteiten lijst. Indien hier problemen mee zijn, kunnen deze eenmalig door technische experts worden opgelost, waarna de instellingen lang ongewijzigd blijven. Van de mogelijke instellingen is de tabel met sanctie tarieven het kansrijk om te worden gewijzigd (denk bijvoorbeeld aan de jaarlijkse inflatie correctie) De resourcebesparing en traceerbaarheid zijn van groot belang, omdat deze nauw aansluiten bij het beoogde resultaat. De vraag of dit resultaat behaald gaat worden, dient te allen tijde te worden beantwoord door de testresultaten.

    



Merk op bovenstaande afwegingen bevatten aannames die in een echte situatie natuurlijk getoetst dienen te worden. Een geheugensteuntje om te onthouden dat je altijd voorzichtig moet zijn met het maken van aannames is het volgende woordgrapje: To AssUMe, makes an Ass out of U (you) and Me. Dit geeft aan dat als jij een aanname maakt zonder deze te verifiëren, noch jij, noch ik er beter van worden.

Onderstaand een mogelijke uitwerking van een de TRA:

1 2 3 4 5

functie Scherm performance Bericht performance Traceerbaarheid Betaalstatus bijhouden Besparing portokosten

verdeling 5 9 9 5 9 48/164


6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Besparing klachtafhandeling Handmatig registreren Automatisch registreren Opvragen voertuigregistratie Berekening snelheidsovertreding Berekening roodlichtrijdersovertreding Berekening combinatie overtreding Opvraging registratie Batch verzending Enkelvoudige verzending Sanctie wijzigen Sanctie seponeren Sanctie tarieven beheren Directory inquiry beheren Emailadres financiële afdeling Foutafhandeling kenteken NAW onbekend Foutafhandeling bij sanctie te laag Foutafhandeling bij betaling komt niet overeen Foutafhandeling bij Registratie informatie

9 3 5 1 3 3 5 1 5 1 3 1 3 1 1 1 1 1 1 1

Opdracht 8 De drie mogelijkheden zouden kunnen zijn:  Fouten in de verwerking, waardoor de overtredersDB, waaruit alle administratie uit verder wordt gedaan, gecontamineerd raakt  Fouten in zendingen, waardoor de klachten stroom zal toenemen.  Handmatig invoeren, waardoor de sancties niet goed worden opgevolgd en de sancties niet worden verhoogd. Een ander risico is de klachtafhandeling, hiervoor is de onderstaande fishbonediagram opgesteld:

Opdracht 9: Afhankelijk van de antwoorden bij vraag 8 zal de uitwerking van deze opgave verschillen. Inzichten die deze opgave moet leveren zijn

49/159


-

Dat er enerzijds op basis van common sense best het een en ander te roepen valt over mogelijke risico‟s, maar...

-

Dat anderzijds er achtergrond informatie nodig is om de impact en kans te bepalen van elk van de gebeurtenissen in het fishbone-diagram. Deze informatie kan in de praktijk worden gezocht binnen de organisatie, maar een andere mogelijkheid is het betrekken van belanghebbenden die deze kennis paraat hebben als gevolg van hun functie.

-

Dat verschillende belanghebbenden vanuit hun verschillende achtergrond de accenten op andere punten zullen leggen.

-

Dat de 2-D TRA tot verschillende testen zal leiden dan de 1D-TRA. En dat deze complementair zijn.

50/164


8.4

51/159

Aantekeningen

Hoofdstuk - Begroten en Plannen

9

Begroten en Plannen

9.1

Algemeen

De WBS om thee te drinken in figuur 9.1 kan nog verder worden uitgebreid en verbeterd. Een onvolledigheid is bijvoorbeeld de volgende: Als een schoon glas uit de kast gepakt wordt, moet dit na het drinken misschien ook schoongemaakt worden. Deze activiteit kost ook tijd en geld en moet dus ook op de Begroting gezet worden. Deze en andere onvolledigheden kunnen door de docent worden gebruikt om de link te leggen met het beoogde resultaat en de afbakening zoals deze zijn vastgelegd en besproken in de resultaat omschrijving. Ervaringen leert dat ondanks de zorgvuldigheid waarmee je deze opstelt, er altijd aspecten naar boven zullen komen, waar nog niet aan gedacht is. Communicatie met de opdrachtgever zal hier vaak nodig zijn om de afbakening van de opdracht, en wat er dus in de planning staat, af te stemmen.

9.2

Zelftoets

Vraag 1. Een begroting is een inschatting van hoeveel het budget zou moeten zijn om het beoogde resultaat te behalen. Een planning is de inschatting van hoeveel tijd nodig is om een project uit te voeren. Vraag 2. Een mijlpaal is een punt waarop de voortgang van het testtraject duidelijk kan worden vastgesteld. Een mijlpaal valt meestal samen met een fase in de productie. Als het product is afgerond is dan ook de laatste mijlpaal bereikt. Vraag 3. De Estimated Time to Completion (ETC) is de schatting voor hoeveel tijd nodig is om het project, of een activiteit af te ronden. Vraag 4. WBS staat voor een Work Breakdown Structure. Dit is een specificatie van de activiteiten die uitgevoerd moeten worden om een doel te bereiken. Vraag 5. De voordelen van een WBS zijn:  Hoofdactiviteiten worden overzichtelijk weer gegeven  Verdere opsplitsing van de hoofdtaken worden inzichtelijk weer gegeven  Levert veel vragen die noodzakelijk zijn voor opheldering van onvolledigheden in het ontwerp  Dus ook goed voor afbakenen van de taken. Vraag 6. De manieren om de begroting te controleren zijn:  Peer review, meelezer.  Onafhankelijke inschatting, vergelijken van meerdere beoordelingen 52/164


 

Ervaringscijfers uit eerdere vergelijkbare projecten Statistiek uit andere rapportages

De kracht van een onafhankelijke inschatting [Intermediair 2008] Vraag 7. De volgende metrieken worden genoemd:  Aantal pagina‟s per uur  Aantal testgevallen per use case  Aantal testgevallen per use case per uur Vraag 8. Het verschil is dat in de resultaatomschrijving de begroting staat die de klant heeft gemaakt en in de testbegroting staat wat het volgens het testteam zou kosten om het project tot een succes te brengen

53/159


Vraag 9. Een extra metriek die ook gebruik zou kunnen worden is:  Het aantal regels scriptcode per tijdseenheid, aantal testgevallen per categorie per tijdseenheid. Vraag 10. Omdat de globale planning zelden in 1 keer goed wordt gekeurd. Het is efficiënter als de globale planning is goedgekeurd alvorens de gedetailleerde planning wordt opgemaakt, aangezien de gedetailleerde planning veel werk kan zijn.

9.3

Opdrachten

Opdracht 1: Er zijn verschillende goede work breakdown structures mogelijk. Merk op dat de uitwerking sterk afhangt van de insteek die gekozen wordt. Bijvoorbeeld „Ik pak een teiltje met water en ga zelf het lek vinden‟ zoals hieronder is uitgewerkt, maar ook „ik loop naar de fietsenmaker en koop een kaartje voor de bus naar huis‟ De invulling van de WBS hangt blijkbaar af van aannames die onbewust genomen worden. Belangrijk is dat het stappenplan en de WBS gebruikt kan worden om de volledigheid te controleren (dit staat in de tekst), maar ook om te stemmen met de opdrachtgever of jouw aannames de goed zijn. Als de keuze maken om het lek zelf te repareren, ziet de WBS er als volgt uit:

54/164


Opdracht 2: Onderstaand overzicht berekent de kosten per week voor de situatie met en zonder de extra tester. Gegevens Gemiddelde Uurtarief Ontwikkel kosten Testsimulator Licentie tool Huur testomgeving Uren testers Aantal testers in het team Uurtarief extra tester Uren extra tester

Kosten zonder extra tester Week Gemiddelde Urenkosten testteam Uurtarief extra tester Ontwikkelkosten Testsimulator

55/159

85 Euro/uur 3000 Euro eenmalig 150 Euro /gebruiker per 4 weken 100 Euro/week 80 uur/week gelijk aan: 2 3

Fte

100 Euro/uur 36 uur/week

1 6800 0 3000

2 6800 0

3 6800 0

4 6800 0

5 6800 0

6 6800 0


Licentie tool Huur testomgeving Totaal Cumulatief

450 100 10350 10350

Kosten met extra tester Week Gemiddelde Urenkosten testteam Uurtarief extra tester Ontwikkelkosten Testsimulator Licentie tool Huur testomgeving Totaal Cumulatief

1 6800 3600 3000 600 100 14100 14100

Kostenbesparing van 6-4 weken: Zonder extra tester Met extra tester



100 6900 17250

100 6900 24150

100 6900 31050

450 100 7350 38400

100 6900 45300

2 6800 3600

3 6800 3600

4 6800 3600

5 6800 3600

6 6800 3600

100 10500 24600

100 10500 35100

100 10500 45600

600 100 11100 56700

100 10500 67200

45300 45600 -300

45300 56700 -11400

45300 67200 -21900

Opdracht 3: De extra kosten ten gevolge van de extra tester is minimaal, slecht 300 euro. De niet financiële argumenten zullen daarom de doorslag geven. Argumenten om op te voeren kunnen zijn:  De time-to-market wordt verkort, dit is belangrijk voor de organisatie  Het is natuurlijk niet zeker dat de testtijd ook werkelijk wordt verkort, de kosten nemen sterk toe als het project niet 4 maar 5 of 6 weken duurt  Het aansturen van een groter team levert ook extra problemen op  Bottleneck is mogelijk niet het aantal testers, maar het grote aantal problemen met de testomgeving, hierdoor zitten de testers vaak te wachten in plaats van te testen. Een extra tester zit dus ook meer te wachten. Het is verstandiger om het probleem met de omgeving eerst op te lossen.  Bottleneck is mogelijk niet het aantal testers, maar de tijd die ontwikkelaars nodig hebben om de fouten op te lossen. Een extra tester zorgt voor meer gevonden fouten per week, maar de ontwikkelafdeling heeft nu al moeite met het verwerken.

56/164


Kortom er is niet één goed antwoord, maar een groot aantal niet financiële factoren die kunnen meespelen. Opdracht 4: Andere begrotingstechnieken en planningstechnieken die niet in het TestGoal boek zijn opgenomen zijn (zie o.m. [Pinster, 2004]): Top-down Bij een top-downbenadering wordt het totaal benodigde aantal uren voor het project vastgesteld door het project te vergelijken met andere projecten. Nadat het totale aantal uren is geschat worden deze verdeeld over de onderliggende stappen. Deze techniek werkt goed als er weinig bekend is over het project (bijvoorbeeld tijdens de allereerste opzet) en levert een goede initiële planning op. Echter de testmanager moet rekening houden dat de planning waarschijnlijk bijgesteld dient te worden als meer detail informatie beschikbaar komt. Bottom-up (WBS) Besproken in het TestGoal boek Fixed Budget Bij Mixed budget is het aantal uren al vastgesteld, de eisen en doelen zijn dan in principe nog niet echt vastgesteld. De testmanager rekent terug vanuit het vastgestelde budget en kijkt wat hij binnen deze grenzen kan doen. Daar waar hij de doelen naar beneden bijstelt, of minder goed test dan was voorzien, geeft hij dit duidelijk aan aan de opdrachtgever. Wideband Delphi: Een testbegrotingstechniek die tot doel heeft om met behulp van de collectieve ervaring van de teamleden een nauwkeurige begroting te maken. Hierbij stellen verschillende partijen een begroting op en worden de verschillen tussen de verschillende begrotingen besproken. Er kan een afspraak gemaakt worden om alleen die punten te bespreken die x % uit elkaar liggen. Deze techniek lijkt sterk op de in het boek omschreven controlemaatregel „onafhankelijke inschatting‟ en is een verdere verfijning van de in het boek omschreven WBS techniek.

57/159


Een artikel op Wikipedia geeft een overzicht van de verschillende stappen van Wideband Delphi: 

  

 

Choose the team. The project manager selects the estimation team and a moderator. The team should consist of 3 to 7 project team members. The team should include representatives from every engineering group that will be involved in the development of the work product being estimated. Kickoff meeting. The moderator prepares the team and leads a discussion to brainstorm assumptions, generate a WBS and decide on the units of estimation. Individual preparation. After the kickoff meeting, each team member individually generates the initial estimates for each task in the WBS, documenting any changes to the WBS and missing assumptions. Estimation session. The moderator leads the team through a series of iterative steps to gain consensus on the estimates. At the start of the iteration, the moderator charts the estimates on the whiteboard so the estimators can see the range of estimates. The team resolves issues and revises estimates without revealing specific numbers. The cycle repeats until either no estimator wants to change his or her estimate, the estimators agree that the range is acceptable or two hours have elapsed. Assemble tasks. The project manager works with the team to collect the estimates from the team members at the end of the meeting and compiles the final task list, estimates and assumptions. Review results. The project manager reviews the final task list with the estimation team

[http://en.wikipedia.org/wiki/Wideband_delphi] Opdracht 5: Zie onder meer het T-map [Pol,1999]. Functiepuntenanalyse Dit is een methode om de functionele omvang van een informatiesysteem te meten door te kijken naar de relevante functies en gegevens van het systeem. Deze methode is gericht op het informatiesysteem en kan heel goed toegepast worden tijdens een systeemontwikkeling project. Testpuntenanalyse Met behulp van deze methode wordt op basis van de omvang van het informatiesysteem en van het testscenario een begroting gemaakt voor de testen. De omvang van het systeem wordt bepaald aan het aantal testpunten. Het bepalen van testpunten is vergelijkbaar met het bepalen van functiepunten. De scope van de testpunten analyse is in principe de blackboxtesten. Met deze twee analysemethoden heeft men een inschatting van de grootte van het project en de kosten voor het project. Voordeel is dat er een persoonsonafhankelijke inschatting wordt gemaakt op basis van ondermeer het functioneel ontwerp, logisch datamodel en functiepuntentelling. Nadeel is dat deze onderdelen aanwezig dienen te zijn en van voldoende kwaliteit. In veel organisaties is er geen functiepuntenanalyse. Tevens is het een abstracte en

58/164


mathematische aanpak die moeilijk uit te leggen is, veel discipline vergt en de nodige tijd kost. Dus niet geschikt binnen elke organisatie.

59/159


9.4

Aantekeningen

60/164


10

Testplan

10.1

Zelftoets

Vraag 1. Een testplan is het plan van aanpak voor een test traject. Het testplan heeft tot doel te omschrijven op welke wijze het testen ingericht gaat worden en hoe dit bijdraagt aan het resultaat. Het plan wordt vaak gebruikt als middel om de teststrategie concreet te maken, om deze bespreekbaar te maken en om de aanpak te kunnen delen met anderen zodat iedereen hetzelfde doel nastreeft. Vraag 2. Het verschil tussen een MTP (Master Test Plan) en een DTP (Detail Test Plan): MTP DTP Niveau Strategisch niveau Gedetailleerd niveau Aantal testsoorten Behandelt meer dan 1 test Behandelt 1 test soort soort Inhoudelijk Is de vertaling van de Gaat in op een specifieke algemene teststrategie naar testsoort een testaanpak voor alle (ergo de vertaling van het testtrajecten binnen het MTP naar een testaanpak voor project een van de testtrajecten binnen het project Wordt opgesteld testmanager testcoördinator door Vraag 3. De teststrategie maakt duidelijk hoe het beoogde resultaat vertaald kan worden naar de manier waarop er getest wordt. Vraag 4. In de teststrategie staat:  Welk resultaat wordt nagestreefd  Welke testen worden uitgevoerd  Hoe rekening gehouden wordt met de risico‟s  Hoe de aansluiting bij het softwareontwikkelproces en de ontwikkelmethode is geregeld  Welke voordelen de gekozen strategie heeft  Hoe de kwaliteit van het proces gewaarborgd blijft Vraag 5. Kwaliteitsattributen zijn een collectie van eigenschappen waarmee de kwaliteit van een goed systeem worden gedefinieerd. De ISO 9126 standaard is de bekendste set van kwaliteitsattributen. In het Quint model is ISO 9126 uitgebreid met een aantal extra Attributen.

61/159

Hoofdstuk - Testplan

Voordeel van het gebruik van kwaliteitsattributen is dat het kwaliteit beter begrijpbaar en bespreekbaar maakt. De belanghebbenden kunnen aan de hand van Quint of ISO aangeven welke attributen echt belangrijk zijn, en dus tijdens het testen meer aandacht verdienen. Vraag 6. Om een review toegankelijker te maken kun je;  Reviews delen in kleinere sessies  Review taken verdelen onder de reviewers  De TRA gebruiken om de grondigheid van de reviews te variëren  De reviewer een specifieke scope geven.

10.2

Opdrachten

Opdracht 1. Om de opdrachtgever te overtuigen van het gebruik van een testplan geef je de volgende argumenten: 

 

Effectiviteitsaspect: Zonder plan onstaat het risico dat functies dubbel getest worden of erger nog, over het hoofd gezien worden en helemaal niet getest worden. Dit levert mogelijk problemen op als het systeem wordt gebruikt in productie. Daarnaast voorkomt een goede teststrategie (zoals deze is opgenomen in het plan) dat onbelangrijke functies te uitvoerig getest worden, en belangrijke functies op de verkeerde manier getest worden. Kwaliteitsaspect: Zonder plan is het onduidelijk en moeilijk communiceerbaar wat en hoe er getest moet worden en met welke risico‟s rekening mee gehouden moeten worden. Financieel aspect: als functies dubbel getest worden, of onnodig zwaar, duurt het testtraject onnodig lang en wordt het project onnodig duur.

Kortom: 1) Efficiëntie en kosten: de voorbereiding verdient zich terug door een betere aanpak waarbij er geen zaken dubbel getest worden, geen onnodige zaken getest worden en er geen tijd verloren gaat met het onnodig grondig testen van minder risicovolle gebieden. 2) Bijdrage aan het resultaat: De strategie is per definitie een vertaling van beoogd resultaat naar testaanpak. Het plan zorgt ervoor dat er niet zomaar getest wordt, maar dat testen een bijdrage leveren aan het beoogde resultaat, en inzicht geven in de mate waarin het te ontwikkelen systeem het beoogde resultaat ondersteund. 3) Overzicht en inzicht geven: het plan geeft aan welke aanpak gehanteerd en biedt daarmee de structuur voor de testrapportage. Dit maakt duidelijke rapportage mogelijk en help bij te dragen aan het vertrouwen dat de belanghebbenden hebben in het product en maakt het mogelijk voor het projectmanagement om het ontwikkelproject bij te sturen als op grond van de rapportage blijkt dat dit nodig is. Opdracht 2. a) Inhoudsopgave testplan:  Opdrachtformulering 62/164


      

Teststrategie, met een omschrijving van de testaanpak TRA Testomgeving Vrijgaveadvies Planning Testorganisatie (organogram) Benodigdheden

b) bovenstaand elementen zijn niet uit het testplan verwijderd omdat ze noodzakelijk zijn voor het bepalen van welke en hoe de testen uitgevoerd dienen te worden, om het gestreefde resultaat na te behalen, terwijl er rekening gehouden wordt met de risico‟s en de kwaliteit van het proces gewaarborgd kan worden. Merk op dat afhankelijk van de organisatie en het project andere onderdelen belangrijker kunnen worden. Een paar voorbelden:  In een kleine overzichtelijk projectomgeving heeft het opnemen van een organogram misschien niet veel toegevoegde waarde. In een complex omgeving echter wel.  Als er formeel getest wordt, of als er aangetoond dient te worden dat er afdoende getest wordt, zal het raadzaam zijn om aan te geven hoe bepaalde testtechnieken gebruikt worden en welke kwaliteitsattributen wel of niet met testen geraakt worden.  Als de organisatie erg veel belang hecht aan het investeren in testkennis, maar het daarbij belangrijk vindt dat deze ook goed geborgd wordt in de organisatie, is het raadzaam om toch iets te roepen over de overdracht.  In een „blame-cultuur‟ doet de testcoördinator zich er goed aan om de afbakening van de testopdracht goed te formuleren en de verantwoordelijkheden duidelijk vast te leggen, bv aan de hand van een RACI-chart. c) Omdat het een klein project betreft van 1,5 week, zou het plan in één tot anderhalve dag gemaakt moeten zijn. Onderstaande planning geeft aan dat dit inderdaad het geval kan zijn. Ongeveer de helft van de tijd wordt besteed in  het bedenken en bespreken van de testaanpak, en  zorgen dat de belanghebbenden deze aanpak kennen en ermee akkoord gaan. Deze activiteiten zijn ook nodig als er geen plan gemaakt wordt, maar de uitkomsten worden dan niet vastgelegd. onderdeel Opdrachtformulering teststrategie

Omschrijving testaanpak TRA Testomgeving Vrijgaveadvies

63/159

Uren opmerking 0,5 Is al gemaakt tijdens stap 1 Resultaat 4 Kost relatief veel tijd, omdat er overleg nodig is met de betrokkenen. 0,5 Is al gemaakt tijdens voorgaande activiteit 1 1

Hoofdstuk - Testplan

Planning Testorganisatie Benodigdheden Accorderen Totaal

Organogram

2 0,5 1 2 12,5

Opdracht 3. De volgende omschrijvingen geven aan hoe systeemkennis, de review bevindingen op de testbasis en de leerpunten overgedragen zouden kunnen worden:

Systeemkennis Omschrijving:

Ontvangende partij: Wijze van overdracht: Moment van overdracht:

Het testteam heeft geleerd met het systeem te werken. De bevindingen over de werking van het systeem, maar ook over de eigenaardigheden ervan, zullen worden overgedragen aan het deelproject implementatie. De trainers kunnen de kennis gebruiken ten behoeve van een praktische systeemintroductie. Projectleider/trainer van het deelproject Implementatie Review van de training en bespreking voorafgaand hieraan. Bij aanvang van de ontwikkeling van de training

Review bevindingen testbasis Omschrijving: De issuelijst met daarin de bevindingen die gedaan zijn met betrekking tot de testbasis wordt opgeleverd aan het analistenteam. De informatie kan worden gebruikt om de testbasis van toekomstige projecten te verbeteren. Ontvangende partij: Teamleider analisten. Wijze van overdracht: De reviewlog testbasis wordt regelmatig uitgewisseld en besproken. Moment van Op gezette tijden gedurende het hele testtraject. overdracht: Leerpunten Omschrijving: Ontvangende partij: Wijze van overdracht: Moment van overdracht:

Tijdens de evaluatie worden de leerpunten geborgd in het leerpuntenrapport. Manager testafdeling, Testmanager Leerpuntenrapport wordt overgedragen. De ontvangende partij is aanwezig tijdens de evaluatiesessie. Tijdens de laatste stap van het project (borging).

Opdracht 4. Kijk op www.testgoal-eductief.nl voor een template met invul instructie van een testplan.

64/164


10.3

65/159

Aantekeningen

Hoofdstuk - Intake Testbasis

11

Intake Testbasis

11.1

Zelftoets

Vraag 1. De testbasis is de totaalverzameling van documenten en systeembeschrijvingen die definiëren waaraan het testobject moet voldoen. Vraag 2. De intake testbasis wordt uitgevoerd voordat het testteam het testontwerp gaat maken. Tijdens de intake wordt een inschatting gemaakt of de kwaliteit en de bruikbaarheid van de door de analisten aangeleverde specificaties voldoende is. Is dit het geval, dan kan de testbasis dienen als uitgangspunt voor de af te leiden testgevallen. De producten van de Intake testbasis zijn  Een ingevulde checklist met daarin – Conclusie: Een uitspraak over de kwaliteit en bruikbaarheid van de testbasis. – Maatregelen: Als de testbasis niet voldoet, is aangegeven op welke punten deze onvolledig is. Per punt wordt aangegeven wat de risico‟s zijn voor het testontwerp en de planning en welke maatregelen er nodig zijn om deze risico‟s af te dekken.  Geregistreerde reviewbevindingen Vraag 3. Als je testbasis onvolledig is moet per missend punt aangegeven welke risico‟s daaraan gekoppeld zijn voor het testontwerp en de planning en de maatregelen nodig zijn om deze risico‟s af te dekken. Zie tabel 11.1 voor voorbeelden. Vraag 4. Het antwoord is te vinden in tabel 11.1. Als de testbasis veel fouten of onduidelijkheden bevat, ontstaan de volgende risico‟s  Er is onduidelijkheid over gewenst resultaat  Er is een grote kans op wijzigingen in de specificaties  Er is een grote kans op fouten in het systeem. Vraag 5. De review richt zich ook op de reeds aanwezige testware. Zo wordt onder meer vastgesteld in welke mate de beschikbare testen herbruikbaar zijn. Heeft het testteam al met het testontwerp gewerkt, dan is waarschijnlijk al bekend wat de detaillering of kwaliteit van het testontwerp is. In dit geval kan de review zich beperken tot de vraag hoe actueel het ontwerp is en of alle systeemwijzigingen in het testontwerp zijn doorgevoerd. Is er geen kennis van en ervaring met het gebruik van het testontwerp, dan zal deze grondig moeten worden gereviewd om verrassingen bij het uitvoeren van de testen te voorkomen. Vraag 6. 66/164


Tijdens de intake testbasis kan de TRA vooraf informatie bieden t.a.v. de belangrijke functies. Belangrijke functies zullen beter gereviewd worden dan de minderbelangrijke functies. Vraag 7. De checklist zorgt ervoor dat er geen zaken vergeten worden. Checklijsten helpen de tester met het beoordelen van de testbasis, omdat de checklist aangeeft waar de tester op moet letten. Het gebruik van checklists stelt daarnaast de organisatie in staat om opgedane kennis optimaal te hergebruiken, op het moment dat checklists worden aangepast met de laatste ervaringen en inzichten. Door het gebruik van checklists ontstaat er ook een standaard controle, die tot een meer stabielere en voorspelbare kwaliteit van de testbasis leidt. Alle projecten worden immers op dezelfde manier beoordeeld.

11.2

Opdrachten

Opdracht 1. Er is niet gespecificeerd wat er gebeurd als er een tegelijk een snelheiden roodlicht overtreding optreed. Er is wel een =3 gedefinieerd, maar deze komt niet terug in de specificatie van de overige elementen. Dit heeft tot gevolg dat onduidelijk is hoe deze combinatie moet worden afgehandeld, risico bestaat dat het systeem niet beide sancties berekend, maar er slechts één of zelfs geen verwerkt. De is optioneel. Onduidelijk is hoe de overtreding berekend wordt als deze waarde niet gevuld is. Omgekeerd, als deze waarde redundant is, is niet duidelijk hoe deze waarde gebruikt wordt, als deze wel is ingevuld. Het risico bestaat dat de sanctie niet berekend kan worden, of berekend wordt op basis van verkeerde gegevens. De is conditioneel. Er is niet aangegeven wat de condities zijn. Hierdoor is niet te testen of het leeg laten van de velden wordt gedetecteerd als dit niet toegestaan is, het is niet te testen dat het proces goed verloopt als dit wel toegestaan is. Opdracht 2. De sanctie is berekend conform de volgende formule: Overtreding = Gemeten snelheid + Correctie - Toegestane snelheid. De correctie dient van de gemeten snelheid te worden afgetrokken in plaats van opgeteld. Deze fout zal leiden tot een aantal onterechte beschikkingen en hogere sancties. De en worden ingevoerd. De correctie is niet aangegeven. Onduidelijk is welke correctie gehanteerd dient te worden bij de testen. Er zit een fout in de grenswaarden: „0< Overtreding <10 km/u‟ en „10< Overtreding <40 km/u‟ neemt de snelheden 10 km/u en 40 km/u niet mee. Onduidelijk is bij welke sanctie deze snelheden horen, dit is dus niet te testen. Risico bestaat dat in de implementatie voor deze specifieke snelheiden geen sanctie berekend wordt. Opdracht 3.

67/159


a)

De checklist in de bijlage van het boek (of www.testgoal-educatief.nl) kan als volgt worden ingevuld:

Checklist Testbasis: Ontwerp Resultaat Naam Het geheel aan functionaliteit, processen en hun coherentie is voldoende beschreven Het geheel aan functionaliteit, processen en hun coherentie is consistent met het beoogde resultaat Alle relevante kwaliteitsattributen zijn afdoende behandeld.

J/N J

Uitkomsten van de risicoanalyse zijn traceerbaar verwerkt in de testbasis.

N

N.v.t.

Oplossingen

J N

Er is niet aangegeven welke kwaliteitsattributen belangrijk zijn. Er is niet aangegeven welke risico‟s erkent zijn.

Controle Naam Bevat historielog (incl. versiebeheer) Bevat goedkeuring /distributielijst Bevat documentbeschrijving (incl. auteur) Document heeft een status Bevat referentielijst

J/N N N N N N

N.v.t.

Oplossingen

J/N N J J J

N.v.t.

Oplossingen

Structuur Naam Bevat managementoverzicht Bevat tabel met inhoud (actueel) Bevat een inleidend hoofdstuk Bevat hoofdstuk(ken) met overzicht/beschrijvingen van de functionaliteiten (en bijbehorende schermen/ rapporten) Bevat hoofdstuk(ken) met datamodellen en databeschrijvingen Bevat hoofdstuk(ken) met functie specificatie Bevat hoofdstuk(ken) met interface specificatie

N

Datamodel ontbreekt, datadefinitie is aanwezig

J J

Inhoud Functioneel Bevat systeem overview  Systeem beschrijving  Doel van het systeem, wat hebben de gebruikers er aan en hoe ondersteunt het hun business processen (hoog niveau)  Scope diagram / systeem diagram  Systeemomgeving en -afhankelijkheden  Eigenaren van het systeem, beiden functioneel en technisch

J/N

N.v.t.

Oplossingen

J J

J N N J 68/164




Locaties waar het systeem wordt geïmplementeerd

Het systeem bevat verscheidene subsystemen  Voor elk subsysteem: een korte beschrijving met basis functionaliteiten, processen en bijbehorende data  Grenzen van / tussen subsystemen  Relaties tussen subsystemen  Mogelijk relevant: interfaces tussen subsystemen Kwaliteitsattributen  De relevante kwaliteitsaspecten zijn aangegeven voor het hele systeem  De relevante kwaliteitsaspecten zijn aangegeven per subsysteem Bevat workflow / process flow / state transition diagrammen of anderen  Beschrijving  Vermeld acties, condities en situaties  Acties, condities en situaties zijn uitgeschreven Bevat use case (UC)  Use case beschrijving  Use case diagram (UCD)  Connectie tussen UCD en relevante bedrijfsprocessen  Bevat auteurs  UCD bevat grenzen  UCD bevat primaire en secondaire UC  Connectie tussen UC en functionaliteit  UC bevat primair scenario, alternatief scenario en fallback scenario Bevat scherm informatie  Scherm Layout  Scherm / Systeem Navigatie  Input / Output informatie Bevat rapportinformatie  Rapportbeschrijving  Parameters  Velden  Groepering en sortering  Rapport layout  Inhoud Data Model en Data Beschrijving Bevat een grafisch model (ERD) Bevat een beschrijving van de entiteiten  Entiteit definitie: een heldere en ondubbelzinnige definitie van het begrip entiteit  Attribuut definitie: een heldere en ondubbelzinnige definitie van elk attribuut van de entiteit. Inclusief een verwijzing naar een domein of beschrijving van data type, lengte en toegestane waarden  Primary en foreign keys: de attributen die de (gerelateerde) entiteiten identificeren  Hoeveelheden: minimaal, gemiddeld en maximaal aantal entiteiten en growth rate per periode Bevat een beschrijving van relaties  Naam: van de relatie en de inverse relatie  Cardinaliteit: hoeveel entiteiten zijn gelinkt met de relaties

69/159

J N J N

N N

J J N X

J J J

Maar niet van elk scherm

X

J/N

N.v.t. X X

X

Oplossingen




Optie: de mate waarin de relatie verplicht is of optioneel voor de entiteiten van de relatie  Constraints: zijn de regels vastgelegd die vaststellen hoe het systeem zou moeten gedragen conform de cardinaliteit en mogelijkheden binnen de relaties? Bevat een beschrijving van domeinen  Naam  Data type en lengte  Toegestane waarden Bevat een beschrijving van constraints Bevat een beschrijving van regels Bevat een beschrijving van bewaarde procedures Bevat een beschrijving van triggers Bevat een beschrijving van defaults

X

X X X X X

Systeem Interfaces Bevat de naam van de interface; bijvoorbeeld Bevat een beschrijving van het doel Bevat een workflow / schema / diagram Bevat details van het proces Bevat details van de direction Bevat beschrijving van het type interface: operationeel/ data / batch / online Bevat gedetailleerde informatie van het formaat van de interface: structuur, data-elementen, data types, lengte, toegestane waarden Bevat beschrijving van error handling Bevat beschrijving van error logging Bevat beschrijving van constraints

J/N J

N.v.t.

Oplossingen

Functie Specificaties Bevat naam van de functie Bevat doelstelling Bevat proces informatie Bevat Input / Output information Bevat beschrijving van de data verwerking Bevat beschrijving van calculatie functionaliteit Bevat beschrijving van constraints (input checks) Bevat beschrijving van error handling

J/N J J J J J J J J

N.v.t.

Oplossingen

Autorisatie Beschrijving van vereiste autorisatie (profielen) Bevat autorisatiematrix

J/N N N

N.v.t.

Oplossingen

Technische Architectuur Beschrijving en/of schema's van de infrastructuur b.v. netwerk, servers, DBMS, besturingssystemen, middleware Beschrijving van technische aspecten van interfaces

J/N

N.v.t. X

Oplossingen

b)

J J J J J J

J J N

De conclusie is dan als volgt:

Conclusie Conclusie De specificatie (testbasis) is voldoende nauwgezet beschreven om een gestructureerd testtraject op te starten

J

/ N X

70/164


Conclusie binnen de context van de ontwikkelaanpak Merk op dat deze conclusie een enigszins traditionele werkwijze verraad. Immers bij een waterval aanpak zal er uitgegaan worden van een uitgebreid ontwerp. Bij een Agile aanpak is het systeemontwerp vaak minder uitgebreid en zal de specificatie van het CSS misschien wel als ruim voldoende worden aangeduid. De conclusie dient daarom altijd in context gezien met de gekozen ontwikkeltechniek en de daarbij aansluitende teststrategie. Dit geldt ook voor de voorgestelde maatregelen. Bespreek met de opdrachtgever welke risico‟s je ziet en zoek samen naar een maatregel die werkt. Bij opgave C zie je daarom steeds maatregel in de vorm van „maak de specifcatie beter‟ en een alternatief „zorg dat de informatie bekend wordt bij de betreffende personen‟.

c)

Met de volgende toelichting en voorstellen:

Indien Conclusie negatief: Onderstaand zijn op algemeen niveau zijnde bevindingen van de intake aangegeven. Per punt wordt aangegeven wat risico‟s zijn voor het testontwerp en welke activiteiten er nodig zijn om deze af te dekken. Bevinding Geen Controle en versie informatie Het belang dat aan verschillende kwaliteitsattributen gehecht wordt is niet aangegeven in de specificatie.

Risico Laag; dit kan voor verwarringen veroorzaken Hoog; Kwaliteit van de testware kan niet voldoende weergegeven worden

Detaillering is laag, Technische specificaties zijn niet beschreven

Hoog; Vrijheidsgraden in de specificaties kunnen de „fit for purpose‟ in gevaar brengen

Maatregelen Document versie, auteurs etc. Opnemen in document Neem op welke kwaliteitsattributen belangrijk zijn, verwijs het document waar dit vastgelegd is, of organiseer een sessie met belanghebbenden om vast te stellen dat het ontwerp alle belangrijke attributen beschrijft. Stel Technische specificaties op of richt het ontwikkelproject zodanig in dat de implicaties van technische keuzes tijdens de implementatie worden getoetst met de belanghebbenden.

Aanvullend kunnen de ondermeer volgende onvolkomenheden opmerkt worden: 

Het is niet mogelijk om automatisch vastgelegde snelheidsovertredingen waar geen sancties op staan te verwijderen.



De initiële status van de sancties wanneer die automatisch ingevoerd worden. De status wordt niet actief omgezet tot „Geregistreerd‟, zoals bij de handmatige invoer wel het geval is. Dit heeft geen effect op de verdere uitvoer van het systeem. Het doel van het systeem is het registreren van overtredingen. Hierbij dan ook de notitie dat het veranderen van de status bij handmatige invoer dan ook redundant is.

71/159




De datadefinitie geeft aan dat een aantal velden optioneel of conditioneel zijn. Er is niet duidelijk aangegeven welke condities gelden. Het risico hiervan is dat er lege velden in de DB zullen zitten. Deze zullen naar voren komen in de berichtgeving. De brieven zullen mogelijk blanco velden bevatten en niet volledig zijn. Hoe hiermee omgegaan dient te worden is niet omschreven.



Bij de uitwerking van de testgevallen van de Sanctie berekening (zie uitwerkingen hoofdstuk 12) stuiten we op een inconsistentie van de specificatie. In de datadefinitie staat dat de sanctie formaat 3N heeft. Het is onduidelijk hoe omgegaan moet worden met de sancties „inleveren‟ en „geen sanctie‟. Deze zijn immers strings en geen nummers. Komen we een vergelijkbare situatie tegen in de praktijd is het raadzaam om of een reviewbevinding te registreren en te overleggen met analist of technisch ontwerper.



Het is niet duidelijk wanneer de process flow van fig. 1 wordt doorlopen. Wanneer zal b.v. „Rappel=Y‟ gelden? Zeker niet aan het begin, maar wanneer dan? Dagelijks checken?

72/164


11.3

73/159

Aantekeningen

Hoofdstuk - Logisch Testontwerp

12

Logisch Testontwerp

12.1

Algemeen

Ervaring leert dat er bij het behandelen van de testontwerptechnieken vaak veel aandacht wordt gegeven aan het toepassen van de technieken. Terecht, want het vereist enige hands-on ervaring om door te krijgen hoe de technieken werken en waar ze goed voor zijn. Belangrijk is echter niet voorbij te gaan aan de volgende punten:  Veel organisaties werken niet met testtechnieken (ze zijn dus niet heilig)  Het selecteren van de testtechnieken is vaak net zo moeilijk als het toepassen ervan  Als tester dien je niet alleen te weten hoe de technieken werken (toepassen), je dient een goed begrip te hebben van welke techniek, welk type fouten vindt. Je dient in staat te zijn om vanuit de risico‟s en beschikbare informatie een keuze te kunnen maken, en te kunnen toelichten in begrijpbare taal In het hoofdstuk wordt hier aandacht aangegeven. Geadviseerd wordt hier in de colleges ook bij stil te staan.

12.2

Zelftoets

Vraag 1: Het Logisch testontwerp omschrijft wat er getest moet worden. Fysiek testonwerp omschrijft hoe een logisch testontwerp uitgevoerd moet worden Vraag 2: Welke test gekozen wordt hangt af van:  Verwachte type fout  Ernst van de fout  Beschikbare informatie voor informatie voor uitvoer van de test Vraag 3. Test sterkte = test diepte: begrip voor de hoeveelheid testgevallen die een testtechniek oplevert. Een sterke techniek heeft dus meer testgevallen dan een zwakke en dat vergroot de kans op het vinden van een fout binnen het domein waar de techniek zich op richt. Domein zijn fouten van hetzelfde type. Domeindekking geeft aan hoe er binnen verschillende domeinen getest word, dwz het inzetten van meerdere technieken die elk een ander domein afdekken. Vraag 4. Een test is sterk wanneer deze veel testgevallen oplevert. Deze heeft als voordeel dat het een grote testdekking heeft. Een sterke test is kost daardoor meer tijd om te verwerken, wat een nadeel vormt.

74/164


Een zwakke testtechniek is hier het tegenovergestelde van. Het is een testtechniek die minder testcases oplevert, maar ook sneller verwerkt kan worden, de kans dat een fout niet gevonden wordt, is daarmee groter dan bij het gebruik van een sterkere techniek. Vraag 5. Met sterke testtechnieken worden veel testgevallen opgeleverd. Dit is gunstig omdat het een grote dekking heeft, maar als nadelig gevolg dat de uitwerking ervan veel tijd zal kosten. Als voor alle testen een sterke testtechniek gekozen werd zou dit teveel tijd vergen. Vraag 6. De afkorting EP is staat voor equivalence partitioning (equivalentieklassen). Dit is een testtechniek waarbij het invoerdomein van de data wordt verdeeld in equivalentieklassen (= een verzameling van mogelijke invoer waarden die tot dezelfde soort verwerking leiden). Hier wordt er onderscheid gemaakt tussen valide en invalide data. De afkorting BVA staat voor Boundary Value Analysis (grenswaarde analyse). Bij deze techniek worden testgevallen verkregen aan de hand van grenswaarden. Deze grenswaarden bevatten waarden die er onder, op of boven de grens van equivalentie klasse vallen. Ook hier wordt het onderscheid gemaakt tussen valide en invalide grenswaarden. Bij EP wordt er getest met een willekeurige waarde binnen de equivalentieklasse. Bij BVA worden minimaal beide uiteinden van de equivalentieklasse (grenswaarden) getest. Vraag 7. Met syntaxtesten worden de beperkingen die gesteld worden in aan de invoer en/of de uitvoer gecontroleerd of ze goed zijn geïmplementeerd. Vraag 8. Bij een verplicht veld kan null worden gerekend tot een syntaxcontrole. Als het een optioneel veld is het een EP controle, omdat de functionele verwerking niet verandert als het veld leeg is. Vraag 9. Bij perfomancetesten gebruikt men:  Loadtesten  Stresstesten  Reliabilitytesten  Concurrencytesten (deze is niet in het leerboek behandeld) Vraag 10. Exploratorytesten is een aanpak voor ongespecificeerde testen die gebaseerd zijn op de vaardigheid en ervaring van testers. Het onderscheidt zich van de andere testen omdat het niet gebruikt maakt van ongedefinieerd in detail uitgewerkte testen. Exploratorytesten maakt niet expliciet gebruik van testontwerptechnieken, maar z de kennis en kunde van de tester centraal. Het wordt meestal door 2 testexperts uitgevoerd, waarbij meestal 1 de testen uitvoert (achter het systeem ) en de ander de „scriber‟ is (logt de testen). Vraag 11.

75/159


Een testcharter is een werkpakket, een document met de belangrijkste uitgangspunten/aandachtspunten waar de test aan moet voldoen. In de testcharter staat:  Prioriteit: het belang van de testcluster  Beschikbare tijd: tijd dat besteed mag worden  Beoogd resultaat: het resultaat dat de charter nastreeft  Waarom testen: noodzaak tot het testen van de charter. Dit geeft aan welke bijdrage de geteste functie heeft aan het businessresultaat  helpt bij het valideren van de oplossing  Verwachte problemen: de geïdentificeerde risico's of mogelijke problemen die met de geteste functies geassocieerd zijn. Met deze kennis is het mogelijk te bedenken welke testen uitgevoerd moeten worden.  Niet testen in deze charter: omschrijving van welke elementen niet uitgevoerd zullen worden, omdat ze of elders al getest worden  Conclusie: hierin geeft men aan wat de kwaliteit is van de uitvoering ban de charter. Of het helemaal is afgerond, bepaalde delen opnieuw getest moeten worden, de charter gewijzigd moet worden of het succesvol was geweest, ed. Vraag 12. De TRA heeft bij het maken van logische testgevallen de rol van de bron voor informatie over welke testtechniek passen bij dit domein. Kortom... bepaal welke onderdelen sterk dan wel met een lichte techniek getest moeten worden. Identificeert de mogelijke fouten die kunnen optreden, bepaald welke technieken gebruikt dienen te worden.

12.3

Opdrachten

Voor het uitwerken van de logische testgevallen kan de bij elke testontwerptechniek behorende template gebruikt worden. Deze is beschikbaar op www.testgoal-educatief.nl.

Opgave 1: Horoscoop Naam

Geboortedatum

Geboortetijd Geboorteland Geboorteplaats

Geldig Char Null Diakritische char

Ongeldig -

dd-mm-yyyy d-m-yyyy d-mm-yyyy hh-mm h-m From list

Null, Char, dd-mm-yy Char Null Not from list Null Null

Char Diakritische char

76/164


Naam

Testgeval 1 Char

Testgeval 3 Null

Testgeval 4 Char

Testgeval 5 Char

dd-mm-yyyy

Testgeval 2 Diakritische char (Éèç@#$/~€£¥©®) d-m-yyyy

Geboortedatum

d-mm-yyyy

d-mm-yyyy

Null

Geboortetijd

hh-mm

hh-mm

h-m

h-m

hh-mm

Geboorteland

From list

From list

From list

From list

Geboorteplaats

Char

Char

Char

Char

Resultaat

Horoscoop

From list (Nederlandse Antillen) Diakritische char (Curaçao Island) Horoscoop

Horoscoop

Horoscoop

„S.v.p. Alle gegevens invoeren‟

Naam

Testgeval 6 Char

Testgeval 7 Char

Testgeval 8 Char

Testgeval 9 Char

Testgeval 10 Char

Geboortedatum

Char

dd-mm-yy

dd-mm-yyyy

d-m-yyyy

d-mm-yyyy

Geboortetijd

hh-mm

hh-mm

Char

Null

hh-mm

Geboorteland

From list

From list

From list

From list

Not from list

Geboorteplaats

Char

Char

Char

Char

Char

Resultaat

„De geboortedatum en/of tijd is ongeldig !‟




„Combinatie geboorteland/ geboorteplaats persoon 1 niet gevonden of niet eenduidig (gebruik svp atlas functie)!‟

Naam

Testgeval 11 Char

Testgeval 12 Char

Geboortedatum Geboortetijd

dd-mm-yyyy hh-mm

dd-mm-yyyy hh-mm

Geboorteland Geboorteplaats

Null Char

From list Null

Resultaat



Aan de hand van de foutmelding „De geboortedatum en/of tijd is ongeldig !‟ is niet op te maken of geboortedatum of de geboortetijd fout is. Daarom is er bij het opstellen van de testgevallen altijd maar één van de twee velden met een invalide waarde gevuld. Hierdoor weten we altijd welke invalide waarde de fout veroorzaakt

77/159


Eigenaardigheden van deze applicatie Als je een verkeerde datum invult, geeft de applicatie een rode foutmelding onder in het scherm, als je de geboorteplaats leeg laat (null) krijg je een foutmelding in een aparte box.

Opgave 2: EP RekenJeRijk Op www.testgoal-educatief.nl is een ondersteunende excelsheet beschikbaar. De excelsheet 'RekenJeRijk' illustreert hoe de verkoopbonus berekend wordt. Stap 1: Bepaal eigenschappen en relevante functionele beschrijving De volgende beperkingen zijn van toepassing: Attribuut N verkochte producten N 2de lijn verkopers

Invoer of uitvoer INPUT

Beperking 3 INTEGER, OPTIONEEL

INPUT

3 INTEGER, OPTIONEEL

78/164


Bonus

OUTPUT

5 INTEGER

Opmerkingen: Data definitions are missing for all attributes, the following assumptions were made:  N verkochte producten: max. 999  2de lijn verkopers: max. 999  Bonus: Max 99999 99999 Stap 2: Bepaal geldige en ongeldige equivalentieklassen Attribuut N verkochte producten

N 2de lijn verkopers

Bonus

Geldige klasse 0≤N≤50 50
Ongeldige klasse <0 >999

<0 >999

<0 >99999

Opmerkingen: De volgende aannames zijn gemaakt:  De maximale waarde van het aantal verkochte producten en verkopers is 999  Als er invalide waardes ingevoerd worden word er een foutmelding gegeven.

79/159


Stap 3: Bepaal testgevallen Combineer de bepaalde mogelijkheden in stap 2, tot een minimaal aantal testgevallen die iedere groep bevat (minimaal één). Attribuut N verkochte producten

Geval 1 0≤N≤50 (10)

Geval 2 50
Geval 3 150
Geval 4 NULL

Geval 5 NULL


10≤N≤999 (900)

NULL

5≤N<10 (7)

0≤N<5 (4)

NULL

Toelichting

Opbrengst product a €10 + €500 600

Opbrengst product a €10 + €20 1220

Opbrengst product a €12 + €80+ €300 8780

Geen bonus

Geen bonus

0

0

Bonus

Attribuut

Geval 6 N verkochte producten <0 (-1)

Geval 7 >999 (2500)

Geval 8 0≤N≤50 (10)

Geval 9 0≤N≤50 (10)

>999 (2500)

<0 (-1)


5≤N<10 0≤N<5 (5) (3)

Toelichting Bonus

Invalide Invalide Invalide Invalide error error error error

Opmerkingen: Bedragen kleiner dan 0 kunnen worden ingevoerd maar leiden een error Invoer in vet is invalide invoer. De test kan nog iets effectiever gemaakt worden door het aantal 2de-lijn verkopers van de testgevallen 1 en 4 om te wisselen. In dat geval wordt de 2de lijn bonus ook een keer individueel berekend, en zie je goed het verschil met testgeval 5 Merk op dat alle verschillende bonussen in een keer in de uitkomst verwerkt zijn. Deze zijn:  10 euro/product  12 euro/product  20 euro  80 euro  300 euro  500 euro 80/164


In de testgevallen is een rij toegevoegd „Toelichting‟ deze geeft losstaand van de totaal bonus aan welke bonussen er in de berekening gebruikt zijn.Deze rij is niet verplicht en heeft eigenlijk niets te maken met EP. Hij maakt het testgeval wel inzichtelijker en beter controleerbaar.

Opmerking: Is meer oefening met technieken gewenst? Deze opgave is goed uit te breiden voor een oefening met BVA en C/E.

Opgave 3: C/E Woningcorporatie In de specificatie geven we met markers de condities en de acties aan. In dit geval rood voor de condities en groen voor de acties: Specificatie: Bij de woningcorporatie „Weltevree‟ kunnen woningzoekenden zich inschrijven op een woning. Er wordt een puntensysteem gehanteerd, dat de waarde van de inschrijving bepaalt. Omdat er per woning meestal meerdere reacties zijn, wordt er een rangorde bepaald. Diegene met de hoogste inschrijfwaarde krijgt de woning aangeboden. De woningzoekende kan inloggen op de portal van de coöperatie, zijn punten worden berekend en hij krijgt dan alle woningen te zien waarop hij zich kan inschrijven. Na inschrijven krijgt de woningzoekende te zien hoe hoog hij in de rangorde staat. Komt de woningzoekende van buiten de stad, maar is hij werkzaam in de stad, dan krijgt hij 50 extra punten. Als de inschrijver Stadsvernieuwings (SV) urgentie heeft dan wordt hij boven aan de lijst geplaatst. Is de inschrijver een Starter dan mag hij zich inschrijven op een starterswoning. 20% van het aantal vrijgekomen woningen gereserveerd voor deze doelgroep. Woningzoekers die al een huis huren bij de coöperatie hun huis wordt ook opgenomen in de lijst „woningruil‟. Als ze niet al werkzaam zijn in de stad, krijgen ze extra inschrijfwaarde. Vraag 3a We bepalen welke van de gemarkeerde condities we opnemen in de beslissingstabel. Belangrijk Bij het uitvoeren van de C/E opgaven is het belangrijk om de condities goed te bepalen. Omdat het aantal testgevallen sterk exponentieel groeit met het aantal condities, dienen we het aantal condities te beperken. In onderstaande uitwerking is er gekozen voor 4 condities, dus 16 testgevallen. Echter op basis van bovenstaand specificatie fragment zou je ook meer condities kunnen kiezen. In onderstaande uitwerking is de conditie „kan inloggen‟ niet opgenomen en zijn de condities „woningzoekende van buiten de stad‟ en „ werkzaam in de stad‟ samengevoegd tot één conditie. Als we „kan inloggen‟ zouden opnemen in de beslissingstabel (bv als C0), zouden we de gehele onderstaande tabel moeten kopiëren. De testgevallen 1 tot en met 16 zouden we een keer moeten uitvoeren als we ingelogd hebben, en (omdat we alle bij C/E alle

81/159


combinaties van condities testen) ook nog een keer voor de situatie waarin we niet ingelogd hebben. Het is op je klompen aan te voelen, dat deze laatste testen waarschijnlijk weinig zinvol zijn, en leiden tot veel onmogelijke situaties. NB: In de opmerkingen bij de desbetreffende stap is wel expliciet aangegeven dat deze situatie niet is meegenomen. Ook de condities „woningzoekende van buiten de stad‟ en „werkzaam in de stad‟ zijn samengevoegd om het aantal testgevallen te reduceren. Voor de gevallen waar de samengestelde conditie niet waar is, is bij het invullen van de andere condities rekening gehouden met de twee afzonderlijke condities. Vergelijk bv gevallen 10 en 11. Bij testgeval 11 wordt wel „extra inschrijvingswaarde gegeven‟ in dit testgeval is de woningzoekende dus niet werkzaam in de stad, bij testgeval 10 is dit wel het geval. De keuze om de condities samen te voegen, bespaart veel tijd en leid op deze manier niet tot een kleinere dekking. TIP: Als we bovenstaande keuzes anders hadden genomen, had de beslissingtabel 2^6 = 64 testgevallen geteld. Het is daarom aan te bevelen om de studenten hierop te wijzen. Dit voorkomt dat ze een hele middag zitten te zwoegen en steunen op een ‘onmogelijke’ opgave, terwijl ze met een kleine tip, binnen redelijk tijd klaar kunnen zijn.

Condities C1: Buiten de stad en werkzaam binnen de stad C2: Stadsvernieuwingsurgentie C3: Starter C4: Huurt reeds een woning bij de coöperatie Acties A1: Bereken punten aantal A2: Geef extra inschrijvingswaarde A3: Extra 50 punten A4: Toon woningen A5: Toon starters woning A6: Plaats bovenaan de lijst A7: Plaats woning op ruillijst A8: Toon positie op rangorde lijst Opmerking: Het inloggen en het inschrijven is niet opgenomen in de conditie lijst. Als dit wel gedaan zou worden, neemt het aantal testgevallen enorm toe. Het resultaat zou een reeks van testen zijn die aantonen dat er niets gebeurd als er niet ingelogd is, en een reeks testen die aangeeft dat de woningzoekende niet te zien hoe hoog hij in de rangorde staat, als hij zich niet inschrijft. Het heeft weinig toegevoegde waarde om voor deze situaties alle combinaties van de andere condities te testen. Ze zullen immers tot hetzelfde resultaat leiden.

82/164


Vraag 3b Het vullen van de beslissingstabel. Om de tabel te vullen hanteren we de volgende aanpak: We maken één kolom per testgeval (in dit geval dus 16) De eerste rij vullen we met 16/2 =8 enen gevolgd door 16/2= 8 nullen De tweede rij vullen we met 16/4 = 4 enen, gevold door 16/4 = 4 nullen, gevolgd door 4 enen, gevold door 4 nullen De derde rij vullen we om en om met 16/8 = 2 enen en nullen De vierde rij vullen we om en om met 16/16 = 1 enen en nullen

Geval 9

Geval 10

Geval 11

Geval 12

Geval 13

Geval 14

Geval 15

Geval 16

A5: Toon starters woning

Geval 8

A4: Toon woningen

Geval 7

A2: Geef extra inschrijvingswaarde A3: Extra 50 punten

Geval 6

A1: Bereken punten aantal

Geval 5

C4: Huurt reeds een woning bij de coöperatie

Geval 4

C3: Starter

Geval 3

C1: Buiten de stad en werkzaam binnen de stad C2: Stadsvernieuwingsurgentie

Geval 2

Condities/ Acties

Geval 1

Daarna bepalen we per kolom de bijpassende acties.

1

1

1

1

1

1

1

1

0

0

0

0

0

0

0

0

/ 1 /

/ 1 0

/ 0 /

/ 0 0

0 1 /

0 1 0

0 0 /

0 0 0

1 1 /

1 1 0

1 0 1

1 0 0

0 1 /

0 1 0

0 0 1

0 0 0

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

X

X

X X

X X

X

X

X X X

X X X

X

A6: Plaats bovenaan de lijst A7: Plaats woning op ruillijst A8: Toon positie op rangorde lijst

X

X

X

X

X

X

X

X

X

X

X

X

Aannames:  Een starter kan niet al huren bij de coöperatie  Een starter kan wel een SV urgentie hebben, als hij bv. een kamer huurt in een te vernieuwen wijk.  Iemand van buiten de stad kan niet al huren bij de coöperatie  Iemand van buiten de stad kan niet een SV urgentie hebben In een werksituatie zullen we deze aannames natuurlijk toetsen. Bijvoorbeeld door even langs te gaan bij de analist. Niet toegestane combinaties zijn aangeven met een / (hier zou een 1 hebben moeten staan, maar deze conditie is niet waar, omdat de combinatie onmogelijk is).

83/159

X


A5: Toon starters woning

Geval 16

A4: Toon woningen

Geval 15

A2: Geef extra inschrijvingswaarde A3: Extra 50 punten

Geval 14

A1: Bereken punten aantal

Geval 12

C4: Huurt reeds een woning bij de coöperatie

Geval 11

C3: Starter

Geval 10

C1: Buiten de stad en werkzaam binnen de stad C2: Stadsvernieuwingsurgentie

Geval 8

Condities/ Acties

Geval 6

Vraag 3c Na opschonen van de overbodige testgevallen blijft de volgende set testgevallen over.

1

1

0

0

0

0

0

0

0 1 0

0 0 0

1 1 0

1 0 1

1 0 0

0 1 0

0 0 1

0 0 0

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

A6: Plaats bovenaan de lijst A7: Plaats woning op ruillijst A8: Toon positie op rangorde lijst

X

X

X

X

X

Opgave 4: Syntax ‘handmatige registratie’ Stap 1:Bepaal de beperkingen van de attributen De volgende beperkingen zijn van toepassing: Attribuut Plaats Snelweg Kenteken voertuig Type overtreding Gemeten snelheid

Beperking 20 karakters: cijfers,hoofdletters en kleine letters, verplicht 20 karakters: cijfers,hoofdletters en kleine letters, niet verplicht 8 karakters: cijfers,hoofdletters en kleine letters, koppelstreepjes, verplicht 1 cijfer: 1, 2 of 3, verplicht 3 cijfers, conditioneel

Stap 2: Bepaal geldige en ongeldige waarden Attribuut Plaats

Geldig waarde 20 AN 20 an

Snelweg Kenteken voertuig

20 AN 20 an NN-AA-NN (23-XZ-14)

Type overtreding

[1,.., 3]

Ongeldig waarde Plaats > 20 AN Null Spaties Plaats > 20 AN AA-NN-AA (XZ-23-AB) NN-aa-NN (23-xz-14) AANNAA (23XZ14) [0,4, ...,9] 84/164


Gemeten snelheid

3 N, dus 0<=snelheid<=999 null als Type overtreding = 2

null Gemeten snelheid > 999 Gemeten snelheid < 0 A,a en andere tekens null als Type overtreding = 1 of 3

Opmerkingen:  De Null waarden bij Snelweg zijn niet getest omdat dit een optioneel veld is.  Er zijn natuurlijk veel meer invalide kentekens te bedenken, maar in deze uitwerking is het aantal beperkt tot 3.  N zijn de numerieke waarden en A (en ook a) de alfanumerieke waarden, waarbij o A = [A, ..., Z]  hoofdletters o a = [a, ..., z]  kleine letters o N = [0, ..., 9]  natuurlijke getallen o Dus 3N betekent een getal tussen 0 en 999 Stap 3: Bepaal testgevallen Combineer de waarden bepaald in stap 2 tot een minimum aantal testgevallen, waarbij in een case maximaal één attribuut een ongeldige waarde mag hebben. Attribuut Plaats Snelweg Kenteken voertuig

Type overtreding Gemeten snelheid

Verwacht resultaat

85/159

Geval 1 20 AN 20 AN NN-AANN (23XZ-14) [1,.., 3] (1) 0<=snelh eid<=99 9

Geval 2 20 an 20 an NN-AANN (23XZ-14) [1,.., 3] (1) 0<=snelh eid<=99 9

Geval 3 > 20 AN 20 AN NN-AANN (23XZ-14) [1,.., 3] (2) null

Geval 4 Null 20 AN NN-AANN (23XZ-14) [1,.., 3] (2) null

Geval 5 Spaties 20 AN NN-AANN (23XZ-14) [1,.., 3] (2) null

Geaccept eerd

Geaccept eerd

Fout

Fout

Fout


Attribuut Plaats Snelweg Kenteken voertuig

Geval 6 20 AN > 20 AN NN-AANN (23XZ-14)

Geval 7 20 AN 20 AN AA-NNAA (XZ23-AB)

Geval 8 20 AN 20 AN NN-aaNN (23xz-14

Type overtreding

[1,.., 3] (1)

[1,.., 3] (1)

[1,.., 3] (1)

Gemeten snelheid

0<=snelh 0<=snelh eid<=99 eid<=99 9 9


[0,4, ...,9] (9) 0<=snelh eid<=99 9

Verwacht resultaat

Fout

Fout

Fout

Fout

Fout

Attribuut Plaats Snelweg Kenteken voertuig

Geval 11 20 AN 20 AN NN-AANN (23XZ-14) Null

Geval 12 20 AN 20 AN NN-AANN (23XZ-14) Alfa (O)

Geval 13 20 AN 20 AN NN-AANN (23XZ-14) [1,.., 3] (1) > 999

Geval 14 20 AN 20 AN NN-AANN (23XZ-14) [1,.., 3] (2) <0

Geval 15 20 AN 20 AN NN-AANN (23XZ-14) [1,.., 3] (2) A:c

Geval 16 20 AN 20 AN NN-AANN (23XZ-14) [1,.., 3] (3) null

Fout

Fout

Fout

Fout

Type overtreding Gemeten snelheid


Verwacht resultaat

Fout

Fout

Geval 9 20 AN 20 AN AANNA A (23XZ14 ) [1,.., 3] (1)

Geval 10 20 AN 20 AN NN-AANN (23XZ-14)

Opmerkingen: De invalide waarden zijn in vet aangegeven Plaats 20 AN, is dat eigenlijk voldoende? In het CSS wordt een veldlengte van 20 tekens gebruikt om de plaatsnaam in op te slaan. Is deze veldlengte voldoende, wat is eigenlijk de langste plaatsnaam in Nederland? Gasselterboerveenschemond (25 letters) wordt algemeen als de langste plaatsnaam van Nederland beschouwt. De naam van dit onder de gemeente Aa en Hunze (Drenthe) vallende dorpje telt een letter meer dan die van het naburige Gasselternijveenschemond [http://www.onzetaal.nl/kalender/records/r0202.php] De kortste plaatsnamen ter wereld bestaan uit één letter. Zweden, Noorwegen en Denemarken hebben alle drie een dorpje dat Å heet, en in Frankrijk ligt het gehucht Y – wat ook de naam is van een stadje in de Amerikaanse staat Arkansas. Verder zijn er nog het dorpje U op de Carolina's (een eilandengroep in de Grote Oceaan) en het Japanse plaatsje O. 86/164


In Nederland bestaat de kortste plaatsnaam uit twee letters: in de gemeente Dongeradeel in Friesland vinden we het dorpje Ee. In België zijn As (provincie Limburg), My (provincie Luik) en On (provincie Luxemburg) de plaatsen met de kortste naam. [http://www.onzetaal.nl/kalender/records/r1901.php]

Opgave 5: Syntax ‘handmatige registratie’ Stap 1:Bepaal de beperkingen van de attributen De volgende beperkingen zijn van toepassing: Attribuut Agent_ID Pleegdatum Type overtreding

Beperking 8 cijfers, verplicht 8 cijfers en 2 koppeltekens, verplicht 1 cijfer: 1, 2 of 3, verplicht

Opmerkingen: Het attribuut „Bevestiging‟ betreft alleen de roodlichtrijderssancties. Stap 2: Bepaal geldige en ongeldige waarden Attribuut Agent_ID

Geldig waarde 8N

Pleegdatum

dd-mm-jjjj Bijvoorbeeld: 14-12-1999, 01-01-0001 [1,.., 3]

Type overtreding

Opmerkingen:

87/159

Ongeldig waarde Overtreding_ID > 8N Null dd-mm-jj dd:mm:jjjj 29-02-2009 [0,4, ...,9] null


1) Er zijn natuurlijk veel meer invalide kentekens te bedenken (bv NN-NN-NNNN, NN/NN/NNNN, NN NN NNNN en combinaties hiervan , maar in deze uitwerking is het aantal beperkt tot 3. 2) N zijn de numerieke waarden en A (en ook a) de alfanumerieke waarden, waarbij A = [A, ..., Z]  hoofdletters a = [a, ..., z]  kleine letters N = [0, ..., 9]  natuurlijke getallen Dus 3N betekent een getal tussen 0 en 999 Daarnaast zijn er ook de leestekens zoals spaties en koppelstreepjes en Stap 3: Bepaal testgevallen Combineer de waarden bepaald in stap 2 tot een minimum aantal testgevallen, waarbij in een case maximaal één attribuut een ongeldige waarde mag hebben.

88/164


Attribuut Agent_ID

Geval 1 8N (00000000)

Geval 2 8N (99999999)

Geval 3 8N (12345678)

Geval 4 Overtredi ng_ID > 8N (12345678 9)

Geval 5 Null

Pleegdatum

dd-mm-jjjj (14-121999) [1,.., 3] (1)

dd-mm-jjjj (01-010001) [1,.., 3] (2)

dd-mm-jjjj (01-010001) [1,.., 3] (3)

dd-mm-jjjj (31-122010) [1,.., 3] (1)

dd-mm-jjjj (30-062009) [1,.., 3] (3)

Geval 6 8N (00000001) dd-mm-jj (14-12-99)

Geval 7 8N

Geval 8 8N

Geval 9 8N

Geval 10 8N

dd:mm:jjj j (14:12:199 9) [1,.., 3] (2)

29-02-2009

dd-mm-jjjj (14-121999)

dd-mm-jjjj (14-121999)

[1,.., 3] (3)

[0,4, ...,9] Null

Type overtreding Attribuut Agent_ID Pleegdatum

Type overtreding

[1,.., 3] (1)

(0)

Note: Tussen haakjes staat een mogelijke fysiek waarde weergegeven. Bij herhalen van een testgeval is hier een andere waarde ingevuld, om de testdekking te vergroten. Daar waar dit niet gedaan is, staat het de testengineer vrij om zelf een waarde te kiezen.

Opgave 6: EP ‘Berekenen sanctie’ Uitwerking Bij de uitwerking van de opgave is de uitwerking opgesplitst voor de verschillende typen overtreding en de sanctie. Dit voorkomt dat de tabellen te groot worden en houdt het logisch testontwerp overzichtelijk. a) Snelheidsovertreding: Tabel A.1 in de specificatie van het centrale sanctiesysteem staan de grenswaarden waarbij een bepaalde sanctie wordt toegekend en de eigenlijke sancties gedefinieerd. De specificatie omschrijft dat je deze gegevens kan beheren.

89/159


In de onderstaande uitwerking is de correctie aangepast om passende combinaties te maken waarbij alle input en output klassen gedekt zijn. Attribuut Gemeten snelheid

Geval 1 Geval 2 0<=snelheid<= snelheid<0 999 (-50) (140)

Geval 3 snelheid>999 (9999)

Toegestane snelheid

0<=snelheid<= 0<=snelheid< 999 =999 (120) (50)

0<=snelheid<= snelheid<0 999 (-10) (999)

Correctie

0<= Correctie <=99 (3)


0<= Correctie <=99 (99)


Overtreding

10
Overtreding <=0 (-100)

Overtreding >40 (8901)

Overtreding >40 (140)

Geen Sanctie

Inleveren

Inleveren

Sanctie

Geval 4 0<=snelheid<= 999 (135)

90/164


Attribuut Gemeten snelheid

Geval 5 0<=snelheid<=999 (999)



Toegestane snelheid

snelheid>999 (1000)

0<=snelheid<=999 (50)

0<=snelheid<=999 (0)

Correctie


Correctie<0 (-4)

Correctie >99 (100)

Overtreding

Overtreding <=0 -1

Overtreding >=40 800

Sanctie

Geen Sanctie

10
b)

Inleveren

In de uitwerking van vraag 6a komt alle mogelijke output een keer voor, namelijk 28, 90, „inleveren‟ en „geen sanctie‟.

Opmerking 1: Bij de uitwerking van de testgevallen stuiten we op een inconsistentie van de specificatie. In de datadefinitie staat dat de sanctie formaat 3N heeft. Het is onduidelijk hoe omgegaan moet worden met de sancties „inleveren‟ en „geen sanctie‟. Deze zijn immers strings en geen nummers. Komen we een vergelijkbare situatie tegen in de praktijd is het raadzaam om of een reviewbevinding te registreren en te overleggen met analist of technisch ontwerper. Opmerking 2: De sancties „28‟ en „inleveren‟ worden in de ontworpen testgevallen gecreëerd aan de hand van testgevallen met invalide equivalentie klassen (zie testgeval 6 en 7). In praktijk zullen deze testen tot een fout leiden. Om de output EP volledig te hebben, d.w.z. ook een keer gezien te hebben dat de sancties „28‟ en „inleveren‟ ook daadwerkelijk worden gegeven, zullen extra testgevallen nodig zijn, met alleen valide waarden. Bijvoorbeeld de volgende testen: Geval 8 0<=snelheid<=999 (114)


0<=snelheid<=999 (100)

0<=snelheid<=999 (100)



11 28

87 Inleveren

91/159


c) Rappel berekening: Attribuut Sanctie

Geval 1 0< Sanctie <=999 (28) 0 <= Rappel <=999 (971) Vandaag > Datum_verstuu rd+10 (wel rappel)

Geval 2 Inleveren

Geval 3 geen

999

Inleveren + 35

Error

Error (>999)

Geval 5 0< Sanctie <=999 (28) rappel<0 (-10)

Geval 6 0< Sanctie <=999 (90) rappel>999 (1000)

Datum_verstuurd

Vandaag > Datum_verstuu rd+10 (wel rappel)

Vandaag > Datum_verstuu rd+10 (wel rappel)

Geval 7 0< Sanctie <=999 (28) 0 <= Rappel <=999 (0) Vandaag < datum verstuurd

Geval 8 0< Sanctie <=999 (90) 0< Sanctie <=999 (35) Vandaag <= Datum_verstuu rd+10 (geen rappel)

Sanctie (nieuw)

Error

Error

Error

90 (geen rappel)

rappel

Datum_verstuurd

Sanctie (nieuw)

Attribuut Sanctie

rappel

Geval 4 0< Sanctie <=999 (28) 0< Sanctie 0 <= Rappel 0 <= Rappel <=999 <=999 <=999 (28) (35) (972) Vandaag > Vandaag > Vandaag > Datum_verstuu Datum_verstuu Datum_verstuu rd+10 (wel rd+10 (wel rd+10 (wel rappel) rappel) rappel)

Opmerkingen:  Voortbordurend op de opmerking bij vraag 6b. In de datadefinitie staat dat de sanctie formaat 3N heeft. Bij het berekenen van de rappel sanctie kan het voorkomen dat de sanctie niet voldoet aan dit formaat. Het is onduidelijk hoe omgegaan moet worden met de sancties „inleveren‟ en „geen sanctie‟. 

In testgeval 3 staat sanctie „geen‟. Dit is gebaseerd op het volgende specificatie fragment : “Voor alle sancties geldt dat wanneer Sanctie =< 0 er geen sanctie wordt gegeven en er een foutmelding volgt: [Sanctie te laag]. In alle andere gevallen wordt de berekende Sanctie opgeslagen in de Registratie DB.” (sectie 2.4 Berekenen sanctie)

92/164


Aandachtpunten 1) Het gebruik van groter en kleiner dan tekens blijkt in de praktijk erg moeilijk te zijn. Uitwerkingen zijn bevatten vaak onhandige en incorrecte notaties, zoals: Voorbeeld 1: 0=A<6

Voorbeeld 2: 0
Fout:  De tweede regel zou moeten zijn: 3<=A< 6.

Fout:  „3‟ zit niet in de range, omdat noch in de eerste, noch in de tweede regel een „=‟ staat.  De derde range begint bij 7 i.p.v. bij 6.

Tip: Vergeet je steeds welk teken nu groter dan en welk teken kleiner dan betekent? Het volgende ezelsbruggetje kan dan uitkomst bieden: De K in kleiner is geschreven als

|<, Kleiner dan wordt dus genoteerd als < .

2) Het is efficiënt en duidelijk om de equivalentie klassen die in stap 2 van de uitwerking zijn vastgesteld ook letterlijk terug laten komen in de testcases. Studenten maken vaak de fout om deze waarden niet letterlijk over te nemen, maar te interpreteren. In stap 2 van de uitwerking definieerden ze de equivalentieklasse als „33‟. De opmerking die hierbij gemaakt kan worden is dat het efficiënter in om de equivalentie klasse te kopiëren. Elke interpretatie slag de testengineer maakt, kost tijd en kan fouten opleveren. Maak de student bewust van het feit dat degene die met de logische testen aan de slag gaat, waarschijnlijk weer een teruginterpretatie moet maken. Dit kost nogmaals tijd en vergroot de kans op fouten. 3) Vaak hebben studenten de neiging om combinaties van attributen te gaan testen. Bij EP gaat het er niet om de combinaties te testen, maar om minstens elke equivalentie klasse één keer in een test opgenomen te hebben. 4) Begin met de valide tests. Testcase 1 is het belangrijkste goedpad. Reden hiervoor is dat men de neiging heeft om te beginnen bij het eerste testgeval; en in de regel eerst gekeken wordt of de functie überhaupt werkt, alvorens de uitzonderingen (invalide testen) te testen. Bepalen van het aantal testgevallen Het aantal testgevallen kan goed van te voren worden geschat. Het attribuut met de meeste aantal valide equivalentieklassen bepaald het aantal valide testgevallen.

93/159


Het totaal aantal invalide equivalentieklassen bepaald in de regel het aantal invalide testgevallen. Stel we hebben drie attributen en equivalentieklassen A-I Attribuut Attribuut 1 Attribuut 2 Attribuut 3

Valide A, B, C D E

Invalide F, G H I

Voor de valide testgevallen geldt, dat we in het eerste testgeval de attributen A, D en E kunnen testen. Voor het testen van de equivalentie klassen B en C zullen we twee extra testgevallen moeten toevoegen. Bij deze testgevallen zullen we D en E nog een keer gebruiken. Dit vergroot de dekking echter niet, omdat deze al in de eerste test zijn opgenomen. Zo maken we bijvoorbeeld de volgende valide testgevallen: 1: A, D, E 2: B, D, E 3: C, D, E Voor de invalide testgevallen geldt dat we elke invalide equivalentieklassen het liefst testen in combinatie met valide equivalentieklassen. Zo maken we bijvoorbeeld de volgende invalide testgevallen: 4: F, D, E 5: G, D, E 6: A, H, E 7: A, D, I

Opgave 7: BVA ‘Berekenen sanctie’ Opgave 7a De onderstaande tabel geeft grenswaarden aan die er zijn. De gearceerde grenswaarden zij op genomen in de onderstaande testgevallen. De vetgedrukte grenswaarden zijn de invalide grenswaarden. Gemeten snelheid Toegestane snelheid Correctie Overtreding Overtreding (vervolg) Sanctie

-1 -1 -1 -1 geen

0 0 0 0 39 28

1 1 1 1 40 90

998 998 98 9 41 Inlever en

999 999 99 10 998

1000 1000 100 11 999

1000

94/164


Opmerking Voor het veld Gemeten snelheid en Toegestane snelheid staat niet gedefinieerd hoe er omgegaan moet worden met negatieve en nul-waarden. De definitie van Correctie (ook een veld dat een snelheid weergeeft) geeft aan dat deze‟ >=0‟ is. Aanname is dat dit ook geldt voor de Gemeten snelheid en Toegestane snelheid. Moraal: Als de specificatie onvolledig of onduidelijk is, is uit de context is vaak te achterhalen wat er bedoeld is. Op basis hiervan kunnen vaak zinnige aannames gemaakt worden. Maar let wel, dit zijn aannames. Aannames altijd toetsen door bijvoorbeeld lang te gaan bij de analist. De volgende testgevallen zijn nodig om alle grenswaarden minimaal één keer te testen. Merk op dat er ook andere combinaties mogelijk zijn Cursief zijn testwaarden aangegeven die nodig zijn voor het berekenen van een sanctie met een grenswaarde, maar niet veel toevoegen aan de test. Het zijn of grenswaarden die al een keer in een ander testgeval voorkomen, of het zijn geen grenswaarden. Het aantal van deze „overbodige‟waarden dient zoveel mogelijk beperkt te worden. Deze leiden immers tot extra testactiviteiten die de formele dekking niet vergroten. Attribuut Gemeten snelheid

Geval 1 0

Geval 2 999

Geval 3 999

Geval 4 998

Geval 5 999

Geval 6 104

Toegestane snelheid

1

999

998

891

890

90

Correctie

0

0

0

98

99

3

Overtreding

-1

0

1

9

10

11

Sanctie

Geen Sanctie

Geen Sanctie

28

28

28

90

Attribuut Gemeten snelheid

Geval 7 160

Geval 8 165

Geval 9 165

Geval 10 999

Geval 11 999

Geval 12 1

120

120

120

1

0

0

Correctie

1

5

4

0

0

0

Overtreding

39

40

41

998

999

1

Sanctie

90

90

Toegestane snelheid

95/159

Inleveren Inleveren Inleveren

28


Opgave 7b Een typische fout die wel met BVA maar niet met EP gevonden zou zijn, is de berekening van een verkeerde sanctie als bijvoorbeeld de overtreding precies 10 km/uur is. Bij opgave 3 is deze grenswaarde niet expliciet meegenomen. De applicatie geef een verkeerd antwoord als bijvoorbeeld:  sanctie = 28 als overtreding <10 i.p.v. sanctie = 28 als overtreding <= 10 km/u  sanctie = 90 als overtreding >=10 i.p.v. sanctie = 28 als overtreding <= 10 km/u is geïmplementeerd Het testen van de grenswaarden van de sanctie helpt ook bij de controle van de correctie. Als de correctie niet wordt doorgevoerd (bv omdat de programmeur dit is vergeten te implementeren of er door een programmeerfout altijd een nul-waarde in de berekening wordt meegenomen) zal dit door testgeval 4 aan het licht worden gebracht. Als de correctie niet wordt meegenomen, dient in dit geval het rijbewijs Ingeleverd te worden, ipv een sanctie van 28 Euro. Deze situatie wordt niet gevonden als met de EP testgevallen van opgave 6.

Opgave 8: State Transition testing op basis van het STD (figuur 6) Opgave 8a Stap 1: Bepaal state transition diagram (indien nog niet gedaan)

S1: Geregistreerd

A

S2: Beschikking verzonden

B

E F I

S3: Sanctie betaald

S5: Rappel verzonden

J S7: Geseponeerd C

G

L K

S4: Geen actie nodig

M

S8: Geseponeerd & Restitutie nodig

S6: Deurwaarder

H

96/164


Stap 2: Bepaal testdiepgang De diepgang is Switch Coverage = 0 Stap 3: Bepaal de toestandentabel Lijst van combinaties van acties en toegestane toestandsovergangen: Toestand S1Geregistreerd S2Beschikking verzonden S3Sanctie voldaan S4Geen actie nodig S5Rappel verzonden S6Deurwaarder S7Geseponeerd S8Restitutie nodig S9Eind

A B C S2 S3 -

D -

E F S5 -

G -

H -

I J S7 -

K -

L -

M -

N -

-

S9 -

-

S6 -

S9 -

-

S4 -

S8 -

S4 -

S7 -

-

S4 -

S3 -

S7 -

Stap 4: Bepaal testgevallen De overgangen kunnen, gebaseerd op bovenstaande tabel, worden gedefinieerd. S1S2 S2S3 S2S5 S2S7 S3S4 S3S7 S4S9 S5S3 S5S6 S6S9 S7S4 S7S8 S8S4 S5S7 Valide geval 1 S1 Pre-conditie Actie A S2 Conditie Actie B S3 Conditie Actie C S4 Conditie Actie D S9 Conditie Post-Conditie S9

Valide geval 2 S1 (H) A (H) S2 E S5 G S6 H

valide geval 3 S1 (H) A (H) S2 I S7 K

valide geval 4 S1 (H) A (H) S2 (H) I (H) S7 L S8 M

Valide geval 5 S1 (H) A (H) S2 (H) E (H) S5 F S3 J

Valide geval 6 S1 (H) A (H) S2 (H) E (H) S5 N

S2

S4

S4

S7

S7

Opmerking: De laatste State is gedefinieerd als S9, wat niet in het boek staat. (H) staat voor herhaling, deze stappen zijn in een eerder testgeval al doorlopen en dienen enkel 97/159


doorlopen te worden om in een bepaalde state terecht te komen die als eigenlijke startpunt voor het testgeval geldt. Opgave 8b Bij de invalide testen worden alle transities die niet mogen getest. Bijzondere aandacht verdienen de transities S7-S8 en S7-S4. S7-S8 : Er kan geen restitutie verleend worden als er nog niet betaald is. S7-S4: Misschien is het mogelijk om zonder restitutie een betaalde sanctie te seponeren. Hoe moet hiermee omgegaan worden? Mag er een mail naar de financiële afdeling gaan met een restitutiebedrag gelijk aan 0, of mag deze mail nooit worden verstuurd. Welke controle is geïmplementeerd om de zorgen dat seponeren niet zondermeer kan als er al betaald is? De specificatie is niet duidelijk op de gegeven punten. Dus onze kans om een fout te vinden. Opgave 8c Overgangen: S1-S2-S5 S1-S2-S3 S1-S2-S7 S2-S5-S6 S2-S5-S3 S2-S3-S7 S2-S3-S4 S2-S7-S8 S2-S7-S4 S3-S7-S8 S3-S7-S4 S3-S4-S9 S5-S6-S9 S5-S3-S7 S5-S3-S4 S5-S7-S8 S5-S7-S4 S7-S8-S4 S7-S4-S9 S8-S4-S9

98/164


Valide geval 1 Pre-conditie S1

Valide geval 2 S1

valide geval 3 S1

Valide geval 5 S1 (H)





A S2 I S7 K S4 D

valide geval 4 S1 (H) A (H) S2 E S5 G S6 H

Actie Conditie Actie Conditie Actie Conditie Actie Conditie Actie Conditie Actie Conditie Postconditie

A S2 E S5 F S3 C S4 D

A S2 B S3 J S7 L S8 M S4 D

A (H) S2 (H) E (H) S5 F S3 J S7 K

A (H) S2 B S3 C

A (H) S2 I S7 L

A (H) S2 (H) E (H) S5 N S7 L

A (H) S2 (H) E (H) S5 N S7 K

S9

S9

S9

S9

S4

S4

S8

S8

S4

Merk op dat de uitwerking van 8c veel meer herhaling bevat dan bij vraag 8a met switchcoverage = 0 Hoe pas je state testing toe als er twee manieren zijn om van de ene naar de ander toestand te komen? In analogie met de Statement coverage en de branch coverage die we bij PCT testen tegenkomen kunnen we ook de coverage van ST variëren. Bij ST kunnen we er bijvoorbeeld voor kiezen om  alle toestanden één keer te raken (lijkt op statement coverage) of  alle overgangen te testen (lijkt op branch coverage). Gaan we uit van het laatste, dan worden testing worden alle transities tussen twee toestanden getest. In het geval dat er twee manieren zijn om van S1 naar S2 te komen worden beide opgenomen in de state table. Daarom wordt de state table vaak als een „toestand x actie‟ matrix weergegeven. Bijvoorbeeld:

S1

A B C S1 S2 S2 S2 S1

C A B

S2

Deze situatie komt voor bij het CSS waar de sanctie zowel handmatig als batchgewijs verzonden kan worden. In beide situaties gaat de status van niet verzonden naar verzonden.

Het testen van switch coverage = 1 en hoger. Bij hogere orde transities is de „toestand x actie‟ matrix moeilijk toepasbaar. Het is beter

99/159


om dat een „toestand-x toestand‟ matrix te gebruiken. Het uitrekenen van het aantal hogere orde transities dat mogelijk is van de ene naar de andere toestand, kan worden gedaan door de matrices te vermenigvuldigen. Neem bijvoorbeeld de volgende STD: A

S2

B

E S1

S4 F

C

S3

D

State table M: S1 S2 S3 S4

S1 0 0 0 2

S2 1 0 0 0

S3 1 0 0 0

S4 0 1 1 0

Tweede orde transities worden verkregen door de state table te kwadrateren:

 0 1 1 0 0 1 1 0 0 0 0 2 0 0 0 1  0 0 0 1   2 0 0 0     MxM   0 0 0 1  0 0 0 1   2 0 0 0         2 0 0 0  2 0 0 0 0 2 2 0  M2 (4,2) = 2, Wat aangeeft dat er 2 testgevallen nodig zijn om de transitie S4-S2 te testen Voor 3e orde transities geld dat:

0 2 2 M M   2  0

0 0 2 0 0 0 0 0  0 0 0  0   2 2 0 2

1 1 0  4 0 0 1 0  0 0 1  0   0 0 0 0

0 0 0 2 2 0 2 2 0  0 0 4

M3(1,1) = 4. Wat ook klopt, De 3de orde transitie S1-S1 kan op 4 manieren: S1-A-S2-B-S4-E-S1 S1-A-S2-B-S4-F-S1 S1-C-S3-D-S4-E-S1 S1-C-S3-D-S4-F-S1

100/164


Opgave 9: State transition testing van schermtransities Vraag 9a

S6: Wijzigen

Wijzigen

Annuleren Of Bevestigen

Details S5: Registratie overzicht

S3: Registratie gegevens Annuleren

Enkelvoudig

Overzicht

Annuleren of Verzenden

Handmatige Invoer bevestigen

Annuleren Verder

verzenden Invoeren S4: Verzenden

S2: Handmatig invoeren

S1: Menu Annuleren of Batch verzenden Annuleren Of Bevestigen Beheer

S7: Beheer

Annuleren

Annuleren Error Log

S8: Error Log

Voor de testdiepgang Switch coverage = 1, valide testen geldt de onderstaande combinaties van acties en toegestane state transitions:

101/159

Wijzigen

Details

Verder

Beheer

Error log

Enkelvoudig

S4 -

S5 -

-

-

S3 -

S7 -

S8 -

-

S1 -

S1 -

-

S6 -

S3 -

-

-

-

S5 -

S1* of -# S5 S1 -

Invoeren

Overzicht

-

Bevestigen

Verzenden

S4 S5 S6 S7 S8

S1 S2* of S5# S1 S1 S5 S1 S1

Batch verzenden

S1 S2 S3

Annuleren

Toestand


S2 -

-

Opmerkingen: 1) De registratiegegevens worden gebruikt bij twee functies, namelijk het controleren van de gegevens bij handmatige invoer en bij het inziet van de registratiegegevens vanuit het overzicht. Hoewel het scherm er in beide gevallen hetzelfde uitziet, is de navigatie net anders. In de state table is dit als volgt aangegeven: * = bij handmatige invoer # = bij registratie gegevens 2) De notatie „-„ is gebruikt om aan te geven dat er geen transitie mogelijk is. Door de cel niet leeg te laten weten we zeker dat er nagedacht is over de transities en dat deze niet per ongelijk vergeten is. Vraag 9b Er zijn in het diagram geen acties gedefinieerd. Deze dienen uit de specificatie geëxtraheerd te worden. De meeste transacties gaan gepaard zonder extra acties. Uitzonderingen zijn: S5-S1 en S4-S1. Hierbij word respectievelijk een handmatig selecteerde of een batch met beschikkingen verstuurt. Vraag 9c Uit de state table extraheren we de volgende overgangen: S1-S4 S1-S5 S1-S7 S1-S8 S1-S2 S2-S1 S2-S3

S3-S2* S3-S5# S3-S1* S4-S1 (Annuleer) S4-S1 (Batchverwerken) S4-S5

S5-S1 (Annuleer) S5-S1 (Verzenden) S5-S6 S5-S3 S6-S5 (Annuleer) S6-S5 (Bevestiging)

102/164


S7-S1(Annuleer) S7-S1(Bevestiging) S8-S1 Hiermee kunnen we de volgende ketens maken: Testgeval 1 S1-S8 S8-S1 S1-S7 S7-S1 (Annuleer) S1-S4 S4-S1 (Batchverwerken) Testgeval 2 S1-S4 (H) S4-S1 (Annuleer) S1-S5 S5-S3 S3-S5# S5-S6 S6-S5 (Annuleer) S5-S1 (Annuleer) Testgeval 3 S1-S2 S2-S3 S3-S1* S1-S4 (H) S4-S5 S5- S6 (H) S6-S5 (Bevestigen) S5-S1 (Verzenden) Testgeval 4 S1-S2 (H) S2-S3 (H) S3-S2* S2-S1 S1-S7 (H) S7-S1 (Bevestigen)

103/159


Vraag D: De overgangen van S3 naar S1, S2 en S5 zijn conditioneel. Afhankelijk van hoe je het scherm binnenkomt mogen bepaalde overgangen wel of niet. Annuleren brengt je terug naar het scherm waar je vandaan komt. Dit kan S5 of S2 zijn, De bevestigen knop mag alleen „enabled‟ zijn bij handmatige invoer.

Het nut van paden testen Er is een verschil tussen het testen van elke functie en het testen van alle paden door het systeem. Dit verschil wordt duidelijk aan de hand van het volgende voorbeeld. Bij de Hema kun je on-line foto‟s bestellen. Om dit te doen moet je geregistreerd staan. Registreren kan vooraf, via de hoofdpagina, maar als onderdeel van het foto-upload-enbestel proces. Als we kiezen om vooraf te registreren krijgen we het volgende scherm te zien:

[https://foto.hema.nl/web/20349612/cmRegistration.do;jsessionid=4741C25CDA9ABC9908688AE7B87582E8]

Als we ervoor kiezen om eerst foto‟s te selecteren als onderdeel van het bestel proces, 104/164


kiezen we na het uploaden van de foto‟s op „Registreren‟.

Het inlogscherm dat we dan te zien krijgen heeft een ander adres en lijkt erg op het vorige scherm. Echter op dit scherm wordt twee keer om een e-mail adres gevraagd.

[https://foto.hema.nl/web/20349612/owRegistration.do]

Registeren is niet mogelijk omdat volgens de site het e-mail adres ongeldig is.

Als we coverage op functie niveau hadden gekozen, hadden we de functie inloggen wel getest. Waarschijnlijk hadden we echter voor één van de twee opties gekozen. Door alle schermtransities langs te lopen wordt de tester gedwongen om beide opties te testen. In dit geval is dit blijkbaar niet gebeurd; de fout treedt op in de productie omgeving (datum: 4 mei 2008).

105/159


Opgave 10: PCT ‘Verzenden’ Ontwerp logische testgevallen aan de hand van de testontwerptechniek PCT. Doe dit voor het flowdiagram van de functie Bereken Sanctie, Zie omschrijving CSS (par. 2.4).

START

Y 1. Eerste beschikking?

Eerste beschikking=Y als Datum_verstuurd = null

Y

N

2. Rappel? Rappel =Y als Datum_verstuurd < Datum – 10 dagen en Datum_rappel_1= null en Betaalstatus = 0

Y

N 4. Bereken Sanctie 3. Deurwaarder procedure ?

Deurwaarder = Y als Datum_rappel_1< Datum – 10 dagen en Datum_rappel_2 = null en Betaalstatus = 0

Y

5. Aanmaken Brief ‘Deurwaarder’

6. Aanmaken Rappel

7. Aanmaken Bechikking

N

8. Verzenden Batch ?

9. Andere registraties ?

Y

N 10. Verzenden Aangemaakte berichten

N

Eind

Vraag 10a Voor testdiepte = branch coverage (maat-1) geldt dat de paden die leiden tot de beslissingen 1, 2, 3, 8 en 9 moeten gedekt worden. De paden kunnen als volgt worden gedefinieerd. testcase 1 2 3

pad 1, 7, 8, 10 1, 2, 4, 6, 8, 10 1, 2, 3, 5, 8, 9, 1, 2, 3, 8, 9, 10

scenariobeschrijving enkele verzending eerste beschikking enkele verzending rappel batch zending deurwaarderbrief (laatste registratie)

Vraag 10b

106/164


Bij statement coverage worden alle states 1 maal uitgevoerd. Dit komt overeen met eerste orde State Transition (ST) testen. testcase 1 2 3

pad 1, 2, 3, 5, 8, 9, 10 1, 2, 4, 6, 8, 10 1, 7, 8, 10

Scenariobeschrijving batch zending deurwaarderbrief (laatste registratie) enkele verzending rappel Enkele verzending eerste beschikking

Merk op dat het pad 9-1 niet is opgenomen. Omdat dit pad opnemen geen extra statement afdekt in de testen

Vraag 10c Als we de branch coverage testen willen uitbreiden naar condition coverage komen er een aantal testgevallen bij. Bij condition coverage bepalen de condities de uitkomst van de beslissing. In dit geval zouden er nog de beslissingen t.a.v. de berekening van de rappel, voor het versturen van de deurwaardersbrief (fig. 4) ook getest moeten worden. Hierbij dus de volgende testen ook gedaan worden: Voor Eerste beschikking: Dit is een enkelvoudige conditie, dus uitbreiding naar condition coverage levert geen extra testgevallen op t.o.v. branch coverage Voor Rappel: De condities bij het beslispunt 2 zijn van de vorm (A en B en C) A Datum_verstuurd< datum-10 1 0 1 1

B Datum_rappel=null

C Betaalstatus=0

1 1 0 1

1 1 1 0

De volgende mogelijkheden zijn ook mogelijk, maar met bovenstaande vier testgevallen heeft elke conditie één keer de uitkomst bepaald, voor WAAR en één keer de uitkomst bepaald voor ONWAAR. 1 0 0 0

0 1 0 0

0 0 1 0

Voor Deurwaarder: De condities bij het beslispunt 3 zijn van de vorm (A en B en C) A Datum_verstuurd< datum-10 1

107/159

B Datum_rappel=null

C Betaalstatus=0

1

1


0 1 1

1 0 1

1 1 0

De volgende mogelijkheden zijn ook mogelijk, maar met bovenstaande vier testgevallen heeft elke conditie één keer de uitkomst bepaald, voor WAAR en één keer de uitkomst bepaald voor ONWAAR. 1 0 0 0

0 1 0 0

0 0 1 0

Vraag 10d Bij maat 2 coverage worden alle combinaties tussen 2 opvolgende paden getest. In dit geval houdt het in dat voor alle combinaties van de states 1-8 en 10 en de 2 testcases moeten worden gemaakt. Dus: statement 1: Voor beslispunt: Start-1 en 9-1, Na beslispunt: maar 1 mogelijkheid statement 8: Voor beslispunt: 3-8, 5-8, 6-8, 7-8, Na beslispunt: 8-9 en 8-10. statement 10: Voor beslispunt: 8-10, 9-10, Na beslispunt: maar 1 mogelijkheid

Het nut van testen van paden II Bij de uitwerking van de state transition testing is het voorbeeld gegeven van het inlog scherm van de Hema fotoservice. Deze fout zou ook goed gevonden kunnen worden met PCT. Bij PCT worden alle functionele paden door het systeem getest. Branch coverage op de beslissing „reeds ingelogd? j/n‟ in het process-flowdiagram, zou ook afdwingen om beide situaties te testen. Merk hierbij op dat als er use cases waren gebruikt bij het specificeren van de inlog Functionaliteit, het in het proces. aanmelden, vast een alternatief scenario in de use case geweest zou zijn.

Opgave 11: C/E ‘Automatische registratie’ Zie ook opmerkingen bij opgave 12.3 Vraag 11a In onderstaand fragment uit de CSS specificatie zijn condities (rood) en acties (groen) aangegeven Input Inkomende queue van het CSS Verwerking Het CSS controleert de inkomende queue met de geconfigureerde frequentie en 108/164


verwerkt alle in de queue aanwezige berichten. Als er een file aanwezig is wordt achtereenvolgens: 1) De file gecontroleerd 2) Bijbehorende persoonsgegevens opgezocht 3) De sanctie berekend Als voor elk van de records deze stappen zonder fouten zijn doorlopen worden de gegevens opgeslagen in de Registratie DB. Het originele bericht wordt verwijderd. Als er een foutmelding optreedt wordt het bericht opgeslagen in de gedefinieerde directory. Output Gegevens in Registratie DB of in het geval van fouten het originele XML bericht in gedefinieerde directory.

Daarnaast staat in sectie 2.8: De volgende foutmeldingen worden bijgehouden door het systeem:      

File formaat onjuist (invoer voldoet niet aan restricties) Registratie informatie (invoer voldoet niet aan restricties) Kenteken niet gevonden NAW niet gevonden Sanctie te laag Betaling komt niet overeen

Moet ik ook andere specificatie onderdelen betrekken bij de functie waarvoor ik testen ontwerp? Bij deze opgave worden de verschillende fouten die opkunnen treden in een aparte paragraaf van de specificatie gedefinieerd. Sectie 2.8 van de CSS specifiactie omschrijft de foutafhandeling. Er is hier gekozen om deze informatie op te nemen in de testen van de automatische registratie. We kunnen ervoor kiezen om dit niet te doen, dan:  Reduceren we het aantal acties in de beslissingstabel (A2, A3 en A4 worden dan samengevoegd tot één actie: “foutmelding” (merk op dat aangezien het aantal condities gelijk blijft, het aantal testgevallen niet afneemt)  Als we de foutafhandeling willen testen, zullen we testgevallen moeten bedenken om de specifieke foutmeldingen op te genereren. Dit zijn precies die testgevallen die we nu doorlopen voor het testen van de automatische registratie. Het lijkt daarom efficiënt om de foutafhandeling erbij te betrekken.

109/159


Vraag 11b De volgende beperkingen zijn van toepassing: Condities C1: File aanwezig C2: File controle OK C3: NAW gevonden C4: Sanctie berekend zonder foutmelding

Acties A1: foutmelding: invoer voldoet niet aan restricties A2: foutmelding: kenteken niet gevonden A3: foutmelding: NAW niet gevonden A4: foutmelding: Sanctie te laag A5: bericht opslaan voor latere verwerking A6: gegevens opslaan en verwijdering origineel A7: wacht op file Vraag 11c Er zijn 4 condities. Er zijn dus formeel 2 tot de macht 4 = 16 verschillende testen.

110/164


111/159

Geval 4

Geval 5

Geval 6

Geval 7

Geval 8

Geval 9

Geval 10

Geval 11

Geval 12

Geval 13

Geval 14

Geval 15

Geval 16

A1: foutmelding: invoer voldoet niet aan restricties A2: foutmelding: kenteken niet gevonden A3: foutmelding: NAW niet gevonden A4: foutmelding: sanctie te laag A5: bericht opslaan voor latere verwerking A6: gegevens opslaan en verwijdering origineel A7: wacht op file

Geval 3

C1: File aanwezig C2: File controle OK C3: NAW gevonden C4: Sanctie berekend zonder foutmelding

Geval 2

Condities/ Acties

Geval 1

Vraag 11d De beslissing tabel komt er dan als volgt uit te zien:

1

1

1

1

1

1

1

1

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

0

1

1

1

1

0

0

0

0

1

1

0

0

1

1

0

0

1

1

0

0

1

1

0

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

1

0

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x


Opmerkingen: Bij testgeval 3: onduidelijk gespecificeerd: er is een fout gedefinieerd voor het niet kunnen vinden van het kenteken, en voor het niet kunnen vinden van persoonsgegevens bij een bestaand kenteken. De aanname is gemaakt dat A3 altijd optreed als A2 het geval is. Als dit afzonderlijke testsituaties zijn, splitst testgeval 3 zich op in twee individuele testgevallen. Bij testgeval 5-8: aangenomen wordt dat de controle stopt bij de eerste falende check. De situatie waarbij er meerdere fouten optreden wordt dus niet afzonderlijk getest, omdat de tweede fout niet gevonden wordt, nadat de eerste is geconstateerd. Hierdoor onderscheiden testgeval 5-8 zich niet van elkaar. Bij testgeval 9-16: Als er geen file in de queue gevonden wordt, is de functie „idle‟. De testgevallen 9-16 onderscheiden zich niet van elkaar. Vraag 11e Op basis van de opmerkingen bij vraag 9d kunnen we de niet onderscheidende testen verwijderen.  De testgevallen 5-8 onderscheiden zich niet van elkaar, dus alleen 5 wordt uitgevoerd  De testgevallen 9-16 onderscheiden zich niet van elkaar, dus alleen 9 wordt uitgevoerd Het uiteindelijke resultaat is dan als volgt: Condities/ Acties C1: File aanwezig C2: File controle OK C3: NAW gevonden C4: Sanctie berekend zonder foutmelding

Geval 1 1 1 1 1

A1: foutmelding: invoer voldoet niet aan restricties A2: foutmelding: kenteken niet gevonden A3: foutmelding: NAW niet gevonden A4: foutmelding: sanctie te laag A5: bericht opslaan voor latere verwerking A6: gegevens opslaan en verwijdering origineel A7: wacht op file

Geval Geval 2 3 1 1 1 1 1 0 0 1

Geval 4 1 1 0 0

Geval Geval 5 9 1 0 0 1 1 1 1 1

x x x

x

x

x

x x

x

x x

112/164


Opgave 12: Bevindingen a) Bevinding 1: S5: Overtreding wordt uitgerekend zonder correctie (BVA) b) Bevinding 2: S7: Seponeren van betaalde sanctie is mogelijk zonder restitutie te verlenen. (state) c) Bevinding 1: S2: Invoeren van afwijkende kenteken-format wordt ten onrecht geaccepteerd. (syntax) d) Bevinding 4 S4: Rappel verstuurd zonder verhoging van de sanctie (PCT) e) Bevinding 5 XML interface: 20% van de aangeboden overtredingen wordt niet verwerkt. (performance, loadtesten)

Opgave 13: Tarieven calculator

Zaken op te testen zouden kunnen zijn:  ST: werken alle scherm transities. Denk hierbij aan de links boven aan de pagina, en recht in het menu. Maar ook de link „kilopost Internationaal‟. Hoe wordt opgegaan de „back‟optie in de internet browser. Berekent de calculator altijd het tarief aan de hand van de getoonde gegevens, of bij gebruik van de back toets met oudere gegevens.  ST: het enablen en disabelen van de opties die wel/niet geselecteerd mogen worden. Merk op de op deze site de radio buttons voor Aangetekend verkeerd gebruikt worden. Normaal hoort een radio button of in de ene, of in de andere stand te staan. Bij deze implementatie is het ook mogelijk om de radio button twee keer aan te klikken, de optie gaat dan uit. De keuze mogelijkheid „met of zonder bericht van ontvangst wordt dan disabled. Een nettere implementatie zou een derde radio button introduceren met de optie „Niet aangetekend‟.

113/159




 

  

Het invoeren van de waarde van een aangetekend poststuk. Wat zijn de invoer restricties (Syntax), afhankelijk van de ingevoerde waarde, maken de kosten bepaalde sprongen, welke grenswaarden gelden hier? (BVA). Wat is de maximale waarde die ingevoerd mag worden? Test verschillende maximale waarden, voer de maximale waarde voor een land in, en selecteer vervolgens een land met een lagere maximale waarde (PCT). Is dit veld optioneel, en kan het leeg gelaten worden? (EP of Syntax). Test het berekenen van een internationaal tarief, bij het selecteren van België als bestemming, kan dat, mag dat? Het invoeren van het aantal poststukken. Mag dit veld leeg blijven of 0 zijn? Test het invoeren van niet numerieke karakters, decimalen en voorloopnullen. (BVA, Syntax), wat is het maximaal aantal poststukken, worden kwantum kortingen goed berekend bij grotere aantallen, en zijn de grenswaarden goed geïmplementeerd? (BVA). Controleer de berekening voor verschillende bestemmingen. Klopt de uitkomst. Test of in de verschillende talen Frans, Engels, Nederlands de berekende tarieven gelijk zijn. Security settings: vereist de applicatie bepaalde security settings? Als ik deze strikt zet, werkt de applicatie dan nog? Interoperabiliteit: Hoe werkt de applicatie in verkeerde browsers?

Enkele Bevindingen aan de Tarieven calculator (zoals geconstateerd op 21-07-08) 1.

Het is mogelijk een waarde in te vullen bij „aangetekend met aangegeven waarde‟ terwijl deze optie niet geselecteerd is:

114/164


2. Het is mogelijk de <------------------------------------------------------> te selecteren bij land.

Overigens wordt er wel een foutmelding gegeven bij de berekening van de prijs:

3. Bij het selecteren van een aantal landen (bv. Albanië) wordt de knop „Aangetekend met aangegeven waarde‟ disabled. Wanneer het land van bestemming gewijzigd wordt blijft deze knop disabled. Wanneer er een berekening wordt gemaakt voor een verzending zónder de optie „aangetekend met aangegeven waarde‟ en er wordt van het scherm waarop de berekening is weergegeven op „vorige‟ gedrukt terug naar het scherm waarin de invoer moeten worden gegeven, is het bij hetzelfde land wél mogelijk om de optie „Aangetekend met aangegeven waarde‟ aan te vinken. Wanneer deze invoer gegeven wordt en er op „bereken prijs‟ geklikt wordt, wordt er een foutmelding weergegeven.

115/159


4. Wanneer er vanuit het scherm waarop de berekening wordt weergegeven via de knop „vorige‟ teruggekeerd wordt naar het invoerscherm zijn in dit scherm de knoppen „Met bericht van ontvangst‟ en „zonder bericht van ontvangst‟ disabled. 5. Het is mogelijk een negatief bedrag in te vullen bij „Aangetekend met aangegeven waarde‟. In de berekening van de prijs wordt dit als een 0 beschouwd. 6. Het is mogelijk een negatief bedrag in te vullen bij ‘Aantal brieven

(kaarten) dat u wenst te versturen’. In de berekening van de prijs wordt het bedrag per brief ook daadwerkelijk vermenigvuldigd met dit negative getal waardoor er een negatieve totaalprijs uitkomt. 7. In de Nederlandstalige versie is het links bovenin mogelijk om voor de Duitstalige of Franstalige versie te kiezen. Wanneer de Duitstalige versie gekozen wordt komt er plotseling ook een Engelstalige versie beschikbaar.

De Nederlandstalige versie

De Duitse versie, waarbij ook een Engelstalige versie beschikbaar komt

116/164


Opgave 14: PCT en Unittesten Op www.testgoal-educatief.nl is een ondersteunende excel-sheet beschikbaar. De excel-sheet 'bereken restschuld' genereert de output zoals deze in de opgave is omschreven aan de hand van de input variabelen. Tevens geeft de sheet een indicatie van de testdekking.

Opgave 14a START

1. n=0

2. Vraag Totaalbedrag, Percentage, Renteboete

3. Vraag TermijnBedrag

8. Extra aflossing > Totaalbedrag/20 OF Termijn < 10

4. Extra aflossing?

J

5. Vraag Extra Aflossing TermijnExtraAflos sing

6. A of B ?

J

N

7. Percentage = Percentage + RenteBoete

N

J

8. Schuld= Totaalbedrag

9. n =n+1

10. Rente= Percentage* Schuld

13. ExtraAflossing>0 EN n=TermijnExtraAflossng?

11. Rente >= TermijnBedrag N 12. Schuld+Rente > TermijnBedrag

13. A en B ?

N

N

18. TermijnBedrag = Schuld + Rente

15. Aflossing = TermijnBedrag – Rente

Einde

117/159

J

16. Schuld = Schuld – Aflossing

J

14. Schuld= Schuld – ExtraAflossing

Y


Onderstaand is [er regel in de code aangegeven bij welk statement in het flow diagram deze regel hoort:

1. 2. 3. 4.

5. 6. 7. 8. 9. 10. 11. 12.

13.

14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.

START N=0 GET TotaalBedrag GET Percentage GET RenteBoete

START 1 2 2 2

VRAAGAFLOSSINGSGEGEVENS GET TermijnBedrag

3

IF (ExtraAflossing) { GET ExtraAflossing GET TermijnExtraAflossing

5 5 5

IF (ExtraAflossing > TotaalBedrag / 20 OR TermijnExtraAflossing < 10) { Percentage = percentage + RenteBoete } } Schuld = TotaalBedrag; BEREKENVOLGENDETERMIJN N=N+1 Rente = Percentage * Schuld IF (Rente >= TermijnBedrag) { GOTO VRAAGAFLOSSINGSGEGEVENS } IF (Schuld + Rente <= TermijnBedrag) { TermijnBedrag = Schuld + Rente GOTO EINDE } IF (ExtraAflossing AND N = TermijnExtraAflossing ) { Schuld = Schuld - ExtraAflossing } Aflossing = TermijnBedrag - Rente Schuld = Schuld - Aflossing GOTO BEREKENVOLGENDETERMIJN EINDE

6 6 7

8

9 10 11 Pad 11-3 12 18

13 13 14 15 16 Pad 16-9 EINDE

118/164


Opgave 14b Met één pad kunnen alle statements in het flowdiagram geraakt worden. Testgeval 1: 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-9-10-11-12-18 Niet opgenomen in dit pad zijn :  4-8  6-8  11-3  13-15 Opgave 14c Met onderstaande gegevens is het hele pad te doorlopen  Totaal bedrag 100000  Rente percentage 0,06  Termijn bedrag 20000  Extra aflossing 100  Termijn 4  Renteboete 0,01 Opgave 14d Er zijn geen regels in de code die met statement coverage niet geraakt worden. Bij statementcoverage worden immers alle statements geraakt. De paden door de flow die niet geraakt worden, zijn de lege ELSE takken. Op het eerste lijkt statement coverage een mooie dekking te hebben. In de broncode zijn geen regels aan te wijzen die niet getest zijn. Echter, .... uit het flowdiagram valt op te maken dat er wel degelijk paden door het systeem te maken zijn, die invloed hebben op de werking. Deze worden wel gedekt met zwaardere technieken, zoals branch coverage, condition coverage en maat 2. Opgave 14e De paden die bij statement coverage niet zijn opgenomen, dienen bij branch coverage wel te worden geraakt. Bijvoorbeeld met de volgende paden: Testgeval 1

Testgeval 2

Scenario Twee keer termijn invullen, omschrijving Extra aflossing in 1 termijn betaald

Extra aflossing met Renteboete, meerdere aflossingstermijnen

Paden

1-2-3-4-5-6-7-8-9-10-11-12-

1-2-3-4-5-6-8-9-10-11-3-4-89-10-11-12-18

Als N ≠ Aflossingstermijn: (13-15-16-9-10-11-12) Als N = Aflossingstermijn: (13-14-15-16-9-10-11-12) -18

119/159


Merk op Er zit een afhankelijkheid in de paden. Als je een pad definieert waarbij zoals in testgeval 1 de aflossing zodanig is dat je 1 termijn afbetaald (Statement 12 is niet waar), kom je nooit bij statement 14. Deze kunnen dus niet in één testgeval gecombineerd worden. Tip: door een omschrijving toe te voegen aan het scenario, trigger je jezelf om deze afhankelijkheden. Bij abstracte paden, waarbij je deze scenario omschrijving niet meeneemt, is de kans aanzienlijk groter dat je onmogelijke paden definieert.

Opgave 14f Fouten die je zou kunnen vinden zijn ondermeer: 1. Als je een terug loop maakt (regel 16 in de code) wordt de telling van de termijn niet meer terug gezet. Dit gebeurt immers in statement 1. (regel 1 in de code) 2. Als je een terug loop maakt (regel 16 in de code) kan het voorkomen dat statement 7 twee keer wordt uitgevoerd, de renteboete wordt dan twee keer toegepast (regel 11 in de code). 3. Als het termijnbedrag en ExtraAflossing > Schuld + Rente blijft er geld over die de bank zou moeten terug betalen. Dit staat niet gespecificeerd. Overigens wordt de extra aflossing waarschijnlijk nooit meegenomen, want statement 14 zit niet in de loop (regel 22 in de code). 4. In statement 5 wordt de TermijnExtra aflossing gedeclareerd. Als er geen extra aflossing is, zal deze variabele onbekend zijn, in statement 15 treed er vervolgens een fout op (regel 23 in de code). Met enig spelen zijn er echter wel meer foutsituaties te creëren. Opgave 14g Bij condition coverage zijn er testgevallen nodig voor beslissingen 6 en 13. Beslissing 6: Extra aflossing > Totaalbedrag/20 OF Termijn < 10, Dus:

(Niet A, B) (A, Niet B) (Niet A, Niet B)

A Extra aflossing > Totaalbedrag/20 0 1 0

B Termijn < 10

OF

1 0 0

True True False

Beslissing 13: . ExtraAflossing EN n=TermijnExtraAflossing Dus:

(Niet A, B) (A, Niet B) (A, B)

A ExtraAflossing 0 1 1

B n=TermijnExtraAflossing 1 0 1

EN False False True

120/164


Typische fouten die je niet zou vinden bij minder sterke coverage (bv branch en statement) zouden zijn: 1. Bij beslissing 6: Als je een Extra aflossing definieert van die groter is dan Totaalbedrag/20 (regel 10 van de code), dan wordt er een Renteboete toegepast, een fout in regel 10 van de code, bijvoorbeeld Termijn =< 10, zal in dit geval niet noodzakelijkerwijs gevonden worden, omdat ongeacht wat de waarde is van deze stelling, er toch renteboete wordt toegepast. Bij branch is het testen van (Niet A, B) en (Niet A, Niet B) voldoende om alle paden een keer doorlopen te hebben. 2. Bij beslissing 6: Als in de fout zit in criterium B, wordt deze niet gevonden als op basis van criterium A de stelling al onwaar is. Bijvoorbeeld als er onterecht n >TermijnExtraAflossing is geïmplementeerd in regel 21 van de code wordt deze niet noodzakelijkerwijs gevonden bij branch. Als er bij branch wordt gekozen voor het testen van (A, Niet B) en (A,B) zijn immers alle paden gedekt.

121/159


12.4

Aantekeningen

122/164


13

Het Fysieke Testontwerp

13.1

Zelftoets

Vraag 1. Verschil tussen een logische en fysieke test. Een Fysiek testgeval omschrijft hoe de test moet worden uitgevoerd, hierin staan de acties, condities en inputdata beschreven. Een logische test omschrijft wat er getest moet worden aan de hand van de TRA en de Testboom. De volgorde is eerst een logisch test en vervolgens een fysieke test, al is het niet altijd mogelijk en verplicht om een logische test te doen. Vraag 2. Een goed gestructureerde fysieke testontwerp heeft als voordeel dat het overzichtelijk is (dit helpt bij het maken van een heldere testrapportage) en de onderdelen gemakkelijk terug te vinden zijn in de testbasis (dit is belangrijk bij de testuitvoering). Verder wordt de onderhoudbaarheid vergroot (dit zorgt voor een up-to-date testset). Vraag 3. In een fysiek test zijn de volgende velden belangrijk:  ID fysiek testgeval  Doel van de test  Preconditie  Testacties  Postconditie maar ook,  Verwijzing naar testbasis  Verwijzing naar positie testboom  Kwaliteitsattribuut  Verwijzing naar configuratie Vraag 4. De omschrijving van een testdoel moet voldoen aan:  De situatie die getest wordt  De verwachte en goede systeemreactie Uit de omschrijving moet dus helder zijn wat er getest wordt en wat het resultaat hoort te zijn. Het hoort ook overeen te komen met het desbetreffende logisch testgeval. Vraag 5. De test resultaten worden terug naar het beoogde resultaat herleid door een duidelijke structuur. Te beginnen bij de testboom, en vervolgens door ervoor te zorgen dat elk testgeval terug te leiden is naar de testboom. Dit onder meer door in het fysieke testgeval een referentie op te nemen naar het logische testgeval en de specificatie, en in het logische geval een referentie op te nemen naar de positie in de testboom. Vraag 6. Beschrijft het resultaat dat verwacht wordt als het systeem functioneert zoals het is ontworpen. Doe dit door onder meer de actie op te nemen die het systeem uitvoert en wie hiermee geconfronteerd wordt. Bijvoorbeeld:

123/159

Hoofdstuk - Het Fysieke Testontwerp





Het systeem toont de gebruiker een foutmelding om aan te geven dat de datum ongeldig is. Een reserveringsaanvraag wordt naar het bibliotheeksysteem gestuurd. Het resultaat van de berekening (Antwoord = 42) wordt getoond aan de gebruiker. De gewijzigde boekstatus wordt opgeslagen in de database.

13.2

Opdrachten

 

Voor het uitwerken van de fysieke testgevallen kan de bijbehorende template gebruikt worden. Deze is beschikbaar op www.testgoal-educatief.nl. Opdracht 1 Afhankelijk van de bedachte testen kunnen de fysieke uitwerkingen erg uiteen lopen. Let bij het controleren op de aandachtspunten die genoemd zijn in opdracht 2. Opdracht 2 Let o.m. op de volgende eigenschappen van een fysiek testgeval:         

It should indicate the purpose of the test Test action describes the action that the tester should undertake The expected system reaction can be checked Lists the test data to be used and its functional purpose Test results can be traced back to anticipated result Contains an indication for regression testing Contains a reference to used configuration Has a unique ID Describes pre-condition

124/164


Bij testgeval 86

Doel van de test Preconditie

Postconditie Referentie naar de Testbasis Referentie naar Logische testontwerp

testacties

Verwachte systeemreactie

125/159

Omschrijft wel wat er gebeurd, maar niet wanneer de test ook geslaagd is Pre-conditie is geformuleerd als een activiteit, i.p.v. een conditie. Tevens is het onduidelijk welk bestand er aangeboden dient te worden, of welke eigenschappen dit bestand heeft. Er is niet gespecificeerd waar dit bestaand aangeleverd dient te worden. Is niet ingevuld. Bevat geen versienummer Er is geen referentie ingevuld, betekend dit dat er geen logisch ontwerp gemaakt is, of dat de referentie niet is ingevuld? Vul bijvoorbeeld „n.v.t‟ om aan te geven dat er geen LTO is. Beide testacties zijn niet omschreven als activiteiten. Actie 1: benoemd een file, wat moet ermee gebeuren, wat zijn de eigenschappen van de file. Actie 2: dit is eigenlijk een verwachte systeemreactie en geeft geen informatie over wat de tester moet doen. Deze test kan worden uitgebreid door aan te geven welke fout (exacte string) er waar te vinden is. Tevens is de zin


Regresietestset indicatie

moeilijk interpreteerbaar; is de foutmelding „NAW „niet gevonden of is de foutmelding „NAW niet gevonden‟. Ontbreekt.

Testgeval 87 bevat dezelfde test als testgeval 86, maar dan uitgewerkt zodat:  Duidelijk is waneer de test geslaagd is: als de XML is opgeslagen  De preconditie duidelijk is: XML-file met onbekende NAW gegevens in de in-queue (bestand: reg-invalid-naw v09.xml). De eigenschappen van de file zijn logisch omschreven en er is een referentie opgenomen naar een voorgedefinieerde file die eventueel gebruikt kan worden.  Er is een postconditie ingevuld die controleerbaar is  Er is een referentie opgenomen naar de Testbasis incl. versienummer van de specificatie.  Er is een referentie opgenomen naar bovenliggend logisch testontwerp.  Er is een referentie opgenomen naar de gebruikte configuratie (die bijvoorbeeld de directory van de in-queue en de directory waar het niet verwerkte bericht wordt opgeslagen vastlegt)  De testacties beginnen met een „actie‟zoals maak, plaats, controleer, check.  De verwachte systeemreactie is omschreven zodat deze controleerbaar is: bijvoorbeeld door het noemen van de exacte string van de foutmelding, de omschrijving van de regel in het fout-log.

126/164


In de fysieke testgevallen kan gebruik gemaakt worden de volgende notering:

Een veld met een waarde die op dit moment niet bekend is, maar waarvan logisch af te leiden is wat de goede waarde zou moeten zijn. Bijvoorbeeld bij datum en tijd velden. Er is van tevoren niet te vertellen op welke dat de test uitgevoerd wordt, maar de datum in het veld, dient overeen te komen met de .

„naam‟

Exacte string die gebruikt wordt, bijvoorbeeld bij de invoer van een veld, of de foutmelding die getoond wordt.

[naam]

De naam van een button of menu-item dat geselecteerd dient te worden door de tester.

Mogelijke verbeteringen aan bovenstaand testgeval: Formeel zou ook gecontroleerd moeten worden of de file ook echt niet verwerkt wordt. Dit zou een extra testactie opleveren in de trant van: 6 In menu selecteer [overzicht]. 7 Voer in het kenteken zoals gebruikt in de aangeboden xml-file, selecteer [zoek].

S5 Registratieoverzicht wordt getoond. Er zijn geen correspondeerde zoekresultaten (het resultaten scherm blijft leeg)

Opgave 3 Actiewoord gedreven testen is o.m. uitgelegd in hoofdstuk testautomatisering van het TestGoal boek. Zie eventueel ook:  http://www.computable.nl/artikel.jsp?rubriek=1272857&id=1368602 Opgave 4 en verder Afhankelijk van de bedachte testen kunnen de fysieke uitwerkingen erg uiteen lopen. Let bij het controleren op de aandachtspunten die genoemd zijn in opgave 2.

127/159


13.3

Aantekeningen

128/164


14

Testdata

14.1

Zelftoets

Vraag 1. De 4 soorten testdata zijn: 1. Invoer- en uitvoerdata: bijv BVA grenswaarden 2. Operationele data: bv. ST testcase waarden 3. Configuratie data: bijv. Login-gegevens, registratienummers 4. Metadata: bijv. Globale gegevens zoals licenties Vraag 2. Bij het deployen van een systeem zal configuratie data nodig zijn, omdat hiermee de instellingen van het testsysteem worden gewijzigd. Daarnaast zal metadata nodig zijn, om te zorgen dat een bepaalde configuratie daadwerkelijk mogelijk is Vraag 3. Operationele data is gebruikt:  bij installatie , door de DB te vullen met precondities voor de uit te voeren testen. Dit kan productie data zijn, of fictieve testdata.  bij de testuitvoering als pre-conditie (uitgangssituatie).  Opmerking: bij Performance test kan de DB grote van invloed zijn. Dus hier kan het belangrijk zijn om de DB te vullen, zonder dat deze data direct gebruikt wordt bij een uit te voeren test. Vraag 4. In praktijk blijkt dat sommige fouten vaak pas gevonden worden op het moment dat er een realistische dataset gehanteerd wordt. De testdata is daarom bij voorkeur vergelijkbaar zijn met de productiedata. Als er grote verschillen zijn tussen de productiedata en de fictieve testdata, kan het zijn dat een test een andere uitkomst heeft , waardoor fouten pas opgemerkt worden op het moment dat er productie data gebruikt wordt. Vaak is dit in de productie omgeving, en dat is rijkelijk laat. Vraag 5. Goede testdata is altijd belangrijk omdat bij het gebruik van de verkeerde testdata het systeem mogelijk anders werkt dan zou moeten. Dit is in veel gevallen dan niet te wijten aan het systeem, maar de configuratie en gebruikte invoer. Dit soort fouten, kosten veel tijd en vertragen de testuitvoering, terwijl ze geen toegevoegde waarde hebben voor het testtraject. Dit dient dus voorkomen te worden. Het voorbereiden van testdata zorgt ervoor dat testen sneller en beter uitgevoerd kunnen worden, bijvoorbeeld door duidelijk de pre-condities te definiëren en deze mogelijk al in de database van het systeem beschikbaar te stellen.

129/159

Hoofdstuk - Testdata

Ongelukkig gebruik van testdata kan er vervolgens voor zorgen dat bepaalde fouten niet gevonden worden. Denk bijvoorbeeld aan het gebruik van diakritische tekens, lange strings in bv de rapporten die gegenereerd worden, of de definitie van gebruikers rollen (zie ook het voorbeeld in het boek over dit onderwerp) Een tester kan tijdens het handmatig testen de (incorrecte) data op de juiste manier interpreteren en waar nodig aanpassen. Echter, zelfs een „slim‟ script is in wezen „niet intelligent‟ en kan dus niet anticiperen op onvoorziene invoer. Hierdoor is het belangrijk dat de data bij een geautomatiseerde test 100% correct is. Vraag 6. Een testdata respository is een centrale opslagplaats voor testdata. Het bevat alle testdata. Omdat de verschillende soorten testdata gerelateerd zijn is het handig om ze in één opslagplaats te houden. Een repository kan een Database zijn, maar dit hoeft niet altijd het geval te zijn. Ook een Excel-werkblad of een Word document, kan bij overzichtelijke systemen als testdata repository voldoen.

14.2

Opdrachten

Opdracht 1. Argumenten voor en tegen anonimiseren van de testdata Voor Tegen Reduceert het risico dat derden inzicht Verschil met productiedata, niet hebben in vertrouwelijke informatie, of realistisch. Vergroot de kans op fouten in dat deze informatie uitlekt. Denk productie. bijvoorbeeld aan wie kredieten heeft, wie een strafblad heeft, e.d.. Helderheid van data tijdens testen als er bijvoorbeeld duidelijke rol namen worden gekozen.

Kan onrealistische fouten opleveren als het anonimiseren niet correct gebeurt.

Kan wettelijk verplicht zijn, i.v.m. met privacy wetgeving

Is een extra bewerkingstap, kost dus tijd en geld. Bij ketentesten worden systemen gekoppeld. De gebruikte testdata dient dan op beide systemen overeenkomstig te zijn. Dit houdt in dat over de hele keten de data geanonimiseerd dient te zijn, en op dezelfde wijze. Dit is complex en soms zelfs onmogelijk.

130/164


Opdracht 2. Type testdata Invoer- en uitvoerdata

Operationele data

Beantwoorden van mailtjes Wordt het e-mail adres van de afzender vanzelf in het „naar‟- veld geplaatst. Dus invoer data is: e-mail adres. Een bericht in de inbox

Configuratie data

Is er het een bestaand e-mail adres Maar ook bv. proxyserver instellingen en de ‟log-on security‟ settings

Metadata

De opties van de ‟log-on security‟ settings, zie screenshot

Screenshot van e-mail –security settings:

131/159

Hoofdstuk - Testdata

Opdracht 3. Type testdata Invoer- en uitvoerdata

Bereken sanctie Uitvoer: het bedrag van de sanctie Invoer: kenteken

Operationele data

Een overtreding van het type 1. Een sanctie met status beschikking verzonden.

Configuratie data

De hoogte van de eerste rappel.

Metadata

Betaal statussen die geselecteerd kunnen worden, dus Sanctie betaald, geseponeerd.

S6: Betaalstatus wijzignen Pleeg datum

Kenteken

Sanctie

19-10-2007

23-XZ-14

135

Wijzig de huidige betaalstatus naar:

Betaald Betaald Geseponeerd

Ontvangen bedrag Rijbewijs ontvangen

Wijzigen

Annuleren

Screenshot van het CSS scherm waar de betaalstatus wordt gewijzigd, de pull-down wordt gevuld met metadata die afkomstig is uit een tabel in de systeemdatabase. Opdracht 4. Bij het bespreken van de Testdata is er primair uitgegaan van volledig uitgeschreven testen. Als er unscripted testing wordt toegepast, zoals het geval is bij Exploratory testen, wat is dan het belang van voorgedefinieerde Testdata? In het algemeen geldt dat voorgedefinieerde in- en uitvoerdata van ondergeschikt belang worden. De testen worden pas tijdens de testuitvoering bedacht. Er is dus weinig voorbereiding mogelijk. Het is natuurlijk wel belangrijk dat de Testomgeving goed geconfigureerd is. De voorgedefinieerde configuratie- en metadata kunnen wel goed worden gebruikt. De operationele data beschrijft de uitgangssituatie van de test. Het kan handig zijn om ook bij unscripted testing een aantal uitgangssituaties klaar te hebben staan. Dit voorkomt dat er veel tijd verloren gaat met het creëren van de precondities. De exploratorytesters kunnen zich dan richten op het uitvoeren van de testcharter. Optioneel kan de uitgangssituatie zelfs in de ET-testcharter worden opgenomen. Zie voor uitleg van Exploratory-testen en het gebruik van testcharters hoofdstuk 12.

132/164


14.3

133/159

Aantekeningen

Hoofdstuk - Testomgeving

15

Testomgeving

15.1

Algemeen

Voor het opstellen van de eisen testomgeving is checklist beschikbaar op www.testgoal-educatief.nl. De checklist kan gebruikt worden om de Eisen van de Testomgeving in kaart te brengen. De testexpert die belast is met het opzetten van de Testomgeving vult de checklist in en bespreekt deze met de testcoördinator. Samen checken ze of de eisen die aan de Testomgeving worden gesteld de gekozen Teststrategie ondersteunen. Daarna wordt de checklist besproken met de beheerder. Bij het bespreken van de ingevulde lijst vormt de beheerder zich een beeld van de benodigdheden en vult hij de lijst in overleg verder in. Aan de hand van deze eisenlijst kan besloten worden welke invulling gegeven wordt aan de omgeving en welke hardware eventueel moet worden aangeschaft. Het invullen van de checklist helpt bij het slaan van bruggen naar de systeembeheerorganisatie.

15.2

Zelftoets

Vraag 1. Een belangrijke oorzaak van het niet op tijd afronden van testprojecten of het niet behalen van het gewenste resultaat, ligt vaak in een Testomgeving die niet voldoet. Een testomgeving die niet voldoet, leidt tot bevindingen die geen uitspraak doen over het testobject. Als het systeem crasht gedurende de testuitvoer, leidt dit tot vertraging omdat testen opnieuw uitgevoerd moeten worden. Als het systeem „plat‟ ligt dan onstaat er „idle tijd‟ omdat de testers niet kunnen testen. Daarnaast kost het overleg over en het oplossen van testomgevingsbevindingen veel tijd van de betrokkenen. Niet alleen de testers, maar ook ontwikkelaars en beheerders. Vraag 2. Stukjes code die niet-aanwezige programmacode vervangen (zie ook sectie 5.9 van het testgoal boek.) Vraag 3. Een deployment cycle maakt het mogelijk om een fout direct op te lossen, en te hertesten. Dit is efficiënt en geeft snel zekerheid en leidt tot een beter product. Nadeel is dat dit proces vaak ongecontroleerd is. Het is niet bekend welke fouten er zijn gevonden, wanneer deze is opgelost en of de opgeloste fout belangrijk was. De wens om meer controle te hebben over de bevindingen die opgelost worden en om de stabiliteit van de omgeving te vergroten, leidt tot een bevindingenbeheerproces, de tijd die het kost om hiermee een opgeloste bevinding op de testomgeving beschikbaar te hebben wordt daarmee langer, een langere deployment cycle dus. Vraag 4. Vragen die je kunt stellen zijn: 134/164


      

Welke testsoort ga ik uitvoeren? Hoe snel dient mijn deployment cycle te zijn? Wat voor testdata gaan we gebruiken? Hoeveel mensen gaan er tegelijk op de testomgeving werken? Welke rechten hebben de testers, kunnen ze bv de configuratie wijzigen of de systeemloggings inzien? Is er tooling nodig, bijvoorbeeld, stubs, drivers, simulatoren of bevindingen registratie tools Etc.

Vraag 5. Configuratiemanagement: Het proces dat ervoor zorgt dat de samenstelling van de testomgeving gecontroleerd en bekend is. Vraag 6. Het proces release management zorgt ervoor dat de wijzigingen op vastgestelde momenten plaatsvinden en er bekend is welke wijzigingen er worden doorgevoerd.

15.3

Opdrachten

Opdracht 1. Er kan gedacht worden aan de volgende benodigdheden:  De applicatie Voor functioneel – en gebruikersacceptatie testen.  Testontwerptool De testontwerptool wordt gebruikt op de fysieke testgevallen in te definiëren en uit te voeren (zie bijvoorbeeld de screenshot in figuur 13.2 van het TestGoal boek). Tevens wordt in deze tool de testdata opgenomen.  Test data Bijvoorbeeld de gegevens van de gebruikers, bestuurders, voertuigen. Denk hierbij aan alle vier typen van testdata (zie hoofdstuk 14 van het TestGoal boek)  Test tool Ten behoeve van de performance testen (zie bijvoorbeeld paragraaf 5.8)  (Simulator van de) flitspaal Het SS Systeem is verbonden met flitspaalsysteem.  Een systeem waar de applicatie geïnstalleerd gaat worden PC, waar geen productie systeem op draait.  Netwerk voorziening Waarmee de systemen (applicatie, database enz.) met elkaar gekoppeld worden.

135/159

Hoofdstuk - Testomgeving

15.4

Aantekeningen

136/164


16

Testautomatisering

16.1

Zelftoets

Vraag 1. Testautomatisering is het gebruik van testtools die de testexpert helpen in het vinden van fouten en die het testproces ondersteunen. Vraag 2. Typen testtools zijn :  Dynamische tools, zoals Quick test Pro, Winrunner, Conclusion, Selenium.  Statistische tools, zoals Jumbl.  Ondersteunende tools, zoals Jira (bevindingen registratie), Quality centre (test managment tool), maar bijvoorbeeld ook Excel. Vraag 3. Redenen om automatisch te testen:  Extra testmogelijkheden: sommige tests zijn te complex om handmatig uit te voeren, zoals uitlezen van smartcards  Tijdbesparing: sommige tests hebben teveel mogelijke testgevallen om handmatig uit te voeren, zoals security testen  Logging: om het vastleggen van testresultaten te vergemakkelijken, zoals bij performance testen  Vergelijking van resultaten met de verwachtte waarden  Grote herhaalbaarheid: het is makkelijker de resultaten te herhalen. Vraag 4.. De kosten voor testautomatisering bestaan uit de kosten voor:  Selecteren van een tool  Aanschaffen van een tool  implementeren van een tool  omscholing van testers  licentie kosten van de tool  ontwikkelkosten van de testscripts en/of tools  onderhoudskosten van de testscripts en/of tools Deze kosten worden terugverdiend door de automatische testen meerdere keren te gebruiken of voor testgevallen die complex zijn en daarom handmatig heel veel testtijd kosten. Vraag 5. De nadelen van testautomatisering zijn ook de voordelen:  niet alles is automatisch te testen  script opstelling is ook tijdsintensief, het is geen vervanging van testers  de introductie van een extra foutkans – testautomatisering is zelf fout . potentieel lage betrouwbaarheid

137/159

Hoofdstuk - Testautomatisering

 

Tools kunnen niet alle omgevingen aan niet altijd rendabel, omdat herhaalbaarheid niet gegarandeerd is

Vraag 6. Record en playback is een type tool waarbij het tool de acties van de tester registreert in een script. Vraag 7. Het nadeel van lineair scripten is dat het weinig flexibel is en de controle over de inhoud beperkt is. Vraag 8. Actiewoord gedreven testen heeft als voordeel dat scripts snel gebouwd en aan te passen zijn. Vraag 9. Parametriseren is het uit het script halen van „hard coded‟ testdata. De testdata wordt in een database of Excel-sheet gedefinieerd en door het script ingelezen. Voordelen zijn:  als de data wijzigt, hoeft het script niet verandert te worden (betere onderhoudbaarheid)  Met een script zijn meerdere testen te doen, door het script nogmaals uit te voeren met andere data (grotere efficiëntie) Vraag 10. Programmeren van scripts is noodzakelijk als er het systeem geen gebruikersinterface heeft (zoals bij smartcards, transactieverwerkende systemen of telefooncentrales) en wanneer de scripts ontwikkeld moeten worden voordat de gebruikersinterface beschikbaar is. Vraag 11. Een testharnas is en testomgeving dat het testobject afschermt en dat het testobject op meerder interfaces tegelijk aanstuurt en test.

16.2

Opdrachten

Opdracht 1. Er zijn vele tools op de markt, een willekeurige selectie: Tool naam: Testlog Leverancier: PassMark Software Type testtool: ondersteunend Voordelen:  Bekende (Explorer-achtige) interface  Uitgebreide support  Web-based (dus remote accessible)  Geen third-party databasesoftware nodig (werkt op XML) 138/164


 

Spellingchecker Conversie mogelijk m.b.v. CSV

Tool naam: Conclusion Leverancier: Collis Type testtool: dynamisch Voordelen:  Generieke tool voor geautomatiseerd testen  Bruikbaar voor verschillende typen interface.  volledig geïntegreerde shell voor het testbeheer  Een script-based testtool (geparametriseerd testen)  Stelt een volledige reeks onafhankelijk van testcases in werking  Spellchecker  Gemakkelijk leesbare testscripts  Gemakkelijk testscenario‟s vertalen in geautomatiseerde testcases  Generische API laat gemakkelijke scriptontwikkeling toe en is volledig onafhankelijk van het component dat wordt getest  Een scala aan off-the-shelf Test tools Tool naam: J Usage Model Builder Library (JUMBL) Leverancier: Java Type testtool: statistisch Voordelen:  Gemakkelijk scripts ontwikkelen en hergebruiken  Statistische analyse van de modellen kan direct worden gedaan  Testcases kunnen op verschillende manieren worden gegenereerd, zoals random, per weight, gebaseerd op coverage en in handmatig  Met TGL (Test Generation Language) kunnen gecombineerde events gegenereerd worden vanuit meerdere modellen  Scripts kunnen aangestuurd worden door externe test tools  Test cases zijn overzichtelijk georganiseerd  verwachte reliability kosten en DDR kunnen geanalyseerd worden  Tool is gebaseerd op Java Opdracht 2. De precieze vorm van de curves en daarmee ook van de locatie van het optimum, is afhankelijk van veel factoren. Denk hierbij aan de ervaring die het testteam heeft met scripting en met de gebruikte tools. Als het testteam veel ervaring heeft, zullen de ontwikkelkosten lager zijn dan bij een onervaren team. De curve met ontwikkelkosten zal minder steil lopen en het optimum zal naar rechts verschuiven. Afhankelijk van de stabiliteit van het testobject en de testbasis zullen ook de beheerkosten variëren. Bij een zeer stabiele testbasis zijn de beheerkosten misschien in ieder geval wel laag. Met het doorvoeren van een meer flexibele automatisering valt in dit geval veel minder te besparen. De curve van de beheerkosten zal dan lager beginnen en vlakker lopen, en het optimum verschuift dan naar links. Bij een Agile / Scrum project zal de testbasis erg aan verandering onderhevig zijn. Bij een conformance-project zal de testbasis stabiel zijn.

139/159

Hoofdstuk - Testautomatisering

16.3

Aantekeningen

140/164


17

Intake Systeem

17.1

Zelftoets

Vraag 1. De Intake systeem heeft tot doel om vast te stellen dat het systeem van voldoende kwaliteit is om getest te kunnen worden. Een Intake systeem levert inzicht op in de kwaliteit en de testbaarheid van het systeem. De Intake testsysteem is niet bedoeld als stok tussen de spaken die het hele project stil kan leggen, maar heeft tot doel risico‟s bespreekbaar te maken. Bij het aannemen van de testopdracht hebben we een verantwoordelijkheid op ons genomen. Met de testbegroting en -planning zijn verwachtingen gewekt over het aantal uren dat nodig is om het systeem te testen. Als het opgeleverde systeem van mindere kwaliteit is dan was verwacht, dan zal de efficiëntie van het testproces in het gedrang komen. Mogelijk wordt hierdoor zelfs de deadline niet gehaald. Hierover is tijdig communicatie vereist. De Intake systeem geeft inzicht in de mate waarin het systeem voldoet aan de verwachting en stelt de tester in staat om tijdig aan de bel te trekken als de kwaliteit minder is dan verwacht. In overleg met de opdrachtgever wordt dan besloten welke maatregelen getroffen worden. Vraag 2. De producten van de Intake systeem zijn:  

Bevindingen Tijdens de intake worden de eerste bevindingen gedaan. Deze worden geregistreerd conform het afgesproken bevindingenrapportageproces. Ingevulde checklist met – een conclusie over de testbaarheid van het systeem; – een overzicht van de maatregelen die nodig zijn voordat er zonder risico met de testuitvoer begonnen kan worden. Als het systeem niet voldoet, wordt aangegeven op welke punten het systeem faalt. Per punt is aangegeven wat de risico‟s zijn voor een efficiënte testuitvoer en welke maatregelen nodig zijn om deze risico‟s af te dekken.

Vraag 3. Bevinding Release notes ontbreken

141/159

Risico’s Het is niet duidelijk welke bevindingen zijn opgelost, en welke „known issues‟ er spelen. Er worden functies getest waarvan al bekend is dat deze niet werken, of er worden bevindingen geregistreerd die al bekend zijn Het is onbekend welke wijzigingen er nodig zijn in de configuratie.

Maatregelen Release notes zijn alsnog nodig Organiseer kennisoverdracht tussen ontwikkelteam en testteam. Het project moet rekening houden met onnodige testtijd en aanvullend bevindingenoverleg.

Hoofdstuk - Intake Systeem

Vraag 4. Bevinding Systeem is instabiel Systeem bevat veel fouten

Risico’s Testuitvoer loopt vertraging op.

Maatregelen Er is een nieuwe release nodig alvorens verder te kunnen testen Het project moet rekening houden met meer releases en een langere testtijd.

Vraag 5. De Intake systeem is een risicogebaseerde activiteit. In de Testrisicoanalyse is samen met de belanghebbenden vastgesteld welke onderdelen van meer of minder belang zijn. Bij de intake ligt de nadruk op die onderdelen die moeten werken om de belangrijkste testen te kunnen uitvoeren.

17.2

Opdrachten

Voor het uitvoeren van de intake systeem kan de bijbehorende checklist gebruikt worden. Deze is opgenomen in de appendix, maar ook beschikbaar op www.testgoaleducatief.nl.

142/164


17.3

143/159

Aantekeningen

Hoofdstuk - Testuitvoering

18

Testuitvoering

18.1

Zelftoets

Vraag 1. Activiteiten in de test uitvoeringsfase  Uitvoeren van de geplande testen (belangrijkste eerst)  Vastleggen v/d testresultaten (beeldvorming kwaliteit v/h testobject en voortgang)  Registreren van de bevindingen  Bespreken en oplossen van de bevindingen (per bevinding beslissen: of en hoe snel wordt opgelost. ->bevindingen beheer)  Inplannen van nieuwe versies  Rapporteren over voortgang & kwaliteit ( zorgen voor het betrokkenheid en inzicht v/d betrokkenen tav het testproces & verschaffen van stuurgegevens.) Vraag 2. Een testrun is een verzameling van testactiviteiten waarbij alle testen minimaal 1 keer zijn uitgevoerd. Het kan zijn dat er nieuwe versie van het testobject nodig zijn om een testrun af te ronden. Een nieuwe testrun wordt gemaakt als de systeem versie wordt vernieuwd. Er worden ook nieuwe testruns gemaakt voor het hertesten en voor regressietesten. Vraag 3. Een testrun is afgerond als alle testen uitgevoerd zijn. Het laatste betekent niet dat alle testen geslaagd hoeven te zijn. Vraag 4. TRA is bepalend voor het uitvoeren van de scope and diepgag van het testen. Het test en moet in principe een antwoord geven op de risicovraagstukken. Tijdens het uitvoeren bepaald de TRA de volgorde van de testen, in de regel worden de belangrijkste testen als eerste uitgevoerd. Daarnaast worden de resultaten van de TRA gebruikt in de testrapportage. Door te rapporteren over zaken die leven bij de belanghebbende wordt ervoor gezorgd dat deze ook lezen en begrijpen. Risico‟s behoren typisch tot de zaken die leven bij de belanghebbenden. Openstaande risico‟s bepalen het besluit: door testen of live gang Vraag 5. De testcoördinator en de businessmanager nemen de beslissing om te stoppen met testen wanneer:  Alle testen zijn uitgevoerd  Alle open staande bevindingen zijn opgelost (of er is besloten dat deze niet van belang zijn)  Er naar verwachting veel testtijd nodig is om een nieuwe showstopper te ontdekken, dit kan m.b.v. de defect detection rate (zie tekstbox).  Er geen openstaande risico‟s zijn  De testers en de betrokkenen in het algemeen een goed gevoel bij hebben  Er meer belang is bij het in productie nemen van het systeem dan in het testen 144/164


Merk op dat al deze vragen de beslissing beïnvloeden, de vragen niet helemaal onafhankelijk van elkaar zij, en het gewicht dat er aan een bepaalde vraag wordt gegeven, per project kan verschillen. Defect Detection Rate (DDR) De Defect Detection Rate geeft het aantal bevindingen aan dat gevonden wordt per tijdseenheid testen als functie van de datum.

De grafiek geeft voor een gegeven moment aan hoeveel nieuwe bevindingen er verwacht worden, als er nog een uur of een dag verder getest wordt. Deze grafiek kan goed gebruikt worden om vast te stellen of verder testen nog zinvol is. Als de kosten om een fout te vinden hoger liggen dan de verwachte kosten van herstel als de fout in een productiesysteem gevonden wordt, is verder testen discutabel. Omgekeerd zal een projectmanager de testuitvoer niet stoppen, als de testcoördinator aantoont dat een extra dag testen waarschijnlijk nog acht showstoppers oplevert.

18.2

Opdrachten

Opdracht 1. Argumenten als „geen geld‟ en „geen tijd‟ zijn in het boek niet als overweging opgenomen. Hoewel deze argumenten vaak worden genoemd, leert de ervaring dat als de risico‟s te groot zijn, er meestal extra tijd en geld beschikbaar gesteld wordt. Of dit echt gebeurt, hangt of van de openstaande risico‟s en het vertrouwen dat de business heeft in het testen. Opdracht 2. Het antwoord op deze vraag is een persoonlijke mening en dus mits goed onderbouwd altijd goed. Een goed antwoord zou kunnen zijn dat er gestopt kan worden als er geen openstaande risico‟s zijn. Ervan uitgaande dat de TRA goed is uitgevoerd zou hiermee de meeste belangrijke risico‟s voorspeld zijn en daarmee de cruciale onderdelen getest.

145/159

Hoofdstuk - Testuitvoering

Testers zijn in het algemeen minder blij, als er gestopt wordt met in testen, omdat het belang van in productie zijn erg groot is. Dit houdt in dat er minder geluisterd wordt naar inhoudelijke argumenten over de kwaliteit van het testobject en de voortgang van het testtraject. Een aanvullende afweging zou kunnen zijn: Als het onduidelijk is wat het systeem moet doen, dan kan er ongeacht de test inspanning die geleverd wordt, geen goede uitspraak gedaan kan worden voor de fit for purpose van het systeem. Een student beantwoorde deze vraag ooit als volgt: “De uitvoer van de testen is in principe gebaseerd op een risico inschatting die vooraf is gemaakt, de TRA. Deze afweging dekt dus ook de openstaande risico‟s, gebaseerd op een structurele analyse. Ook het algemene gevoel bij het systeem lijkt mij erg belangrijk. Het is een soort informele overview die gebaseerd is op de ervaring van de tester(s) met het systeem, mar ook de ervaring van de tester in het algemeen. Bovendien overstijgt een dergelijke afweging het niveau van individuele testen, er vindt een soort informele samenvatting plaats. Ik denk wel dat deze afweging pas sterker van belang wordt naargelang de tester zelf meer ervaring heeft. “

146/164


18.3

147/159

Aantekeningen

Hoofdstuk - Bevindingenregistratie en –Beheer

19

Bevindingenregistratie en –Beheer

19.1

Zelftoets

Vraag 1. Een bevinding is een constatering van een verschil tussen van de verwachting en de uitkomst van een (deel van een) SUT. Deze afwijkingen kunnen worden gevonden in: 1. Testbasis 2. Programmatuur 3. Testontwerp 4. Testdata 5. Technische infrastructuur Vraag 2. Een bug is een fout in het SUT. Een RfC (Request for Change) is een voorstel hoe (een deel van) het SUT beter kan. Beide zijn een bevinding. Vraag 3. Het heeft toegevoegde waarde als bevindingen worden geregistreerd, wanneer ze verwerkt worden. Daarnaast is de toegevoegde waarde van een bevindingenregistratie dat  Er inzicht ontstaat over de kwaliteitsverbetering (deze bevindingen n hebben we opgelost)  Er garantie gegeven kan worden dat er geen belangrijke zaken vergeten worden (geeft vertrouwen: we vinden niet alleen dingen, we zorgen ook dat ze opgelost worden)  Maakt het hertesten van opgeloste bevindingen mogelijk, dan wel efficiënter  Maakt de communicatie met de ontwikkelaars efficiënter, ze hebben meer informatie om de bevinding op te lossen, en de kans is groter dat ze de goede fout oplossen.  Maakt het mogelijk om achteraf te onderzoeken wat de zwakke plekken zijn in het ontwikkelproces (waar ontstaan de fouten, in de code, in de documentatie, etc)  Maakt het mogelijk (afhankelijk van het registratie systeem) om de workflow rondom het vinden, oplossen en hertesten van bevindingen te automatiseren. Dit reduceert fouten en onduidelijkheden en is dus efficiënter. Vraag 4. Een goed bevindingenbeheer draagt bij aan resultaat gedreven testen doordat hiermee de juiste bevindingen worden verwerkt en op gecontroleerde wijze worden afgesloten. Tevens levert een goed bevindingenbeheer het juiste overzicht op de openstaande bevindingen en de gerealiseerde kwaliteit. Dit draagt bij aan het vertrouwen dat men kan stellen in de oplossing. Vraag 5. Een bevindingenrapport wordt gebruikt voor: 148/164


  

Het aangeven van de risico‟s in het geval dat het systeem in productie wordt genomen Het verwerken van bevindingen, door de oplossing door te voeren in de documentatie of de code. Het hertesten van de bevinding.

Vraag 6. In een bevindingenrapport staat o.m.:  Identificatie nummer  Datum waarop de bevinding is gedaan  Urgentie/ prioriteit  Testomgeving waarin de test heeft plaatsgevonden  Toewijzing van degene die de volgende actie tav de vervolgactie  Bijlagen of referenties Niet onbelangrijk is daarbij natuurlijk de omschrijving van de bevinding, zie antwoord op de volgende vragen: Vraag 7. De samenvatting moet de aard van de bevinding omschrijven. Er wordt omschreven  waar de fout optreedt,  wat het verkeerde resultaat is en  welke testactie de bevinding veroorzaakt. Vraag 8. De omschrijving moet alle informatie bevatten die nodig is om de bevinding te reproduceren. De omschrijving bestaat uit:  Welke testactie zijn uitgevoerd  De foutieve reactie  De verwachte reactie  De reden waarom deze afwijking incorrect is  De impact van de afwijking

19.2

Opdrachten

Opdracht 1. De meest minimale invulling van een bevinding zou toch minstens de volgende attributen moeten bevatten:  Nummer  Datum  Testexpert  Bevindingstatus  Samenvatting  Omschrijving  Commentaar Opdracht 2.

149/159

Hoofdstuk - Bevindingenregistratie en –Beheer

De gegeven bevinding voldoet duidelijk niet aan de omschrijving die in het boek gegeven wordt. De volgende dingen zijn op te merken:  De bevinding heeft geen ID  De Samenvatting geeft niet aan wat de invoer is en geeft niet aan wat de foutmelding is. Op deze wijze is de omschrijving weinig tot nietszeggend.  De omschrijving geeft onvoldoende informatie; wat voor een registratie? Welk kenteken is ingevoerd, en waarom denkt de tester dat deze valide is.  De omschrijving bevat fraseringen die negatief opgevat kunnen worden. Lees „alweer een foutmelding‟. De bevinding bevat op deze wijze een waarde oordeel over het hele systeem, terwijl ze objectief een anomaliteit dient te registreren.  De omschrijving bevat de zin „Graag snel oplossen !!!‟ Niet alleen kan deze zin (mede door de drie uitroeptekens) als negatief worden ervaren. De vraag is of de urgentie van de bevinding op deze manier geregistreerd dient te worden. Dit gebeurt meestal in een apart veld. Tevens wordt niet aangegeven waarom de bevinding deze urgentie heeft.  Verder ontbreken er attributen die wel in het boek omschreven staan (zie boek paragraaf 19.3) Op basis van bovenstaande opmerkingen dient de bevinding teruggestuurd te worden naar de tester die hem heeft geregistreerd.

Opdracht 3. Er zijn verschillende tools beschikbaar: Een willekeurige greep: Mantis (http://www.mantisbt.org/) Bugzilla (https://bugzilla.mozilla.org/) ApTest Manager (http://www.aptest.com/atm2/) Jira. http://www.atlassian.com/software/jira/

Op de website van ApTest Manager kun je de volgende informatie vinden: Registratie tool: ApTest Manager Leverancier: Applied Testing and Technology, Inc. Voordelen:  Maximize time to market in test planning, execution, and results analysis.  Quality Assurance and Quality Control teams can manage their entire testing process.  Engineering can manage their Unit testing as well as sharing QA/QC tests.  Management can monitor and examine the results and status of testing.  Tests and results can be shared with vendors and customers.  Kosten: gratis 30 dagen trial, anders eenmalig en afhankelijk van het aantal gebruikers, vanaf $500 (1-5 gebruikers) en voor support een bijdrage van $100 per jaar na het eerste jaar.

150/164


19.3

151/159

Aantekeningen

Hoofdstuk - Testrapportage

20

Testrapportage

20.1

Zelftoets

Vraag 1 Een testrapportage draagt bij aan resultaatgedreven testen door overzicht en inzicht te geven in de voortgang van het testproject en de in de kwaliteit van het testobject. De toegevoegde waarde van testen is gedefinieerd als: 1. Draagt bij aan de totstandkoming van „fit for purpose‟-systemen die werken conform de vastgestelde requirements, kwaliteitsattributen en (impliciete) verwachtingen. Het draagt bij aan het resultaat. 2. Voorkomt schade op het moment dat het systeem in productie is, doordat de tijdens het testen gevonden fouten voortijdig zijn opgelost. Het neemt de oorzaak weg 3. Voorkomt schade op het moment dat het systeem in productie is. De fouten in het systeem zijn bekend en er wordt geanticipeerd op de gevolgen van de fout. Het reduceert de impact. 4. Levert inzicht in de kwaliteit van het testobject, waardoor er vertrouwen in het testobject ontstaat. 5. Levert inzicht in de kwaliteit van het testobject en de voortgang van de realisatie, waardoor er effectieve projectsturing mogelijk is [Black, 2002]. Ad 2 en 3: Een rapportage zorgt ervoor dat duidelijk is welke fouten er zijn gevonden, en wat de status is van deze fouten. Ad 4: geeft inzicht in de testresultaten en maakt inzichtelijk dat de kwaliteit verbeterd is. Tevens geeft de rapportage inzicht in de testvoorgang zodat duidelijk is dat er steeds meer testen zijn uitgevoerd en daarmee het risico op grote verrassingen steeds kleiner wordt. Kortom het draagt bij aan vertrouwen Ad 5: testrapportage geeft inzicht in de kwaliteit van het testobject en de voortgang van de bug-fixing. Het geeft inzicht in de knelpunten die er zijn bij het behalen van het beoogde resultaat, dit maakt effectieve projectsturing mogelijk en zorgt er dus voor dat het resultaat sneller en effectiever behaald kan worden. En daarmee is gelijk punt 1 ook gedekt. Vraag 2. Tijdens de testuitvoering wordt het vrijgaveadvies gebruikt om de kwaliteit van het testobject aan te geven. Vraag 3. De Quality Gap is het verschil tussen de beoogde kwaliteit en de gerealiseerde kwaliteit.Vaak wordt dit verschil afgemeten aan de hand van het aantal openstaande bevindingen. Het verschil tussen de gevonden oplossingen en de gesloten oplossingen geeft het bekende verschil aan tussen de beoogde kwaliteit en de gerealiseerde kwaliteit Vraag 4. 152/164


Tijdens de testuitvoering wordt de grafiek „uitgevoerde vs. geplande testen‟ gebruikt om de voortgang van het testtraject te beoordelen. Vraag 5. Redenen om een dashboard te gebruiken zijn onder meer:  Geeft kort en toegankelijk overzicht en inzicht in voortgang van testtraject, kwaliteit van het testobject en kosten van het testtraject  Bevat kritische presentatieindicatoren die begrijpelijk voor alle belanghebbenden  Up to date, omdat het regelmatig bijgewerkt wordt. Vraag 6 Een testboodschap wordt helder over gebracht door:  Je te verplaatsen in de ontvangende partij  Rekening te houden met de percepties van anderen  De onderliggende data te beschouwen  Maatregelen voor te stellen  Niet alleen negatieve, maar ook Positieve signalen af te durven geven Vraag 7. De urenbegroting relateert aan de resultaatomschrijving omdat het een momentopname is van de geplande tijd en ten opzichte van de op dat moment bestede en verwachte tijd. Als de bestede tijd en de estimate to completion (ETC) samen meer is dan de begrootte tijd is er de kans dat het project langer duurt dan voorzien. Dit heeft dan effect op het resultaat, nl. dat het project over budget zal zijn. Vraag 8. De clusters in het grafiek testresultaat per cluster komen overeen met de aandachtsgebieden uit de TRA. Vraag 9. Het is van belang bij samengestelde data ook de onderliggende data te beschouwen, omdat de samengestelde data een verkeerd beeld kan geven. Dit kan zijn omdat bijvoorbeeld  de onderliggende data van verschillende grootorde is (bv een testsoort met 10.000 testen waarvan de helft is uitgevoerd en waarvan de uitgevoerde testen voor 90 procent positief zijn, en een klein project waarbij alle 100 testen blokkerende fouten hebben opgeleverd)  De onderliggend data elkaar opheffen (bijvoorbeeld een paar stappen die ruim over budget gaan en een paar meevallers die tijd uitsparen. Het kan belangrijk zijn om te weten waarom bepaalde taken uitlopen omdat hier een structurele oorzak voor is.)

20.2

Opdrachten

Opdracht 1 De uitgevoerde testen per risico categorie zijn goede key performance indicators omdat het duidelijk aangeeft

153/159

Hoofdstuk - Testrapportage



Hoe de aandacht verdeeld is over de belangrijke en minder belangrijke clusters (lees: het aantal testgevallen resp. voor de kritische, en minder kritische clusters)  Hoe de testuitvoering rekening houdt met de TRA  Een indruk geeft van de kwaliteit (de verhouding tussen geslaagde en niet geslaagde testen)  En indruk geeft van de voortgang en daarmee de kans op showstoppers in de rest van het testtraject. Kortom de grafiek bevat veel informatie de voor belanghebbenden nuttig is om te weten. Opdracht 2. Vragen die de projectmanager zou kunnen vragen zijn: Grafiek uitgevoerde testen:  Waarom zijn er meer risico‟s uit de lage categorie uitgevoerd dan uit de hoogste categorie.  Waarom zijn er geen testen uitgevoerd uit de midden categorie en wel uit de lage categorie  Mijn indruk is dat de helft van de testen gefaald is, betekend dit dat de kwaliteit van het systeem ruim onvoldoende is? Bevindingen status  Waarom zijn er geen bevindingen gesloten na 27 augustus  Ik zie dat de ontwikkelaars de laatste dagen veel bevindingen hebben opgelost, waneer worden deze hergetest door het testteam?  De grafiek betreft alleen showstoppers, tonen de overige bevindingen hetzelfde beeld? Uitgevoerde vs. geplande testen  Waarom zijn er na 27 augustus geen testen meer uitgevoerd?  Wat is de verwachte einddatum, waarom alle geplande testen zijn uitgevoerd? Uren begroting:  Waarom verwacht je het budget te overschrijden, komt dit doordat je meer doet dan gepland of omdat de dingen die gepland waren meer tijd kosten?  Wat zijn maatregelen die genomen kunnen worden om te zorgen dat je binnen budget blijft. Combinaties  Als er geen testen uitgevoerd zijn na 2-sep en project eerder niet echt veel meer testen uitgevoerd zijn, waarom is dan de urenbegroting overschreden?  Waarom, als tussen 27-aug en 2-sep geen testen zijn uitgevoerd, is er een stijging in showstoppers in dezelfde periode?

154/164


20.3

155/159

Aantekeningen

Hoofdstuk - Borging

21

Borging

21.1

Zelftoets

Vraag 1. De volgende activiteiten worden uitgevoerd om de projectresultaten te borgen: Evaluatie van het testtraject Vaststellen van de regressietestset Archiveren en borgen van de testware Overdracht Decharge van testteam Vraag 2. Het doel van project evaluatie is om successen te kunnen herhalen en te leren van fouten, zodat toekomstige testtrajecten efficiënter uitgevoerd kunnen worden. Vraag 3. Tijdens de borging worden de testplan gebruikt om de plannen en resultaten te vergelijken (aandachtspunten) en de relevante gebeurtenissen en ervaringen (leerpunten) te belichten. Vraag 4. Aan het einde van het project wordt de regressietest vastgelegd, omdat dan de bestaande testen opgeschoond kunnen worden. Hierin wordt aangegeven welke testen belangrijk zijn voor een toekomstige hertest. Testprincipe: herbuikbaarheid Vraag 5. Bij de overdracht worden de producten en kennis aan de organisatie overgedragen. Doel hiervan is dat de producten hergebruikt kunnen worden door bijvoorbeeld de beheerorganisatie. Testprincipe: herbuikbaarheid, faciliteer de hele lifecycle. Vraag 6. De ontvanger bepaalt of de overdracht voldoende is, omdat de kennis overgedragen moet worden aan deze partij en deze heeft hun eigen wensen over hoe en waar de borging plaats zou vinden. Vraag 7. Decharge is de officiële ontheffing verantwoordelijkheden van de testteamleden; de werkelijke afronding van het project.

21.2

Opdrachten

Opdracht 1. 1. Evaluatie testtraject 2. Vaststellen regressietest 3. Archivering en borgen testware 4. Overdracht 5. Decharge 156/164


21.3

157/159

Aantekeningen

Hoofdstuk - Dankwoord

22

Dankwoord

Een boek schrijf je niet alleen. Bij de totstandkoming van de TestGoal-filosofie die in dit boek beschreven is, hebben vele personen met enthousiasme meegewerkt. Een dankwoord is daarom zeker op zijn plaats; zonder jullie was dit boek nooit geworden wat het nu is. Aan de oorspronkelijke versie van TestGoal hebben veel collega‟s meegewerkt door het op papier stellen van hun ervaringen met bepaalde activiteiten binnen het testtraject. Mede dankzij hun inzet is TestGoal niet alleen mijn verhaal, maar een verhaal van allen. Ik bedank daarom iedereen die betrokken is geweest bij de initiële publicatie. Bij het schrijven van dit leerboek heb ik veel steun gehad van onder andere de volgende personen: Hossein Chamani (Hogeschool Rotterdam), Erik van Wessel (Hogeschool Leiden), Martin Reijnhoudt (Haagse Hogeschool), Natalia Silvis (Vrije Universiteit Amsterdam) en Jan Tretmans (Radboud Universiteit Nijmegen). Jullie meedenken over „testen in het onderwijs‟ heeft veel bijgedragen aan de didactische invulling van dit leerboek. Dank jullie wel voor de betrokkenheid en de tijd die jullie hebben uitgetrokken om, naast alle onderwijstaken, mee te denken met de opgaven en het manuscript te reviewen. Daarnaast wil ik de personen bedanken die geholpen hebben met opstellen en testen van de zelftoetsvragen en opdrachten: Acacia Bhikharie, Farid Rostami, Melissa Sjiem-Fat, Sakine Donmez, Paul van Leeuwen, Ufuk Hacivelioglu, Otto Vos en Froukje van der Wulp. Jullie bijdrage was onmisbaar bij het samenstellen van dit boek en de docentenhandleiding. Paul Post van uitgever Academic Service bedank ik voor zijn meedenken, support en vertrouwen. We hebben er een mooi boek van gemaakt! Collis, Dirk Jan v.d. Heuvel en Henk van Dam dank jullie wel voor het vertrouwen, support en het vrijmaken van de tijd die nodig was om dit boek te verwezenlijken. Derk-Jan de Grood Augustus 2008

158/164


23

Referenties

[Black, 2002], Rex Black, Eurostar, 2002. [Bouman, 2008], SmarTest, Egbert Bouman, 2008, SDU, ISBN9789012125970. [ISO/IEC Guide 2, 1991], Zie http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=39976. [Pinkster, 2004], Succesful Testmanagement, Iris Pinkster, bob van de Burgt, Dennis Janssen, Erik van Veenendaal, 2004, Springer, ISBN 354022822 5. [Pol, 1999], Testen volgens T-map, Martin Pol, Erik van Veendendaal, Ruud Teunissen , 1999, Tutein Nolthenius, ISBN 90721 9458 6. [TestGrip, 2007], TestGrip - Grip op kwaliteit en processen in ICT door testbeleid en testorganisatie. Rik Marselis, Iris Pinkster, Chris Schotanus en Jos van Rooyen, Logica, 2007 [van Dale], Woordenboek Van Dale. [Zeist, 1996], Quint: Kwaliteit van softwareprodukten. Praktijkervaringen met een kwaliteitsmodel , Bob van Zeist, Paul Hendriks, Robbert Paulussen, Jos Trienekens, pdf-versie 1.0, mei 1996, 1996. [Intermediair, 2008], Intermediair nr. 29, 17-07-08, bladzijde 11.

159/159

Docentenhandleiding. Leerboek resultaatgedreven softwaretesten

Recommend Documents