Docentenhandleiding. Leerboek resultaatgedreven softwaretesten

Transcriptie

1

2

3 Docentenhandleiding TestGoal Leerboek resultaatgedreven softwaretesten Versie 1.2 Derk-Jan de Grood D

4 Collis B.V. De heijderweg XZ Leiden T F E grood@collis.nl Deze docentenhandleiding behoort bij: Titel: TestGoal Leerboek resultaatgericht softwaretesten Auteur: Derk-Jan de Grood Uitgegeven door: Academic Service, Den Haag ISBN: Sdu Uitgevers bv, Den Haag Academic Service is een imprint van Sdu Uitgevers bv 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.

5 Inhoud Introductie Testen, een vak in ontwikkeling Resultaatgedreven Testen Testgoal en de tien testprincipes Testexpertise De Aanpak Aan De Slag Inventarisatie Beoogd Resultaat Testrisicoanalyse Begroten en Plannen Testplan Intake Testbasis Logisch Testontwerp Het Fysieke Testontwerp Testdata Testomgeving Testautomatisering Intake Systeem Testuitvoering Bevindingenregistratie en Beheer Testrapportage Borging Dankwoord Referenties

6 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

7 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 ISBN: ISBN: /164

8 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

9 Hoofdstuk - Introductie Resultaatgedreven zijn 1. Een vak in ontwikkeling 2. Resultaatgedreven testen 3. Testprincipes 4. Testexpertise 5. Verschillende toepassingen van testen Een gedegen testtraject doen 14. Testdata Maakt gebruik van 15. Testomgeving 17. Intake systeem 11. Intake testbasis Maakt gebruik van Snel een klein project doen Is nodig voor Entry criterium Wordt gebaseerd op 13. Fysiek testontwerp Worden uitgevoerd 18. Uitvoering Leid tot 19. Bevindingen registratie Levert op 12. Logisch testontwerp Wordt gebaseerd op 20. Testrapportage Wordt gebaseerd op Bevat informatie over Wordt gebaseerd op 8. TRA 9. Begroten en plannen 7. Inventaris beoogd resultaat Wordt gebruikt bij Wordt gebruikt bij Wordt gebruikt bij 16. Test automatisering 10. Testplan 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

10 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 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 uitvoeren, maar doe je niet? 2. Geef voor elk van de bij 1. bedachte testen aan waarom je deze test wil uitvoeren, 3. Stel je gaat achter de computer zitten om deze testen daadwerkelijk uit te voeren. Omschrijf welke handelingen jij of een andere tester moet verrichten 4. Welke getallen voer je in? 5. 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)? 6. 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

11 Hoofdstuk - Introductie 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 wordt automatisch 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

12 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 1 Testen, een vak in ontwikkeling 1.1 Aantekeningen 7/159

13 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: BROWSE&ObjectType=ART Sizing the QA Group - Theory and Application 8/164

14 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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. [ 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. [ 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

15 Hoofdstuk - Resultaatgedreven Testen 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

16 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

17 Hoofdstuk - Resultaatgedreven Testen 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

18 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 2.4 Aantekeningen 13/159

19 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

20 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten of T-map (afkomstig van de Sogeti Website): Of testframe (afkomstig van Wikipedia): 15/159

21 Hoofdstuk - Testgoal en de tien testprincipes 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

22 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

23 Hoofdstuk - Testgoal en de tien testprincipes 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

24 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 Nummer A 2 B 5 C 9 D 10 E 3 F 4 G 1 H 8 I 7 J 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

25 Hoofdstuk - Testgoal en de tien testprincipes 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 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 Requirements Design Coding Testing Deployment Result Test plan & strategy Review (intake Test base) Test design Setting up environment 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

26 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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.. Verkoop Introductie Groei Volwassenheid Afname Zie voor meer informatie over de Productlevenscyclus: Opdracht 3. Focus op resultaat Bouw aan vertrouwen 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. 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 Draagt bij aan vertrouwen, maar is nodig om resultaat te behalen 21/159

27 Hoofdstuk - Testgoal en de tien testprincipes Sla bruggen Test gefaseerd Draagt bij aan o.m. inzicht en overzicht, maar ook aan vertrouwen Draagt bij aan o.m. inzicht en overzicht Faciliteer de gehele ICTlifecycle Geef overzicht en inzicht Draagt bij aan o.m. het resultaat, zal het nodig maken om bruggen te slaan. 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

28 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 3.4 Aantekeningen 23/159

29 Hoofdstuk - Testexpertise 4 Testexpertise 4.1 Zelftoets Vraag 1. De testmanager De testcoördinator De testanalist De testengineer De testautomatiseerder De performancetester De securitytester Heeft zicht op de businessbehoeften en -wensen. Daarnaast beschikt hij over projectmanagementvaardigheden én heeft hij ervaring als tester een ervaren tester zijn én over projectleidersvaardigheden beschikken. 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 heeft hij kennis van de testontwerptechnieken Kritisch 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 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 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

30 mate van betrokkenheid Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 De testmanager De testcoördinator 1 0 Resultaat Aanpak Ontw erp Inrichten Uitvoering Borging fase 25/159

31 mate van betrokkenheid mate van betrokkenheid Hoofdstuk - Testexpertise Betrokkenheid testrollen De testanalist De testengineer 1 0 Resultaat Aanpak Ontw erp Inrichten Uitvoering Borging fase Betrokkenheid testrollen De testautomatiseerder 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

32 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

33 Hoofdstuk - Testexpertise 4.3 Aantekeningen 28/164

34 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

35 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

36 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

37 Hoofdstuk - De Aanpak Vraag 6. ISO9126 of anders het extended ISO model: QUINT. Niet genoemd in het boek, maar ook een model is : SQUA 3 RE 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

38 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

39 Hoofdstuk - De Aanpak 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. Stap Activiteit Product Resultaat Stap 1 Test Risico Analyse (TRA) Stap 2 Testplan Stap 2 Intake testbasis Stap 3 Ontwerp Stap 3 Intake systeem Stap 4 Testrapportage Stap 5 Borging Stap 6 Inrichting Stap 4 Configureren testomgeving Stap 4 Aanpak Stap 2 eisen testomgeving Stap 3 Uitvoering Stap 5 Testscenario Stap 3 Definiëren Testdata 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

40 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

41 Hoofdstuk - De Aanpak 5.4 Aantekeningen 36/164

42 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

43 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 Sla bruggen 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. Spreken met de opdrachtgever is het slaan van een brug. Test gefaseerd Faciliteer de gehele ICTlifecycle Geef overzicht en inzicht Minder van toepassing, tenzij de testcoördinator tijdens de inventarisatie al zijn beoogde aanpak communiceert. 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. 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

44 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 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: Beoogd resultaat: Opdrachtgever: Opdrachtnemer: Beschouwingsgebied: Testsoort: Systeemtest Centrale Sanctie Systeem (CSS) 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 s. Het voldoen aan de wettelijke verplichting m.b.t traceerbaarheid. o o Reduceren van de benodigde resources door: Het verminderen van klachten door het verminderen van de hoeveelheid foutief verstuurde sancties. Het automatiseren van de registratieprocedure en het verminderen van de fouten die zich daarbij voordoen. Hoofd afdeling IT (L. Harmsma) Testcoördinator QA en Testen (F. Rostami) Het CSS-systeem, incl. mail server De flitspalen behoren niet tot de scope van de systeemtest. Systeemtest 39/159

45 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

46 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 7.3 Aantekeningen 41/159

47 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: 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

48 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

49 Hoofdstuk - Testrisicoanalyse 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 2D TRA Voordeel Vormt een checklist van functies Is structuur voor fysieke testontwerp Gemakkelijk om over risico s te rapporteren naar belanghebbenden Relatief eenvoudig te begrijpen en in te voeren 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 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 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

50 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 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. 45/159

51 Hoofdstuk - Testrisicoanalyse Opdracht 4 Op de langere termijn zou nu een TRA organiseren een tijd- en 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

52 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

53 Hoofdstuk - Testrisicoanalyse 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: functie verdeling 1 Scherm performance 5 2 Bericht performance 9 3 Traceerbaarheid 9 4 Betaalstatus bijhouden 5 5 Besparing portokosten 9 48/164

54 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 6 Besparing klachtafhandeling 9 7 Handmatig registreren 3 8 Automatisch registreren 5 9 Opvragen voertuigregistratie 1 10 Berekening snelheidsovertreding 3 11 Berekening 3 roodlichtrijdersovertreding 12 Berekening combinatie overtreding 5 13 Opvraging registratie 1 14 Batch verzending 5 15 Enkelvoudige verzending 1 16 Sanctie wijzigen 3 17 Sanctie seponeren 1 18 Sanctie tarieven beheren 3 19 Directory inquiry beheren adres financiële afdeling 1 21 Foutafhandeling kenteken 1 22 NAW onbekend 1 23 Foutafhandeling bij sanctie te laag 1 24 Foutafhandeling bij betaling komt 1 niet overeen 25 Foutafhandeling bij Registratie informatie 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: 1 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

55 Hoofdstuk - Testrisicoanalyse - 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

56 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 8.4 Aantekeningen 51/159

57 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

58 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

59 Hoofdstuk - Begroten en Plannen 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

60 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Opdracht 2: Onderstaand overzicht berekent de kosten per week voor de situatie met en zonder de extra tester. Gegevens Gemiddelde Uurtarief 85 Euro/uur Ontwikkel kosten Testsimulator 3000 Euro eenmalig Licentie tool 150 Euro /gebruiker per 4 weken Huur testomgeving 100 Euro/week Uren testers 80 uur/week gelijk aan: 2 Fte Aantal testers in het team 3 Uurtarief extra tester Uren extra tester 100 Euro/uur 36 uur/week Kosten zonder extra tester Week Gemiddelde Urenkosten testteam Uurtarief extra tester Ontwikkelkosten Testsimulator /159

61 Hoofdstuk - Begroten en Plannen Licentie tool Huur testomgeving Totaal Cumulatief Kosten met extra tester Week Gemiddelde Urenkosten testteam Uurtarief extra tester Ontwikkelkosten Testsimulator 3000 Licentie tool Huur testomgeving Totaal Cumulatief Kostenbesparing van 6-4 weken: Zonder extra tester Met extra tester Kostenbesparing van 6-5 weken: Zonder extra tester Met extra tester Kostenbesparing van 6-6 weken: Zonder extra tester Met extra tester 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

62 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

63 Hoofdstuk - Begroten en Plannen 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 [ 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

64 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten mathematische aanpak die moeilijk uit te leggen is, veel discipline vergt en de nodige tijd kost. Dus niet geschikt binnen elke organisatie. 59/159

65 Hoofdstuk - Begroten en Plannen 9.4 Aantekeningen 60/164

66 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 algemene teststrategie naar een testaanpak voor alle testtrajecten binnen het project Gaat in op een specifieke testsoort (ergo de vertaling van het MTP naar een testaanpak voor een van de testtrajecten binnen Wordt opgesteld door testmanager het project testcoördinator 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

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

68 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 Uren opmerking Opdrachtformulering 0,5 Is al gemaakt tijdens stap 1 Resultaat teststrategie Omschrijving testaanpak 4 Kost relatief veel tijd, omdat er overleg nodig is met de betrokkenen. TRA 0,5 Is al gemaakt tijdens voorgaande activiteit Testomgeving 1 Vrijgaveadvies 1 63/159

69 Hoofdstuk - Testplan Planning 2 Testorganisatie Organogram 0,5 Benodigdheden 1 Accorderen 2 Totaal 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 voor een template met invul instructie van een testplan. 64/164

70 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 10.3 Aantekeningen 65/159

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

72 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 Opdrachten Opdracht 1. Er is niet gespecificeerd wat er gebeurd als er een tegelijk een snelheid- en roodlicht overtreding optreed. Er is wel een <type_overtreding>=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 <toegestane_snelheid > 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 <gemeten_snelheid> 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 <gemeten_snelheid> en <toegestane_snelheid > 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

73 Hoofdstuk - Intake Testbasis a) De checklist in de bijlage van het boek (of kan als volgt worden ingevuld: Checklist Testbasis: Ontwerp Resultaat Naam J/N N.v.t. Oplossingen Het geheel aan functionaliteit, processen en hun J coherentie is voldoende beschreven Het geheel aan functionaliteit, processen en hun J coherentie is consistent met het beoogde resultaat Alle relevante kwaliteitsattributen zijn afdoende behandeld. N Er is niet aangegeven welke kwaliteitsattributen Uitkomsten van de risicoanalyse zijn traceerbaar verwerkt in de testbasis. Controle N belangrijk zijn. Er is niet aangegeven welke risico s erkent zijn. Naam J/N N.v.t. Oplossingen Bevat historielog (incl. versiebeheer) N Bevat goedkeuring /distributielijst N Bevat documentbeschrijving (incl. auteur) N Document heeft een status N Bevat referentielijst N Structuur Naam J/N N.v.t. Oplossingen Bevat managementoverzicht N Bevat tabel met inhoud (actueel) J Bevat een inleidend hoofdstuk J Bevat hoofdstuk(ken) met overzicht/beschrijvingen van J de functionaliteiten (en bijbehorende schermen/ rapporten) Bevat hoofdstuk(ken) met datamodellen en databeschrijvingen N Datamodel ontbreekt, datadefinitie is aanwezig Bevat hoofdstuk(ken) met functie specificatie J Bevat hoofdstuk(ken) met interface specificatie J Inhoud Functioneel J/N N.v.t. Oplossingen Bevat systeem overview Systeem beschrijving J Doel van het systeem, wat hebben de gebruikers er J aan en hoe ondersteunt het hun business processen (hoog niveau) Scope diagram / systeem diagram J Systeemomgeving en -afhankelijkheden N Eigenaren van het systeem, beiden functioneel en N technisch J 68/164

74 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 J N J N 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 N N J J N J J J X X Maar niet van elk scherm Data Model en Data Beschrijving J/N N.v.t. Oplossingen Bevat een grafisch model (ERD) X Bevat een beschrijving van de entiteiten X 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 X Naam: van de relatie en de inverse relatie Cardinaliteit: hoeveel entiteiten zijn gelinkt met de relaties 69/159

75 Hoofdstuk - Intake Testbasis 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 J/N N.v.t. Oplossingen Bevat de naam van de interface; bijvoorbeeld <Interface J Systeem A Systeem B> Bevat een beschrijving van het doel J Bevat een workflow / schema / diagram J Bevat details van het proces J Bevat details van de direction J Bevat beschrijving van het type interface: operationeel/ J data / batch / online Bevat gedetailleerde informatie van het formaat van de J interface: structuur, data-elementen, data types, lengte, toegestane waarden Bevat beschrijving van error handling J Bevat beschrijving van error logging J Bevat beschrijving van constraints N Functie Specificaties J/N N.v.t. Oplossingen Bevat naam van de functie J Bevat doelstelling J Bevat proces informatie J Bevat Input / Output information J Bevat beschrijving van de data verwerking J Bevat beschrijving van calculatie functionaliteit J Bevat beschrijving van constraints (input checks) J Bevat beschrijving van error handling J Autorisatie J/N N.v.t. Oplossingen Beschrijving van vereiste autorisatie (profielen) N Bevat autorisatiematrix N Technische Architectuur J/N N.v.t. Oplossingen Beschrijving en/of schema's van de infrastructuur b.v. X netwerk, servers, DBMS, besturingssystemen, middleware Beschrijving van technische aspecten van interfaces b) De conclusie is dan als volgt: Conclusie Conclusie J / N De specificatie (testbasis) is voldoende nauwgezet beschreven om een X gestructureerd testtraject op te starten 70/164

76 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 Risico Maatregelen Geen Controle en versie informatie Laag; dit kan voor verwarringen veroorzaken Document versie, auteurs etc. Opnemen in document Het belang dat aan verschillende kwaliteitsattributen gehecht wordt is niet aangegeven in de specificatie. Hoog; Kwaliteit van de testware kan niet voldoende weergegeven worden 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 Detaillering is laag, Technische specificaties zijn niet beschreven Hoog; Vrijheidsgraden in de specificaties kunnen de fit for purpose in gevaar brengen 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

77 Hoofdstuk - Intake Testbasis 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

78 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 11.3 Aantekeningen 73/159

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

80 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 /159

81 Hoofdstuk - Logisch Testontwerp 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 Opdrachten Voor het uitwerken van de logische testgevallen kan de bij elke testontwerptechniek behorende template gebruikt worden. Deze is beschikbaar op Opgave 1: Horoscoop Naam Geldig Char Null Diakritische char Ongeldig - Geboortedatum Geboortetijd dd-mm-yyyy d-m-yyyy d-mm-yyyy hh-mm h-m Null, Char, dd-mm-yy Char Null Geboorteland From list Not from list Null Geboorteplaats Char Diakritische char Null 76/164

82 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Testgeval 1 Testgeval 2 Testgeval 3 Testgeval 4 Testgeval 5 Naam Char Diakritische char Null Char Char (Éèç@#$/~ ) Geboortedatum dd-mm-yyyy d-m-yyyy 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 From list (Nederlandse Antillen) Geboorteplaats Char Diakritische char Char Char Char (Curaçao Island) Resultaat Horoscoop Horoscoop Horoscoop Horoscoop S.v.p. Alle gegevens invoeren Testgeval 6 Testgeval 7 Testgeval 8 Testgeval 9 Testgeval 10 Naam Char Char Char Char 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! De geboortedatum en/of tijd is ongeldig! De geboortedatum en/of tijd is ongeldig! S.v.p. Alle gegevens invoeren Combinatie geboorteland/ geboorteplaats persoon 1 niet gevonden of niet eenduidig (gebruik svp atlas functie)! Testgeval 11 Testgeval 12 Naam Char Char Geboortedatum dd-mm-yyyy dd-mm-yyyy Geboortetijd hh-mm hh-mm Geboorteland Null From list Geboorteplaats Char Null Resultaat S.v.p. Alle gegevens invoeren S.v.p. Alle gegevens invoeren 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

83 Hoofdstuk - Logisch Testontwerp 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 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 Invoer of uitvoer Beperking N verkochte INPUT 3 INTEGER, OPTIONEEL producten N 2de lijn verkopers INPUT 3 INTEGER, OPTIONEEL 78/164

84 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Bonus OUTPUT 5 INTEGER Opmerkingen: Data definitions are missing for all attributes, the following assumptions were made: N verkochte producten: max de lijn verkopers: max. 999 Bonus: Max Stap 2: Bepaal geldige en ongeldige equivalentieklassen Attribuut Geldige klasse Ongeldige klasse N verkochte producten 0 N 50 50<N< N 999 <0 >999 N 2de lijn verkopers Bonus NULL 0 N<5 5 N<10 10 N 999 NULL 0 N 999 NULL (ik denk dat dit dan altijd 0 is. <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

85 Hoofdstuk - Logisch Testontwerp 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<N 150 (120) Geval 3 150<N 999 (700) Geval 4 NULL Geval 5 NULL N 2de lijn verkopers 10 N 999 (900) NULL 5 N<10 (7) 0 N<5 (4) NULL Toelichting Opbrengst product a Opbrengst product a Opbrengst product a Geen bonus Bonus Geen 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) N 2de lijn verkopers 5 N<10 (5) 0 N<5 (3) >999 (2500) <0 (-1) Toelichting Invalide Invalide Invalide Invalide Bonus 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 2 de -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

86 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

87 Hoofdstuk - Logisch Testontwerp 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

88 Geval 1 Geval 2 Geval 3 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 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 Daarna bepalen we per kolom de bijpassende acties. Condities/ Acties C1: Buiten de stad en werkzaam binnen de stad C2: Stadsvernieuwingsurgentie / / / / C3: Starter / 0 / 0 / 0 / 0 / / C4: Huurt reeds een woning bij de coöperatie A1: Bereken punten aantal X X X X X X X X X X X X X X X X A2: Geef extra X X inschrijvingswaarde A3: Extra 50 punten X X X X X X X X A4: Toon woningen X X X X X X X X X X X X X X X X A5: Toon starters woning X X X X X X X X A6: Plaats bovenaan de lijst X X X X A7: Plaats woning op ruillijst X X A8: Toon positie op rangorde lijst X X X X 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

89 Geval 6 Geval 8 Geval 10 Geval 11 Geval 12 Geval 14 Geval 15 Geval 16 Hoofdstuk - Logisch Testontwerp Vraag 3c Na opschonen van de overbodige testgevallen blijft de volgende set testgevallen over. Condities/ Acties C1: Buiten de stad en werkzaam binnen de stad C2: Stadsvernieuwingsurgentie C3: Starter C4: Huurt reeds een woning bij de coöperatie A1: Bereken punten aantal X X X X X X X X A2: Geef extra X X inschrijvingswaarde A3: Extra 50 punten X X A4: Toon woningen X X X X X X X X A5: Toon starters woning X X X A6: Plaats bovenaan de lijst X X X A7: Plaats woning op ruillijst X X X X X X X X X X A8: Toon positie op rangorde lijst 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 Geldig waarde Ongeldig waarde Plaats 20 AN 20 an Plaats > 20 AN Null Spaties Snelweg 20 AN Plaats > 20 AN 20 an Kenteken voertuig NN-AA-NN (23-XZ-14) AA-NN-AA (XZ-23-AB) NN-aa-NN (23-xz-14) AANNAA (23XZ14) Type overtreding [1,.., 3] [0,4,...,9] 84/164

90 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 Geval 1 Geval 2 Geval 3 Geval 4 Geval 5 Plaats 20 AN 20 an > 20 AN Null Spaties Snelweg 20 AN 20 an 20 AN 20 AN 20 AN Kenteken voertuig Type overtreding [1,.., 3] (1) Gemeten snelheid 0<=snelh eid<=99 9 [1,.., 3] (1) 0<=snelh eid<=99 9 NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) [1,.., 3] [1,.., 3] [1,.., 3] (2) (2) (2) null null null Verwacht resultaat Geaccept eerd Geaccept eerd Fout Fout Fout 85/159

91 Hoofdstuk - Logisch Testontwerp Attribuut Geval 6 Geval 7 Geval 8 Geval 9 Geval 10 Plaats 20 AN 20 AN 20 AN 20 AN 20 AN Snelweg > 20 AN 20 AN 20 AN 20 AN 20 AN Kenteken voertuig NN-AA- NN (23- XZ-14) Type overtreding [1,.., 3] (1) Gemeten snelheid 0<=snelh eid<=99 9 AA-NN- AA (XZ- 23-AB) [1,.., 3] (1) 0<=snelh eid<=99 9 NN-aa- NN (23- xz-14 [1,.., 3] (1) 0<=snelh eid<=99 9 AANNA A (23XZ14 ) [1,.., 3] (1) 0<=snelh eid<=99 9 NN-AA- NN (23- XZ-14) [0,4,...,9] (9) 0<=snelh eid<=99 9 Verwacht resultaat Fout Fout Fout Fout Fout Attribuut Geval 11 Geval 12 Geval 13 Geval 14 Geval 15 Geval 16 Plaats 20 AN 20 AN 20 AN 20 AN 20 AN 20 AN Snelweg 20 AN 20 AN 20 AN 20 AN 20 AN 20 AN Kenteken voertuig NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) NN-AA- NN (23- XZ-14) Type overtreding Null Alfa (O) [1,.., 3] (1) [1,.., 3] (2) [1,.., 3] (2) [1,.., 3] (3) Gemeten snelheid 0<=snelh eid<=99 9 0<=snelh eid<=99 9 > 999 < 0 A:c null Verwacht resultaat Fout Fout Fout Fout Fout Fout 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 [ 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

92 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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. [ 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 Geldig waarde Ongeldig waarde Agent_ID 8N Overtreding_ID > 8N Null Pleegdatum dd-mm-jjjj Bijvoorbeeld: , dd-mm-jj dd:mm:jjjj Type overtreding [1,.., 3] [0,4,...,9] null Opmerkingen: 87/159

93 Hoofdstuk - Logisch Testontwerp 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

94 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Attribuut Geval 1 Geval 2 Geval 3 Geval 4 Geval 5 Agent_ID 8N ( ) 8N ( ) 8N ( ) Overtredi ng_id > 8N ( ) Null Pleegdatum Type overtreding dd-mm-jjjj ( ) dd-mm-jjjj ( ) dd-mm-jjjj ( ) dd-mm-jjjj ( ) dd-mm-jjjj ( ) [1,.., 3] (1) [1,.., 3] (2) [1,.., 3] (3) [1,.., 3] (1) [1,.., 3] (3) Attribuut Geval 6 Geval 7 Geval 8 Geval 9 Geval 10 Agent_ID 8N 8N 8N 8N 8N ( ) Pleegdatum dd-mm-jj ( ) Type overtreding dd:mm:jjj j (14:12:199 9) dd-mm-jjjj ( ) [1,.., 3] (1) [1,.., 3] (2) [1,.., 3] (3) [0,4,...,9] (0) dd-mm-jjjj ( ) 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. Null 89/159

95 Hoofdstuk - Logisch Testontwerp In de onderstaande uitwerking is de correctie aangepast om passende combinaties te maken waarbij alle input en output klassen gedekt zijn. Attribuut Geval 1 Geval 2 Geval 3 Geval 4 Gemeten snelheid<0 snelheid>999 snelheid (-50) (9999) Toegestane snelheid Correctie 0<=snelheid<= 999 (140) 0<=snelheid<= 999 (120) 0<= Correctie <=99 (3) 0<=snelheid< =999 (50) 0<= Correctie <=99 (0) 0<=snelheid<= 999 (999) 0<= Correctie <=99 (99) 0<=snelheid<= 999 (135) snelheid<0 (-10) 0<= Correctie <=99 (5) Overtreding 10<Overtredin g <=40 (17) Overtreding <=0 (-100) Overtreding >40 (8901) Overtreding >40 (140) Sanctie 90 Geen Sanctie Inleveren Inleveren 90/164

96 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Attribuut Geval 5 Geval 6 Geval 7 Gemeten 0<=snelheid<=999 0<=snelheid<=999 0<=snelheid<=999 snelheid (999) (55) (900) Toegestane snelheid snelheid>999 (1000) 0<=snelheid<=999 (50) 0<=snelheid<=999 (0) Correctie 0<= Correctie <=99 (0) Correctie<0 (-4) Correctie >99 (100) Overtreding Overtreding <=0-1 10<Overtreding <=40 9 Overtreding >= Sanctie Geen Sanctie 28 Inleveren b) 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 Geval 9 0<=snelheid<=999 0<=snelheid<=999 (114) (190) 0<=snelheid<=999 (100) 0<= Correctie <=99 (3) 0<=snelheid<=999 (100) 0<= Correctie <=99 (3) Inleveren 91/159

97 Hoofdstuk - Logisch Testontwerp c) Rappel berekening: Attribuut Geval 1 Geval 2 Geval 3 Geval 4 Sanctie 0< Sanctie <=999 (28) Inleveren geen 0< Sanctie <=999 (28) rappel 0 <= Rappel <=999 (971) Datum_verstuurd Vandaag > Datum_verstuu rd+10 (wel rappel) 0< Sanctie <=999 (28) Vandaag > Datum_verstuu rd+10 (wel rappel) 0 <= Rappel <=999 (35) Vandaag > Datum_verstuu rd+10 (wel rappel) 0 <= Rappel <=999 (972) Vandaag > Datum_verstuu rd+10 (wel rappel) Sanctie (nieuw) 999 Inleveren + 35 Error Error (>999) Attribuut Geval 5 Geval 6 Geval 7 Geval 8 Sanctie 0< Sanctie <=999 (28) 0< Sanctie <=999 (90) 0< Sanctie <=999 (28) 0< Sanctie <=999 (90) rappel rappel<0 (-10) Datum_verstuurd Vandaag > Datum_verstuu rd+10 (wel rappel) rappel>999 (1000) Vandaag > Datum_verstuu rd+10 (wel rappel) 0 <= Rappel <=999 (0) Vandaag < datum verstuurd 0< Sanctie <=999 (35) Vandaag <= Datum_verstuu rd+10 (geen rappel) Sanctie (nieuw) Error Error Error 90 (geen 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

98 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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: Voorbeeld 2: 0<A<3 0<A<3 3>=A<6 3<A<=6 7<= A <10 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 3<A<6. Vervolgens gebruiken ze deze klasse in het testgeval en noteren hem als A>3. 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

99 Hoofdstuk - Logisch Testontwerp Het totaal aantal invalide equivalentieklassen bepaald in de regel het aantal invalide testgevallen. Stel we hebben drie attributen en equivalentieklassen A-I Attribuut Valide Invalide Attribuut 1 A, B, C F, G Attribuut 2 D H Attribuut 3 E 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 geen Inlever en 94/164

100 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 Geval 1 Geval 2 Geval 3 Geval 4 Geval 5 Geval 6 Gemeten snelheid Toegestane snelheid Correctie Overtreding Sanctie Geen Sanctie Geen Sanctie Attribuut Geval 7 Geval 8 Geval 9 Geval 10 Geval 11 Geval 12 Gemeten snelheid Toegestane snelheid Correctie Overtreding Sanctie Inleveren Inleveren Inleveren 28 95/159

101 Hoofdstuk - Logisch Testontwerp 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 F E I S3: Sanctie betaald S5: Rappel verzonden C J S7: Geseponeerd G K L S4: Geen actie nodig M S8: Geseponeerd & Restitutie nodig S6: Deurwaarder H 96/164

102 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Stap 2: Bepaal testdiepgang De diepgang is Switch Coverage = 0 Stap 3: Bepaal de toestandentabel Lijst van combinaties van acties en toegestane toestandsovergangen: Toestand A B C D E F G H I J K L M N S1Geregistreerd S S2Beschikking - S3 - - S S verzonden S3Sanctie voldaan - - S S S4Geen actie nodig S S5Rappel verzonden S3 S S7 S6Deurwaarder S S7Geseponeerd S4 S8 - - S8Restitutie nodig S4 - S9Eind Stap 4: Bepaal testgevallen De overgangen kunnen, gebaseerd op bovenstaande tabel, worden gedefinieerd. S1S2 S2S3 S2S5 S2S7 S3S4 S3S7 S4S9 S5S3 S5S6 S6S9 S7S4 S7S8 S8S4 S5S7 Valide geval 1 Valide geval 2 valide geval 3 valide geval 4 Valide geval 5 Valide geval 6 Pre-conditie S1 S1 (H) S1 (H) S1 (H) S1 (H) S1 (H) Actie A A (H) A (H) A (H) A (H) A (H) Conditie S2 S2 S2 S2 (H) S2 (H) S2 (H) Actie B E I I (H) E (H) E (H) Conditie S3 S5 S7 S7 S5 S5 Actie C G K L F N Conditie S4 S6 S8 S3 Actie D H M J Conditie S9 Post-Conditie S9 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

103 Hoofdstuk - Logisch Testontwerp 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

104 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Valide geval 1 Valide geval 2 valide geval 3 valide geval 4 Valide geval 5 Valide geval 6 Valide geval 7 Valide geval 8 Valide geval 9 Pre-conditie S1 S1 S1 S1 S1 (H) S1 (H) S1 (H) S1 (H) S1 (H) (H) Actie A A A A (H) A (H) A (H) A (H) A (H) A (H) Conditie S2 S2 S2 S2 S2 (H) S2 S2 S2 (H) S2 (H) Actie E B I E E (H) B I E (H) E (H) Conditie S5 S3 S7 S5 S5 S3 S7 S5 S5 Actie F J K G F C L N N Conditie S3 S7 S4 S6 S3 S7 S7 Actie C L D H J L K Conditie S4 S8 S7 Actie D M K Conditie S4 Actie D Conditie Postconditie 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 C A B S2 A B C S1 S2 S2 - S2 - - S1 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

105 Hoofdstuk - Logisch Testontwerp 100/164 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: S1 S2 S3 S4 A C B D E F State table M: S1 S2 S3 S4 S S S S Tweede orde transities worden verkregen door de state table te kwadrateren: MxM M 2 (4,2) = 2, Wat aangeeft dat er 2 testgevallen nodig zijn om de transitie S4-S2 te testen Voor 3 e orde transities geld dat: M M M 3 (1,1) = 4. Wat ook klopt, De 3 de 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

106 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Opgave 9: State transition testing van schermtransities Vraag 9a S6: Wijzigen Wijzigen Annuleren Of Bevestigen S5: Registratie overzicht Details Annuleren S3: Registratie gegevens Enkelvoudig Overzicht Annuleren of Verzenden Handmatige Invoer bevestigen Verder Annuleren verzenden S4: Verzenden Annuleren of Batch verzenden S1: Menu Invoeren Annuleren S2: Handmatig invoeren Annuleren Of Bevestigen Beheer Annuleren Error Log S7: Beheer S8: Error Log Voor de testdiepgang Switch coverage = 1, valide testen geldt de onderstaande combinaties van acties en toegestane state transitions: 101/159

107 Toestand Annuleren Batch verzenden Verzenden Overzicht Wijzigen Details Verder Beheer Error log Enkelvoudig Bevestigen Invoeren Hoofdstuk - Logisch Testontwerp S1 - - S4 S S7 S8 - - S2 S2 S S S3 S2 * S1 * - of S5 # of - # S4 S1 S S5 - - S5 S1 - S1 - S6 S S6 S S5 - S7 S S1 - S8 S 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

108 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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) S7-S1(Annuleer) S7-S1(Bevestiging) S8-S1 103/159

109 Hoofdstuk - Logisch Testontwerp 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: [ Als we ervoor kiezen om eerst foto s te selecteren als onderdeel van het bestel proces, 104/164

110 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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 adres gevraagd. [ Registeren is niet mogelijk omdat volgens de site het 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

111 Hoofdstuk - Logisch Testontwerp 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 1. Eerste beschikking? Y Y Eerste beschikking=y als Datum_verstuurd = null N Rappel =Y als Datum_verstuurd < Datum 10 dagen en Datum_rappel_1= null en Betaalstatus = 0 Deurwaarder = Y als Datum_rappel_1< Datum 10 dagen en Datum_rappel_2 = null en Betaalstatus = 0 2. Rappel? N 3. Deurwaarder procedure? Y N 5. Aanmaken Brief Deurwaarder Y 4. Bereken Sanctie 6. Aanmaken Rappel 7. Aanmaken Bechikking 8. Verzenden Batch? Y 9. Andere registraties? 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 pad scenariobeschrijving 1 1, 7, 8, 10 enkele verzending eerste beschikking 2 1, 2, 4, 6, 8, 10 enkele verzending rappel 3 1, 2, 3, 5, 8, 9, 1, 2, 3, 8, 9, 10 batch zending deurwaarderbrief (laatste registratie) Vraag 10b 106/164

112 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Bij statement coverage worden alle states 1 maal uitgevoerd. Dit komt overeen met eerste orde State Transition (ST) testen. testcase pad Scenariobeschrijving 1 1, 2, 3, 5, 8, 9, 10 batch zending deurwaarderbrief (laatste registratie) 2 1, 2, 4, 6, 8, 10 enkele verzending rappel 3 1, 7, 8, 10 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 B C Datum_verstuurd< Datum_rappel=null Betaalstatus=0 datum 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 Voor Deurwaarder: De condities bij het beslispunt 3 zijn van de vorm (A en B en C) A B C Datum_verstuurd< Datum_rappel=null Betaalstatus=0 datum /159

113 Hoofdstuk - Logisch Testontwerp 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 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 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

114 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

115 Hoofdstuk - Logisch Testontwerp 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

116 Geval 1 Geval 2 Geval 3 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 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Vraag 11d De beslissing tabel komt er dan als volgt uit te zien: Condities/ Acties C1: File aanwezig C2: File controle OK C3: NAW gevonden C4: Sanctie berekend zonder foutmelding 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 x x x x x x x x x x x x x x x x x x x x x x x x 111/159

117 Hoofdstuk - Logisch Testontwerp 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 Geval 1 Geval 2 Geval 3 Geval 4 Geval 5 Geval 9 C1: File aanwezig C2: File controle OK C3: NAW gevonden C4: Sanctie berekend zonder foutmelding A1: foutmelding: invoer voldoet niet aan restricties A2: foutmelding: kenteken niet gevonden A3: foutmelding: NAW niet gevonden A4: foutmelding: sanctie te laag x A5: bericht opslaan voor latere verwerking A6: gegevens opslaan en verwijdering origineel x x x x x x x A7: wacht op file x x x 112/164

118 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

119 Hoofdstuk - Logisch Testontwerp 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 ) 1. Het is mogelijk een waarde in te vullen bij aangetekend met aangegeven waarde terwijl deze optie niet geselecteerd is: 114/164

120 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

121 Hoofdstuk - Logisch Testontwerp 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

122 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Opgave 14: PCT en Unittesten Op 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 4. Extra aflossing? J 5. Vraag Extra Aflossing TermijnExtraAflos sing 8. Extra aflossing > Totaalbedrag/20 OF Termijn < 10 N 6. A of B? J 7. Percentage = Percentage + RenteBoete N J 8. Schuld= Totaalbedrag 9. n =n Rente= Percentage* Schuld 11. Rente >= TermijnBedrag 13. ExtraAflossing>0 EN n=termijnextraaflossng? Y N 12. Schuld+Rente > TermijnBedrag J 13. A en B? J 14. Schuld= Schuld ExtraAflossing N N 18. TermijnBedrag = Schuld + Rente 15. Aflossing = TermijnBedrag Rente Einde 16. Schuld = Schuld Aflossing 117/159

123 Hoofdstuk - Logisch Testontwerp Onderstaand is [er regel in de code aangegeven bij welk statement in het flow diagram deze regel hoort: START START 1. N = GET TotaalBedrag 2 3. GET Percentage 2 4. GET RenteBoete 2 VRAAGAFLOSSINGSGEGEVENS 5. GET TermijnBedrag IF (ExtraAflossing) { 5 8. GET ExtraAflossing 5 9. GET TermijnExtraAflossing IF (ExtraAflossing > TotaalBedrag / OR TermijnExtraAflossing < 10) { Percentage = percentage + RenteBoete 7 } } 13. Schuld = TotaalBedrag; 8 BEREKENVOLGENDETERMIJN 14. N = N Rente = Percentage * Schuld IF (Rente >= TermijnBedrag) { GOTO VRAAGAFLOSSINGSGEGEVENS Pad 11-3 } 18. IF (Schuld + Rente <= TermijnBedrag) { TermijnBedrag = Schuld + Rente GOTO EINDE } 21. IF (ExtraAflossing AND N = TermijnExtraAflossing ) { Schuld = Schuld - ExtraAflossing 14 } 24. Aflossing = TermijnBedrag - Rente Schuld = Schuld - Aflossing GOTO BEREKENVOLGENDETERMIJN Pad EINDE EINDE 118/164

124 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Opgave 14b Met één pad kunnen alle statements in het flowdiagram geraakt worden. Testgeval 1: Niet opgenomen in dit pad zijn : Opgave 14c Met onderstaande gegevens is het hele pad te doorlopen Totaal bedrag Rente percentage 0,06 Termijn bedrag 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 omschrijving Twee keer termijn invullen, Extra aflossing in 1 termijn betaald Extra aflossing met Renteboete, meerdere aflossingstermijnen Paden Als N Aflossingstermijn: ( ) Als N = Aflossingstermijn: ( ) /159

125 Hoofdstuk - Logisch Testontwerp 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: A Extra aflossing > Totaalbedrag/20 B Termijn < 10 (Niet A, B) 0 1 True (A, Niet B) 1 0 True (Niet A, Niet B) 0 0 False Beslissing 13:. ExtraAflossing EN n=termijnextraaflossing Dus: A B EN ExtraAflossing n=termijnextraaflossing (Niet A, B) 0 1 False (A, Niet B) 1 0 False (A, B) 1 1 True OF 120/164

126 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

127 Hoofdstuk - Logisch Testontwerp 12.4 Aantekeningen 122/164

128 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

129 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 Opdrachten Voor het uitwerken van de fysieke testgevallen kan de bijbehorende template gebruikt worden. Deze is beschikbaar op 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

130 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Bij testgeval 86 Doel van de test Preconditie Postconditie Referentie naar de Testbasis Referentie naar Logische testontwerp testacties Verwachte systeemreactie 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 125/159

131 Hoofdstuk - Het Fysieke Testontwerp 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

132 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten In de fysieke testgevallen kan gebruik gemaakt worden de volgende notering: <naam> naam [naam] 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 <datum>. Exacte string die gebruikt wordt, bijvoorbeeld bij de invoer van een veld, of de foutmelding die getoond wordt. 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]. S5 Registratieoverzicht wordt getoond. 7 Voer in het kenteken zoals gebruikt in Er zijn geen correspondeerde de aangeboden xml-file, selecteer zoekresultaten (het resultaten scherm blijft [zoek]. leeg) Opgave 3 Actiewoord gedreven testen is o.m. uitgelegd in hoofdstuk testautomatisering van het TestGoal boek. Zie eventueel ook: 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 /159

133 Hoofdstuk - Het Fysieke Testontwerp 13.3 Aantekeningen 128/164

134 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten 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

135 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 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 wettelijk verplicht zijn, i.v.m. met privacy wetgeving Kan onrealistische fouten opleveren als het anonimiseren niet correct gebeurt. 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

136 Docentenhandleiding TestGoal Leerboek resultaatgericht softwaretesten Opdracht 2. Type testdata Invoer- en uitvoerdata Operationele data Configuratie data Beantwoorden van mailtjes Wordt het adres van de afzender vanzelf in het naar - veld geplaatst. Dus invoer data is: adres. Een bericht in de inbox Is er het een bestaand 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 security settings: 131/159