TESTING POLICY. Van Caneghem Wouter Functionele Analist - Fedict. Dussart Dirk Architect - Fedict

Maat: px
Weergave met pagina beginnen:

Download "TESTING POLICY. Van Caneghem Wouter Functionele Analist - Fedict. Dussart Dirk Architect - Fedict"

Transcriptie

1 TESTING POLICY Van Caneghem Wouter Functionele Analist - Fedict Dussart Dirk Architect - Fedict

2 Contents 1. Inleiding Doel van dit document Waarom testen? Wat is testen Basisprincipes Het testproces en algemene verantwoordelijkheden Het Fedict V-model Testlevels Reviews Unittest level Integratietestlevel Systeemtestlevel Acceptatietestlevel Test types Functionele tests Niet functionele tests Tests gelinkt aan wijzigingen (confirmatietests en regressietests) Classificatie van Testtechnieken Test Proces Risico gebaseerd Verantwoordelijkheden Algemeen Lagere test levels Systeem Integratietests Acceptatietests Severity (Ernst) Vereisten voor de leverancier Algemeen Inhoud van de op te leveren werkproducten Op te leveren werkproducten (Deliverables) Algemene documenten Unittests Integratietests Systeemtests Acceptatietests

3 3.4. Staging Criteria Dekkingsgraad Criteria om naar TEST te gaan Criteria om naar ACCEPTATIE te gaan Criteria om naar PRODUCTIE te gaan Aanbevelingen voor de leverancier Test Matrix Scenario coverage Rollen en verantwoordelijkheden Test Manager Test Architect Test Designer Tester Test Automation Engineer Test Methodologist Tools Selenium JUnit Hudson Jenkins Testproces Testspecificatie Testuitvoering Test Reporting Test Documentatie Testplan Testdesign specificatie Testcase specificatie Testlog Test Incident Rapport Test Summary Rapport Annexen Annex 1 Templates Gebruik van de templates Lijst van templates

4 Datum Versie Beschrijving Auteur 11/10/ Eerst draft versie Wouter Van Caneghem 17/10/ Toevoeging hoofdstuk Tools Wouter Van Caneghem 21/10/ Toevoeging rollen en Wouter Van Caneghem verantwoordelijkheden 17/11/ Toevoeging unittesting Diederik Delen 12/12/ Toevoeging testmatrix Wouter Van Caneghem 13/12/ Toevoeging staging criteria Wouter Van Caneghem 27/02/ Update staging criteria en toevoeging Wouter Van Caneghem annexe 05/03/ Update testmatrix Dirk Dussart 13/04/ Review Coralius nv Coralius nv 14/05/ Wijzigen van de severities Wouter Van Caneghem 4

5 1. Inleiding 1.1. DOEL VAN DIT DOCUMENT Dit document heeft tot doel duidelijk te maken welke eisen Fedict stelt inzake het testproces voor software en af te lijnen wie voor welke delen van dit proces verantwoordelijk is. De in dit document gestelde vereisten zijn van toepassing voor alle projecten. In de specifieke lastenboeken of requirementsdocumenten kunnen zij echter worden aangepast aan de behoeften van het project of product. Verder is het de bedoeling dat dit document de leverancier helpt om vanaf de eerste oplevering een zo goed mogelijk product op te leveren en zodanig een win-win situatie te creëren voor beide partijen. Hierbij willen we ervoor zorgen dat de inspanning voor testen en hertesten langs de kant van Fedict alsook het herwerken van het product bij de leverancier minimaal is. Hoofdstuk 2 geeft een algemeen overzicht van het testproces op basis van het V-model. Hierin geven we aan welke testlevels onder de verantwoordelijkheid van Fedict vallen en voor welke de software leverancier verantwoordelijk is. In hoofdstuk 3 geven we een overzicht van de op te leveren werkproducten (deliverables) en de vereisten waaraan deze moeten voldoen. In hoofdstuk 4 geven we bijkomende aanbevelingen over hoe een leverancier kan voldoen aan de gestelde eisen, zonder evenwel een bepaalde ontwikkelingscyclus of methodiek willen op te leggen. In Annex 1 geven we een lijst van templates die bij deze policy horen en leggen we uit hoe men deze kan gebruiken WAAROM TESTEN? Testen is een noodzakelijke voorwaarde voor het succesvol bouwen en implementeren van informatiesystemen. De complexiteit van hedendaagse software is zodanig dat het zo goed als onmogelijk is om deze van de eerste keer en zonder verificatie correct te implementeren. Testen is nodig om zo vroeg mogelijk problemen in de software te ontdekken zodanig dat deze tegen een minimale kostprijs kunnen gecorrigeerd worden. Een tweede reden om te testen is om vertrouwen en kennis in het opgeleverde product op te bouwen. Defecten in een software product kunnen zware gevolgen hebben voor de business en voor de gebruikers. Naast het zo veel mogelijk vermijden van fouten is testen ook zinvol om aan het management en de gebruikers aan te tonen dat het opgeleverde product voldoet aan hun vereisten ( fit-for-purpose ). 5

6 Hierbij dienen we op te merken dat zowel de functionaliteit als de niet-functionele softwarekarakteristieken van belang zijn om te kunnen stellen dat een product voldoet aan de gestelde vereisten en bruikbaar is in zijn operationele context WAT IS TESTEN Software testen is het proces om te verifiëren en te valideren dat een software programma, applicatie of product: voldoet aan de business en technische vereisten zoals beschreven in het lastenboek, de vereisten (requirements), analyse en design documenten. werkt zoals verwacht en bruikbaar is in zijn operationele omgeving. geïmplementeerd is met de vooropgestelde niet-functionele software karakteristieken. Hierbij dienen verificatie en validatie geïnterpreteerd worden in de zin van de ISO-9000 standaard: verificatie: bevestiging, door middel van het opleveren van objectieve bewijzen dat de gestelde vereisten vervuld zijn. validatie: bevestiging, door middel van het opleveren van objectieve bewijzen dat de gestelde vereisten, voor een specifiek verwacht gebruik of toepassing, vervuld zijn. Men kan dit interpreteren door te stellen dat verificatie inhoudt dat men de software juist gebouwd heeft terwijl validatie inhoudt dat men de juiste software heeft gemaakt BASISPRINCIPES Er zijn een aantal principes die gelden voor alle testen: - Principe 1: Testen brengt defecten naar boven. Testen toont defecten die aanwezig zijn aan, maar kan niet bewijzen dat er geen defecten zijn. Testen verlaagt de kans van niet ontdekte defecten in de software, maar indien geen defecten gevonden worden kan dit niet aanzien worden als bewijs dat er geen defecten zijn. - Principe 2: Exhaustief testen is onmogelijk. Alles testen (alle combinaties van inputs/outputs en pre-condities) is niet haalbaar behalve in triviale gevallen. In plaats van doorgedreven te testen moeten risicoanalyse en prioriteiten gebruikt worden om de testinspanning te beperken tot de juiste testen. - Principe 3: Vroeg testen. De testactiviteiten moeten zo vroeg mogelijk starten in de ontwikkelingscyclus van software. Dit zorgt er voor dat de defecten vroeg gedetecteerd worden wat tot gevolg heeft dat het minder kost om ze op te lossen. 6

7 - Principe 4: Clustering van defecten. Een klein aantal van de modules bevat de meeste defecten die ontdekt worden tijdens de pre-release tests en/of zijn verantwoordelijk voor de meeste operationele fouten. - Principe 5: Pesticidenparadox. Als dezelfde set van testcases telkens opnieuw worden uitgevoerd, zal deze uiteindelijk geen nieuwe defecten meer aantonen. Daarom moeten de testcases regelmatig herbekeken worden. Nieuwe tests moeten geschreven worden om andere delen van de software te verifiëren om zo nieuwe defecten te vinden. - Principe 6: Testen is context afhankelijk. De manier van testen is afhankelijk van de context waarin het product uiteindelijk gebruikt zal worden. Bijvoorbeeld een beveiligingssoftware wordt anders getest dan een e-commerce website. - Principe 7: Absence-of-errors fallacy. Het vinden en oplossen van defecten helpt niet als het systeem niet bruikbaar is en/of niet voldoet aan de noden en verwachtingen van de eindgebruikers. 7

8 2. Het testproces en algemene verantwoordelijkheden 2.1. HET FEDICT V-MODEL Het Fedict V-model illustreert de gebruikte testlevels en de algemene verantwoordelijkheden van Fedict en van de leverancier TESTLEVELS Testlevels zijn groepen van testactiviteiten die tezamen beheerd worden en die in directe relatie staan tot de verantwoordelijkheden zoals gedefinieerd binnen een project. Fedict hanteert de testlevels zoals beschreven in de rest van deze sectie. Wanneer een leverancier andere benamingen of andere testlevels gebruikt moet hij kunnen aangeven wat de relatie is tussen de door hem gebruikte terminologie en deze van Fedict en moet hij kunnen aantonen dat zijn aanpak minstens evenwaardig is aan de door Fedict beschreven aanpak. 8

9 Merk op dat een testlevel niet hetzelfde is als een testfase. In een incrementeel of iteratief ontwikkelingsmodel zal men bijvoorbeeld in verschillende fasen van een project telkens opnieuw taken uitvoeren die behoren tot een welbepaald testlevel. Het V-model wordt in deze policy gebruikt om aan te geven wie welke activiteiten uitvoert en niet om een specifieke softwaredevelopment lifecycle op te leggen Reviews Reviews vormen een uitstekend middel om vroeg en kost-efficiënt fouten te detecteren. Wanneer de leverancier echter een review door Fedict van één of meerdere documenten verwacht, dient hij dit aan te geven in de offerte, met vermelding van de te reviewen documenten en een schatting van de nodige inspanning hiervoor langs de kant van Fedict. Hierbij kan men er vanuit gaan dat een review snelheid van 6 pagina's per uur zorgt voor een goede detectie van fouten Unittest level Unittests (ook wel componenttests genoemd) zoeken naar defecten in, en verifiëren het functioneren van apart testbare software modules, programma s, objecten, klassen, etc. Unittests kunnen zowel functionaliteiten alsook specifieke niet-functionele karakteristieken verifiëren. De testcases zijn gebaseerd op werkproducten zoals de specificaties van een component, het software design of het data model. Unittests worden gebruikt om zeker te zijn dat de individuele componenten correct werken. Unittesten maakt vooral gebruik van de whiteboxtesttechniek en gebeurt dus met kennis van de code die wordt getest en eventueel met de ondersteuning van de ontwikkelingsomgeving (unittest framework, debugging tool, etc.). Deze tests worden daarom dan ook vaak uitgevoerd door de ontwikkelaar die de code heeft geschreven of een gelijkwaardig profiel. De gevonden defecten worden opgelost zodra ze gedetecteerd worden. Voor Fedict vormen de unittests een goed alternatief voor commentaar in de code voor zover ze goed gestructureerd en leesbaar zijn opgesteld. Een unittest beschrijft meestal meer de details dan tekst in commentaar stijl. Unittests worden ook mee onderhouden samen met de code waar commentaar vaak wordt vergeten en op deze manier zal commentaar dan ook snel gedateerd raken. Unittests hebben ook een aantal karakteristieken die invloed hebben op de onderhoudsbaarheid van de applicatie. Tests zouden een eenvoudige structuur moeten hebben en dienen makkelijk op te zetten zijn. Afhankelijkheden moeten beperkt worden; door gebruik te maken van stub- en driverframeworks kan men een testsetup eenvoudig houden. Indien het schrijven van een test complex is, moet men als ontwikkelaar nadenken om de functionaliteit anders te implementeren. Moeilijk te testen code is dikwijls te complex, hetgeen de kans op fouten vergroot. Een richtlijn hierbij is om de cyclomatische complexiteit van individuele functies of methoden zo veel mogelijk beneden de 15 te houden. 9

10 Tests hebben een duidelijke naamgeving. In de methode of testnaam beschrijven we wat de test gaat doen. Namen zoals test1, test2 zijn ontoelaatbaar. Denk er aan dat ook de unittests door Fedict moeten kunnen geverifieerd worden. Unittests zijn ook onafhankelijk van elkaar en moeten dan ook allen afzonderlijk kunnen lopen Integratietestlevel Bij de integratietests worden de interfaces tussen de verschillende componenten en de interacties met verschillende delen van een systeem (zoals besturingssysteem, bestandssysteem, hardware, etc.) getest. Er kunnen meer dan één niveau van integratietesten zijn en ze kunnen uitgevoerd worden op testobjecten van diverse grootte. We maken een onderscheid tussen 2 aparte integratietest levels: - Component integratietests: testen van de interactie tussen software componenten. Zij worden uitgevoerd na de unittests. - Systeem integratietests: testen van de interactie tussen verschillende systemen. Zij worden uitgevoerd na de systeemtests. Hoe groter de scope van de integratie, hoe moeilijker het wordt om defecten te isoleren in een specifieke component of systeem. Op elk moment van de integratie, concentreren de testers zich enkel op de integratie zelf. Bijvoorbeeld: een nieuwe module A wordt geïntegreerd met een module B. Bij de integratietests is men hoofdzakelijk geïnteresseerd in de communicatie tussen de modules en niet in de functionaliteit van de modules zelf Systeemtestlevel Bij de systeemtests willen we het gedrag van een volledig systeem, zoals gedefinieerd in het project, testen. Voor systeemtests is, a priori, geen kennis vereist van het inwendige design of logica van het systeem; er worden hierbij dan ook vooral blackboxtesttechnieken gebruikt. Bij de systeemtests moet de omgeving zoveel mogelijk overeenkomen met de finale productieomgeving om het risico op omgeving specifieke defecten te minimaliseren. Systeemtests worden afgeleid van risicospecificaties, requirementspecificaties, business-processen, use-cases of andere high level omschrijvingen. Ze worden uitgevoerd binnen de context van functionele requirements. Systeemtests zullen daarnaast ook de niet functionele requirements onderzoeken (kwaliteitsattributen). Systeemtests bevatten typisch de volgende soorten tests: GUI-tests, usability tests, regressietests, performancetests, error-handlingtests, maintenance tests, compatibility tests, load tests, security tests, scalability tests, etc. Het is de bedoeling dat op het einde van de systeemtestuitvoering de leverancier ervan overtuigd is dat het systeem voldoet aan alle gestelde vereisten en klaar is om aan de klant overgedragen te worden (eventueel met uitzondering van de interactie met peer- systemen). 10

11 Acceptatietestlevel Acceptatietests zijn vaak de verantwoordelijkheid van de klanten of (eind)gebruikers van een systeem. Andere stakeholders kunnen hier ook bij betrokken worden. Het doel van acceptatietesten is om vertrouwen in het systeem, delen van het systeem of specifieke niet functionele eigenschappen te krijgen. Het vinden van defecten is niet het hoofddoel van acceptatietesten. Met de acceptatietests kunnen we de gereedheid voor gebruik van een systeem nagaan. Acceptatietests kunnen voorkomen als méér dan één enkelvoudige testlevel. Bijvoorbeeld: - Acceptatietesten van de bruikbaarheid van een component kan gebeuren tijdens het unittesten. - Acceptatietesten van een nieuwe functionele verbetering kan gebeuren voor de systeemtests. Acceptatietests bevatten typisch volgende elementen die eventueel als aparte testlevel kunnen worden beschouwd: - Gebruikersacceptatietests: de paraatheid verifiëren van het gebruik van een systeem door business gebruikers. - Operationele acceptatietests: de acceptatie van het systeem door de systeem administrators, bevat tests van backup/restore, disaster recovery, user management, maintenance tasks, etc. - Contract- en richtlijntests (conformantietest): de acceptatiecriteria moeten afgesproken worden tijdens de contractbesprekingen. De acceptatie wordt dan gedaan tegenover deze criteria voor het produceren van software. Hierin zijn ook standaarden (government, legal, security, etc.) inbegrepen. - Zonder specifieke afspraken moet het systeem voldoen aan alle gestelde vereisten zoals beschreven in het (ondertekende)lastenboek en bijhorende documenten evenals aan de vereisten beschreven in alle meer technische documenten die door Fedict zijn goedgekeurd. - Alfa- en betatests: het krijgen van feedback van potentiele of bestaande klanten vooraleer het product op de markt komt. Alfa testen gebeurt binnen de organisatie van de ontwikkelaar. Betatesten (field testen) gebeurt door de mensen op hun eigen locatie TEST TYPES Functionele tests Functionele tests verifiëren de functies die een systeem, subsysteem of component moeten uitvoeren. Deze kunnen beschreven worden in zogenaamde werkproducten zoals requirementspecificaties, use-cases, functionele specificaties, etc. Ze beschrijven wat het systeem doet. De functionele tests zijn gebaseerd op de functionaliteiten en hun interoperabiliteit met specifieke systemen. Functionele tests kunnen uitgevoerd worden op elk testlevel. Bijvoorbeeld, tests voor componenten kunnen gebaseerd zijn op componentspecificaties. 11

12 Functionele tests beschouwen het externe gedrag van de software en worden bijgevolg hoofdzakelijk opgesteld met behulp van blackboxtesttechnieken Niet functionele tests Niet functionele tests omvatten (niet-exhaustieve lijst) performance tests, load tests, stresstests, usability tests, maintainability tests, reliability tests, etc. Ze testen hoe het systeem werkt. Niet functionele tests kunnen uitgevoerd worden op elk test level. De niet functionele tests verifiëren de niet-functionele karakteristieken van systemen. Dikwijls doen ze dit door kwantificeerbare informatie te meten die kan vergeleken worden met vooropgestelde grenzen. Bijvoorbeeld, de response tijden voor performance tests Tests gelinkt aan wijzigingen (confirmatietests en regressietests) Wanneer een defect gevonden en opgelost is moet de software opnieuw getest worden om te bevestigen dat het oorspronkelijke defect succesvol verwijderd is. Dit noemt men confirmatietesten. Men spreekt in dit verband ook van hertesten. Opmerking: Het debuggen van code is een ontwikkelingsactiviteit, geen testactiviteit. Regressietesten is het opnieuw testen van een reeds geteste programmacode na wijzigingen om zo defecten te ontdekken (in niet gewijzigde aspecten van de software) die veroorzaakt worden door wijzigingen aan de software of aan de omgeving. Deze tests worden telkens uitgevoerd wanneer de omgeving of de software verandert. Regressietests kunnen ook uitgevoerd worden op elk testlevel en zijn toepasbaar voor zowel functionele, niet functionele als structurele tests. Regressietests worden vaak uitgevoerd en richten zich op de meest kritische functionaliteiten waardoor ze een geschikte kandidaat zijn voor automatisatie CLASSIFICATIE VAN TESTTECHNIEKEN Testtechnieken zijn formele werkwijzen om test gevallen af te leiden van documenten, van modellen van de software of van code. We kunnen de verschillende soorten testtechnieken opdelen in 2 groepen. De zogenaamde whiteboxtests en de blackboxtests. De whiteboxtests zijn gebaseerd op de programmacode, de programmabeschrijvingen of het technisch ontwerp. Er wordt nadrukkelijk gebruik gemaakt van kennis over de interne structuur van het systeem. Deze tests worden typisch uitgevoerd door de ontwikkelaars en het gaat hierbij om een door de ontwikkelaar uitgevoerde test die dient om aan te tonen dat een programma (of 12

13 module) of een serie programma s (of modules) voldoet aan de in de technische specificaties gestelde eisen. De blackboxtests zijn gebaseerd op de functionele specificaties en kwaliteitseisen. Bij deze tests wordt het systeem beschouwd in de verschijningsvorm zoals die ook gedurende het uiteindelijke gebruik zal functioneren. De software wordt gezien als een zwarte-doos zonder enige kennis van de interne implementatie noch van de interne structuur. Typisch worden hierbij meerdere testcases opgesteld gebaseerd op de functionele specificaties en requirements. Alhoewel beide groepen van testtechnieken op alle levels kunnen gebruikt worden, zet men hoofdzakelijk op de lagere testlevels whiteboxtesttechnieken in en op de hogere levels blackboxtesttechnieken. De acceptatietests uitgevoerd door Fedict zullen hoofdzakelijk gebruik maken van blackboxtesttechnieken TEST PROCES Het staat de leverancier vrij om een test proces te kiezen dat overeenkomt met zijn ontwikkelingsmethodiek voor zover hij daarmee voldoet aan de vereisten zoals gesteld in hoofdstuk 3. In hoofdstuk 4 geven we enige richtlijnen hierover zonder echter een specifiek proces op te leggen RISICO GEBASEERD Risico gebaseerd testen houdt in dat men op basis van een (product) risicoanalyse de testinspanning focust op de delen of aspecten van een applicatie die het grootste risico inhouden. Het wordt gezien als een goede praktijk om de teststrategie minstens gedeeltelijk te bepalen op basis van een risicoanalyse. In deze zijn er twee mogelijkheden: Fedict heeft een risicoanalyse bijgevoegd in het lastenboek of de bijhorende documenten. Fedict heeft geen risicoanalyse bijgevoegd in het lastenboek of de bijhorende documenten. In het eerste geval raden we de leverancier aan om deze analyse te gebruiken en indien nodig te verfijnen wanneer de technische aspecten van het systeem onder test duidelijker worden. In het tweede geval kan de leverancier zelf een analyse uitvoeren. Fedict kan hierbij eventueel input geven inzake de impact van de risico's. Wanneer de leverancier van Fedict een inspanning verwacht in verband met de risicoanalyse dient hij in de offerte op te nemen: 13

14 Een beschrijving van zijn aanpak rond risicoanalyse en de rol van Fedict hierin. Een inschatting van de tijd nodig voor Fedict om deze rol te vervullen VERANTWOORDELIJKHEDEN In deze sectie geven we aan waar de verantwoordelijkheid van de leverancier en Fedict liggen Algemeen We gaan er van uit dat de leverancier een professional is in het ontwikkelen van software en over de nodige domeinkennis beschikt. Wanneer de leverancier dankzij deze kennis tekortkomingen zou ontdekken in de specificaties die ertoe zouden kunnen leiden dat het systeem onder test niet fit-for-purpose is, gaan we er vanuit dat hij Fedict daarvan onverwijld op de hoogte stelt zodat hiervoor tijdig een oplossing kan gevonden worden. Het is duidelijk dat de voorgaande bewering soms contractuele bepalingen kan overschrijden, maar het is steeds in het belang is van beide partijen dat er een bruikbaar systeem wordt opgeleverd. Het is de bedoeling dat de leverancier een volledig getest en correct werkend systeem oplevert aan Fedict. Hierbij hoort ook de oplevering van de testdocumentatie zoals beschreven in het volgende hoofdstuk en eventueel verder gespecifieerd in een lastenboek of requirementsdocument. Fedict zal dan op dit systeem acceptatietests uitvoeren om na te gaan of alle vereisten effectief zijn vervuld Lagere test levels De testlevels unit (component tests), integratietests, en systeemtests of de daarmee overeenkomstige levels,zoals gebruikt door de leverancier vallen volledig onder de verantwoordelijkheid van de leverancier. Fedict zal steekproefsgewijs nagaan of de werkproducten voldoen aan de gestelde vereisten Systeem Integratietests Bij de systeem integratietests is het mogelijk dat systemen van de leverancier moeten geïntegreerd worden met systemen van andere leveranciers of van de overheid. In deze is samenwerking noodzakelijk. Fedict zal in deze een faciliterende rol spelen, maar de eindverantwoordelijkheid ligt bij de leverancier van het systeem onder test. Fedict zal steekproefsgewijs nagaan of de werkproducten voldoen aan de gestelde vereisten. 14

15 Acceptatietests De testanalyse, het testdesign en de testimplementatie van een basis set acceptatietests gebeurt door de leverancier. Fedict zal steekproefsgewijs nagaan of deze werkproducten voldoen aan de gestelde vereisten en kan ook additionele testscenario's voorzien. Fedict zal de tests uitvoeren en de test resultaten gebruiken voor het accepteren van het systeem of desgevallend het vragen van correcties SEVERITY (ERNST) De severity (ernst) van een defect is dikwijls een bron van discussie bij acceptatie van een systeem. [Normatieve sectie] Fedict hanteert volgende definities inzake severities. Elke afwijking hiervan dient contractueel vastgelegd te worden voor de start van een project. Critical Een testcase kan op geen enkele manier beëindig worden. Bv: een submit van gegevens geeft een foutboodschap, de applicatie crasht, etc High Een testcase kan beëindigd worden maar het gedrag van de applicatie is niet conform de specificaties. Bv: een cancel knop doet een submit, een lijst met gegevens wordt niet correct weergegeven, etc Medium Een testcase kan beëindigd worden conform de specificaties maar er zijn fouten die door manuele interventies (zonder de source code te wijzigen) kunnen omzeild worden. Bv: een foute controle van een veld, etc Low Nice to have Er zijn cosmetische problemen (spelling, lay-out, kleuren) die het functioneren van de applicatie weinig beïnvloeden. "niet conform specificaties" moet hierbij geïnterpreteerd worden als: werkt niet zoals beschreven in het lastenboek, het requirementsdocument of andere door Fedict goedgekeurde specificaties. In 15

16 geval verschillende specificaties niet consistent zijn, zal de voor Fedict meest gunstige interpretatie gebruikt worden. [Einde normatieve sectie] 16

17 3. Vereisten voor de leverancier 3.1. ALGEMEEN Deze sectie bevat de standaard op te leveren werkproducten, de daaraan gekoppelde kwaliteitscriteria en de vereisten om het systeem onder test te installeren in de verschillende omgevingen. Dit hoofdstuk is normatief, behalve waar expliciet is vermeld dat dit niet het geval is. In de lastenboeken en bijhorende requirements documenten of in de contracten tussen de leverancier en Fedict kunnen de hier beschreven vereisten wijzigen, zowel in de zin van het stellen van meer of strengere vereisten als in het opleggen van minder strenge vereisten. Voor alle aspecten van het test proces die niet expliciet veranderd worden in contractueel relevante documenten moet de inhoud van dit hoofdstuk gezien worden als test requirements INHOUD VAN DE OP TE LEVEREN WERKPRODUCTEN De op te leveren werk producten dienen in principe minstens de gegevens te bevatten zoals vermeld in de templates (sjablonen) beschreven in annex 1. Individuele lastenboeken, requirementsdocumenten of contracten kunnen bijkomende vereisten stellen aan de inhoud. Indien hiervan wordt afgeweken dient de leverancier hier de reden voor te documenteren ofwel in de testplannen ofwel in de documenten waarin wordt afgeweken, telkens met vermelding van de reden voor de afwijking. Wanneer de leverancier zijn eigen templates gebruikt dient hij zich ervan te vergewissen dat ze de nodige informatie bevatten en dient hij op vraag van Fedict een mapping tussen zijn structuur en deze in de templates in annex voor te leggen. Het verstrekken van deze templates houdt NIET in dat Fedict vraagt om deze templates te gebruiken om effectief documenten te genereren. [niet normatief] Het zij duidelijk dat ze vooral dienen als checklist. In een aantal gevallen is het zeker aan te raden om de gevraagde informatie op te slaan in een tool, eerder dan in MS Office documenten.[einde niet normatieve sectie] 17

18 3.3. OP TE LEVEREN WERKPRODUCTEN (DELIVERABLES) Algemene documenten Offerte De leverancier zal de testaanpak en het testproces dat hij zal gebruiken voor de opdracht beschrijven in de offerte. De verwachtingen van Fedict in dit verband zijn dat het gaat om een gestructureerd en gecontroleerd proces dat de gevraagde deliverables tijdig en correct kan opleveren Test plan(nen) De leverancier zal een testplan opleveren waarin hij de testdoelen en de verschillende testobjectieven per testlevel uiteenzet. Dit plan kan bestaan uit 1 document of uit een master testplan en een level testplan (per test level). De oplevering van het testplan dient ten laatste voor de eerste oplevering van de software plaats te vinden. Het Master testplan dient onderhouden te worden tot de finale oplevering van de software. De inhoud omvat minstens de elementen genoemd in de overeenkomende template in annex. Fedict zal controleren of de geleverde plannen voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirementsdocument of andere contractuele overeenkomsten. Het is in het belang van beide partijen dat de plannen zo snel mogelijk opgeleverd en gecontroleerd worden om herwerking en eventuele vertragingen bij de acceptatiefase te vermijden Master test summary report Bij elke oplevering van software aan Fedict zal de leverancier een (master) test summary report voegen. De inhoud omvat minstens de elementen genoemd in de overeenkomende template in annex en rapporteert over elk testlevel dat reeds is uitgevoerd Unittests Bij elke oplevering van software aan Fedict zal de leverancier een overzicht van de unittest gevallen alsook enkele relevante gevallen zelf mee opleveren. De andere testgevallen moeten ter beschikking gesteld worden indien en wanneer Fedict daar om vraagt. Het kan hier gaan om code of om manuele testgevallen. De unittest gevallen omvatten minstens een geautomatiseerde test suite die in elke testomgeving en in de productieomgeving kan worden uitgevoerd en die minstens een dekkingsgraad (statement coverage) van 75% heeft. Deze coverage moet aangetoond worden op de opgeleverde versie van de 18

19 software. Dit gebeurt met behulp van een tool die eventueel ter beschikking gesteld wordt voor Fedict. Een test summary report (of geautomatiseerd test dashboard) wordt mee opgeleverd. [niet normatief] We raden de leverancier aan om hierbij een systeem van continue integratie of een daily build met geïntegreerde test cases te hanteren.[einde niet normatief gedeelte] Fedict zal steekproefsgewijs controleren of de geleverde unittests voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirementsdocument of andere contractuele overeenkomsten. [niet normatief] Voor complexe of kritieke projecten zal de dekkingsgraad verhoogd worden of kan er worden overgegaan naar een strengere dekkingsvorm zoals bijvoorbeeld decision of condition coverage. [einde niet normatief gedeelte] Input Functionele documenten Technisch design documenten Code van individuele componenten Acties Testen van de individuele componenten Output (deliverables) Testgevallen (test case specificatie), inclusief een geautomatiseerde test suite Testresultaten Test summary rapport (of dashboard) Rol Fedict Steekproefsgewijze controle Integratietests Bij elke oplevering van software aan Fedict zal de leverancier de component integratietestgevallen mee opleveren. Het kan hier gaan om code of om manuele testgevallen. Bij elke oplevering van software aan Fedict zal de leverancier de systeem integratietestgevallen mee opleveren voor zover de systeem integratie al is uitgevoerd en van toepassing is. Het kan hier gaan om geautomatiseerde of om manuele testgevallen. De leverancier zal aantonen (bijvoorbeeld door oplevering van een traceerbaarheidsmatrix) dat: alle interne componenten geïntegreerd zijn. elke externe interface is getest op volgende aspecten: o de communicatie over deze interface functioneert. o de interpretatie van de uitgewisselde data is dezelfde voor beide systemen. Zo dit relevant is en van zodra de systeem integratie heeft plaatsgevonden zal de leverancier ook aantonen dat de end-to-end flow van de applicatie functioneel is door getest (end-to-end tests op basis van de business analyse, chain-testing). 19

20 [niet normatief] We raden de leverancier aan om minstens een deel van de component integratietests op te nemen in een systeem van continue integratie of een daily build. [einde niet normatief gedeelte] Fedict zal steekproefsgewijs controleren of de geleverde integratietests voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirements document of andere contractuele overeenkomsten. Input Business analyse (voor de systeem integratietests) Functionele documenten Design documenten Source code van de te integreren componenten Artefacten van de te integreren componenten Acties Testen van de interfaces tussen de componenten Testen van het de interfaces tussen het systeem en zijn peer-systemen End-to-end testen van functionele en niet functionele kwaliteitsattributen Output Testgevallen (test case design en test case specificatie) Testresultaten Test summary report Traceerbaarheidsmatrices Rol Fedict Steekproefsgewijze controle Systeemtests Bij elke oplevering van software aan Fedict zal de leverancier de systeemtest gevallen mee opleveren voor zover dit al van toepassing is. Het kan hier gaan om geautomatiseerde of om manuele testgevallen. De leverancier zal aantonen (bijvoorbeeld door oplevering van een traceerbaarheidsmatrix) dat de volledige functionaliteit zoals beschreven in door Fedict goedgekeurde functionele documenten is afgedekt en de risicoanalyse effectief gerespecteerd is. De leverancier zal aantonen (bijvoorbeeld door oplevering van een traceerbaarheidsmatrix) dat de niet-functionele kwaliteitsattributen voorzien om te testen op systeemtestniveau in het desbetreffende testplan effectief zijn afgedekt. Fedict zal steekproefsgewijs controleren of de geleverde systeemtests voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirementsdocument of andere contractuele overeenkomsten. Input Functionele documentatie Acties Testen van de functionaliteit van het geïntegreerde systeem Testen van niet functionele kwaliteitsattributen van het geïntegreerde systeem 20

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld.

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld. 1. 1.1. Inleiding Doel In de discipline vindt de validatie van datgene wat binnen het project is gerealiseerd plaats. Dit bestrijkt het gebied van unittest tot en met acceptatie door gebruikers en beheerorganisatie.

Nadere informatie

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Versie

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Test rapportage Waarom eigenlijk?

Test rapportage Waarom eigenlijk? Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015 @JurianvdL Jurian van de Laar

Nadere informatie

Martin van Leeuwen Happy Testing

Martin van Leeuwen Happy Testing Titel, samenvatting en biografie Samenvatting: Deze presentatie beschrijft een aantal test maatregelen die in een RUP nieuwbouw project zijn genomen, om ervoor te zorgen dat het testen aan het eind van

Nadere informatie

Software Test Document

Software Test Document Software Test Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

ISTQB Foundation level. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ISTQB Foundation level. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. ISTQB Foundation level Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval.

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval. TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE Kwaliteit zonder gestructureerd testen is toeval Inhoudsopgave 1. Inleiding 2. De TMap methode 3. De fase Planning & Beheer 4. De fase testspecificatie 5. De

Nadere informatie

Agile Testen in de praktijk

Agile Testen in de praktijk 1 Agenda 2 Agile Testen in de praktijk Summerschool 13 Juli 2011 Introductie Agile de context van agile Testen2.0 de tester in een agile project Waarden en principes DoD, PRA en MTP Testen3.0 in een agile

Nadere informatie

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Henrik Rexed & Joerek van Gaalen Voorstellen Joerek van Gaalen Performancetest specialist sinds 2005 Sinds 2014 CTO Computest Voorstellen

Nadere informatie

ISACA round-table 7 december 2009 Rik Marselis

ISACA round-table 7 december 2009 Rik Marselis ISACA round-table 7 december 2009 Rik Marselis Senior Testconsultant bij Sogeti Penningmeester van BNTQB, de member board voor België en Nederland van de International Software Testing Qualifications Board

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

Testgedreven ontwikkeling dat is pas veilig!

Testgedreven ontwikkeling dat is pas veilig! Testgedreven ontwikkeling dat is pas veilig! INTRODUCTIE ANKO TIJMAN 2 Software tester sinds 1997 (TMap, ISEB Practitioner) Eerste agile ervaring in 2001 Presentaties op (inter)nationale congressen Nov

Nadere informatie

Handleiding voor de checklist Overdracht project/change naar beheer. Handleiding : Frédéric van der Vaeren

Handleiding voor de checklist Overdracht project/change naar beheer. Handleiding : Frédéric van der Vaeren Auteur(s) Datum Versie Frédéric van der Vaeren 11/03/2013 2.0 Eigenaar Doelpubliek Bert van Hemelen Gebruikers checklist overdracht project/change naar beheer Handleiding : Handleiding voor de checklist

Nadere informatie

Van requirements naar teststrategie

Van requirements naar teststrategie Van requirements naar teststrategie Testnet 7 januari 009 Ruud Harreman Appie Pries Waarom dit onderwerp? Leveranciersperspectief Bestaande testmethodes geven weinig aanknopingspunten hoe requirements

Nadere informatie

BDD/Gherkin. Een introductie

BDD/Gherkin. Een introductie BDD/Gherkin Een introductie Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. BDD... 4 3. Gherkin... 5 4. BDD-Tools... 6 5. Voordelen... 7 6. Benodigde kennis en vaardigheden...

Nadere informatie

Webtesten onder schaarste

Webtesten onder schaarste Testnet najaarsevenement 2005 B e y o n d t h e o r d i n a r y Webtesten onder schaarste Vincent Staal ORDINA NV Ringwade 1 Postbus 7101 3430 JC Nieuwegein Tel: 030 6637000 Fax: 030 6637099 www.ordina.nl

Nadere informatie

Anand T hakur. Over Anand

Anand T hakur. Over Anand Anand T hakur Over Anand 1987 Anand Thakur is een TMAP Next gecertificeerde testcoördinator. Mede door zijn analytisch vermogen, objectiviteit, senioriteit, vermogen om onder druk te werken en geode stakeholder

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

Ministerie van Infrastructuur en Milieu Beheerst naar beheer

Ministerie van Infrastructuur en Milieu Beheerst naar beheer Document D-2 Ministerie van Infrastructuur en Milieu Beheerst naar beheer Versie 1.0 Datum 15 juli 2014 Status Definitief Colofon Versie 1.0 Contactpersoon Paul Leunissen M 06-5250 6691 Paul.Leunissen@minienm.nl

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan FACULTEIT WETENSCHAPPEN Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie Datum Auteur Commentaar 0.1 09/11/2010 Jeroen Van den haute Eerste versie 0.2 12/11/2010

Nadere informatie

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V.

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V. Regressietesten De aanpak en aandachtspunten Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING...3 1.1 ALGEMEEN...3 1.2 VERSIEBEHEER...3

Nadere informatie

Woordenlijst bij TMap

Woordenlijst bij TMap Woordenlijst bij TMap Acceptatietest De door de toekomstige gebruiker(s) en beheerder(s) in een zoveel mogelijk als-ware-het-productie omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

Voorbeeldexamen. Testen Foundation. Editie maart 2012

Voorbeeldexamen. Testen Foundation. Editie maart 2012 Voorbeeldexamen Testen Foundation Editie maart 2012 Copyright 2012 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system or circulated

Nadere informatie

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt

Nadere informatie

Wij testen..maar....wat test jij?

Wij testen..maar....wat test jij? Wij testen..maar....wat test jij? Wij testen maar wat test jij? Harm Pul, Busineslinemanager Functioneel Beheer TMAP dag 2015, 29 september 2015 Bussum 2 Herkent u dit? De gebruikers testen dit straks

Nadere informatie

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Mislukken Slagen gegarandeerd 2 Mislukken Slagen gegarandeerd Management verwacht onmiddellijk R.O.I. Doel:

Nadere informatie

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite Managen van een Ketentest bij NS met hun TOPAAS tool-suite Bart Broekman mei 2014 Onderwerpen De (prachtige) TOPAAS tooling De (niet zo prachtige) project-situatie De (oh zo mooie) dingen die we ermee

Nadere informatie

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter 2 Opdrachtgever : Opdrachtnemers : Ing. P. van den Berg Michel van Reenen Thijs Mommen GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

Nadere informatie

Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert

Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert Hoe en waarom DevOps de wereld van performance testen verandert Najaarsevenement 14 oktober 2015 Inleiding Wie zijn we Marc Koper: Specialist in performancetesten / testautomatisering HenkJaap van den

Nadere informatie

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. 1. 1.1. Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline

Nadere informatie

WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING BUSINESS AGILITY ITERATIEVE AANPAK ONTWIKKELSTRAAT

WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING BUSINESS AGILITY ITERATIEVE AANPAK ONTWIKKELSTRAAT WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING Voor het bereiken van business agility is meer nodig dan een juiste architectuur en is een iteratieve aanpak essentieel. Daarvoor is

Nadere informatie

Offshoring & Testing. Verander een uitdaging in een kans. Door Ernst Labruyère. re Consultant ps_testware. 20 september 2007

Offshoring & Testing. Verander een uitdaging in een kans. Door Ernst Labruyère. re Consultant ps_testware. 20 september 2007 Offshoring & Testing Verander een uitdaging in een kans Door Ernst Labruyère re Consultant ps_testware 20 september 2007 Ernst Labruyere- Offshoring en Testing: : Verander een uitdaging in een kans - 1

Nadere informatie

Organisatie SYSQA B.V. Pagina 1 van 6 Titel Overzicht Versie 1.0 Onderwerp Overzicht blackbox testtechnieken Datum 15 februari 1996

Organisatie SYSQA B.V. Pagina 1 van 6 Titel Overzicht Versie 1.0 Onderwerp Overzicht blackbox testtechnieken Datum 15 februari 1996 Organisatie SYSQA B.V. Pagina 1 van 6 Black-Box Test Technieken Er zijn een aantal test specificatie technieken, verder testtechnieken genoemd, die bruikbaar zijn binnen het black-box acceptatietesten.

Nadere informatie

Informatica 2 Studiehandleiding

Informatica 2 Studiehandleiding Informatica 2 Studiehandleiding Embedded Systems Engineering Groep: ES1D ir drs E.J Boks 25-02-2010 Inhoud 1 Inleiding... 2 2 Doelstelling... 3 3 Beoordeling... 4 4 Eisen aan het verslag... 6 Voorbeeld

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

Clean code improves test quality

Clean code improves test quality Clean code improves test quality Michel Kroon, Senior Consultant, SIG TestNet Voorjaarsevenement 30 juni 2008 Arent Janszoon Ernststraat 595-H NL-1082 LD Amsterdam info@sig.nl www.sig.nl De Software Improvement

Nadere informatie

a. Wat wordt verstaan onder V&V? b. Uit welke kernactiviteiten bestaat V&V? c. Noem enkele voor- en nadelen van inspecties. d. Idem voor testen.

a. Wat wordt verstaan onder V&V? b. Uit welke kernactiviteiten bestaat V&V? c. Noem enkele voor- en nadelen van inspecties. d. Idem voor testen. Eindtoets T07351 Software engineering Een eindtoets staat in het algemeen model voor het tentamen van de betreffende cursus. Aangezien deze cursus een mondeling tentamen heeft, bevat deze eindtoets slechts

Nadere informatie

Testing University. A fool with a tool is still a fool

Testing University. A fool with a tool is still a fool Testing University A fool with a tool is still a fool Test Tooling is een must Must? Test Tooling? 2 Als je iets moet kun je dan wel de juiste keuzes maken? Moeten Willen 3 Van moeten naar willen Moeten

Nadere informatie

Testen bij DWH-projecten

Testen bij DWH-projecten Testen bij DWH-projecten Snelheid, Kwaliteit, Flexibiliteit onder úw regie Armando Dörsek, Software Control 18-09-2007 Wat gaat u horen? Testen van DW/BI > Structureren & Plannen Project- en teamstructuur

Nadere informatie

Plan van aanpak Toogle

Plan van aanpak Toogle Plan van aanpak Toogle Gemaakt door, Kevin Donkers Paul v.d. Linden Paul Eijsermans en Geert Tapperwijn 1 Inhoudsopgave 1 Inhoudsopgave...2 2 Inleiding...3 3 Projectopdracht...4 4 Projectactiviteiten...5

Nadere informatie

Erwin van den Hul De stappen van een complexe risico analyse matrix naar concreet testen

Erwin van den Hul De stappen van een complexe risico analyse matrix naar concreet testen Titel, samenvatting en biografie Erwin van den ul De stappen van een complexe risico analyse matrix naar concreet testen Samenvatting: Zie volgende pagina. Biografie: Erwin heeft ruim 10 jaar aansprekende

Nadere informatie

Welkom. Great SAP Test Experience. 23 maart 2015

Welkom. Great SAP Test Experience. 23 maart 2015 Welkom Great SAP Test Experience 23 maart 2015 Sogeti PowerPoint Referentie 2014 2 5 5 Sogeti PowerPoint Referentie 2014 3 Sogeti PowerPoint Referentie 2014 4 Sogeti PowerPoint Referentie 2014 5 En toch

Nadere informatie

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN Copyright Sogeti Nederland B.V. te Vianen Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor willekeurig welke doeleinden)

Nadere informatie

Procesvalidatie voor een veiliger ketentest

Procesvalidatie voor een veiliger ketentest Procesvalidatie voor een veiliger ketentest Johan Vink TestNet Voorjaarsevenement 2010 Agenda Inleiding Typering project & testaanpak Werkwijze business proces Probleem De opdracht voor het testteam Probleemanalyse

Nadere informatie

Testen van digitale leeromgevingen bij ThiemeMeulenhoff. Een Exploratory testaanpak in een veranderende wereld.

Testen van digitale leeromgevingen bij ThiemeMeulenhoff. Een Exploratory testaanpak in een veranderende wereld. Testen van digitale leeromgevingen bij ThiemeMeulenhoff Een Exploratory testaanpak in een veranderende wereld. Hallo! Rob van Steenbergen Tester sinds 1996 Diverse rollen Sinds 2008: Chickenwings Test

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

Nadere informatie

Parasoft toepassingen

Parasoft toepassingen Testen op basis van OSB en Digikoppeling Voor de bestaande Overheid Service Bus en de nieuwe standaard Digikoppeling zijn verschillende test- omgevingen opgezet. Hiermee kan het asynchrone berichtenverkeer

Nadere informatie

Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel

Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel Doelstelling Introductie Practis en Producten Project bij Achmea Testaanpak Concrete toepassing van Rational

Nadere informatie

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RAD Rapid application development Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT

Nadere informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

Ontwikkelen en testen van e-business: beheerste dynamiek Ontwikkelen en testen van e-business: beheerste dynamiek Het ontwikkelen en gestructureerd testen van administratieve systemen is gebaseerd het watervalprincipe. Bij het ontwikkelen volgens het watervalprincipe

Nadere informatie

Workshop 12 ART-DECOR en Acute overdracht. Michael Tan Kai Heitmann Maarten Ligtvoet

Workshop 12 ART-DECOR en Acute overdracht. Michael Tan Kai Heitmann Maarten Ligtvoet Workshop 12 ART-DECOR en Acute overdracht Michael Tan Kai Heitmann Maarten Ligtvoet 22 november 2012 Topics Aanpak en visie Perinatologie Michael Tan Uitleg Acute Overdracht in ART-DECOR Kai Heitmann Faciliteren

Nadere informatie

TestFrame. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

TestFrame. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. TestFrame Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 13 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 2 TESTFRAME... 4 2.1 TESTFRAME ALS

Nadere informatie

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014 Werkgroep ISO29119 TestNet thema-avond 9 oktober 2014 Is dit n gezonde maaltijd? Ja toch!! Om jezelf een oordeel te kunnen vormen heb je informatie nodig!! Vandaag brengen we kennis en informatie bij elkaar

Nadere informatie

Continuous testing in DevOps met Test Automation

Continuous testing in DevOps met Test Automation Continuous ing in met Continuous testing in met Marco Jansen van Doorn Tool Consultant 1 is a software development method that emphasizes communication, collaboration, integration, automation, and measurement

Nadere informatie

TESTAUTOMATISERING IN EEN ETL-OMGEVING

TESTAUTOMATISERING IN EEN ETL-OMGEVING Pagina 21 TESTAUTOMATISERING IN EEN ETL-OMGEVING Door John Kronenberg John.Kronenberg@bartosz.nl @johnkronenberg Edward Crain Edward.crain@divetro.nl Welke groeifasen werden doorlopen in testautomatisering

Nadere informatie

TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl

TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl Testers helpen ontwikkelaars of andersom? TestNet Voorjaarsevenement 2010 Jurian van de Laar 12 mei 2010 info@improveqs.nl Improve Quality Services B.V. 2 Agenda Hoe veilig is een muur? Past Scrum ook

Nadere informatie

Test Coördinatie Introductie

Test Coördinatie Introductie your reference in testing services Test Coördinatie Introductie 1 Gent, 4 april 2011 Wat verstaan jullie onder testen? En testcoördinatie? 2 Hoe zien jullie het? Testen bestaat uit activiteiten die uitgevoerd

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

C.A.S.T. Make it as simple as possible, but not simpler. Make IT as simple as possible, but not simpler. Complexiteit. Einstein maakte het simpel

C.A.S.T. Make it as simple as possible, but not simpler. Make IT as simple as possible, but not simpler. Complexiteit. Einstein maakte het simpel Geautomatiseerd Testen Complexiteit Valori Meeting of Minds, 28 juni 2011 1 2 Einstein maakte het simpel Make it as simple as possible, but not simpler (Einstein) 3 4 Waar staat dit voor? Make IT as simple

Nadere informatie

Selenium IDE Webdriver. Introductie

Selenium IDE Webdriver. Introductie Selenium IDE Webdriver Het Wielsem 10, 5231 BW s- Hertogenbosch, telefoon 073-6409311 e- mail info@testwork.nl internet http://www.testwork.nl 1 Inhoudsopgave 1 Inhoudsopgave... 2 2 Selenium IDE... 3 3

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

Sjabloon testplan o.b.v. situationeel testen. <>

Sjabloon testplan o.b.v. situationeel testen. <<Organisatie>> Sjabloon testplan o.b.v. situationeel testen SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 11 Over dit sjabloon Dit

Nadere informatie

ERP Testing. HP Nijhof. Testmanager. Testnet November 2005

ERP Testing. HP Nijhof. Testmanager. Testnet November 2005 ERP Testing HP Nijhof Testmanager Testnet November 2005 Solution Sales Meeting7 November 2005 1 Agenda Waarom pakketten testen? Schaarse middelen? Ideale ERP test situatie Vragen 2 De centrale vraag ERP

Nadere informatie

voorbeeldexamen TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie TMPF_2.

voorbeeldexamen TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie TMPF_2. voorbeeldexamen TMPF_2.0 TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie EXIN Hét exameninstituut voor ICT ers Janssoenborch, Hoog Catharijne

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan PEN: Paper Exchange Network Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Contents 1 Overzicht 1 1.1 Samenvatting project.........................

Nadere informatie

Rapport Richtlijn gebruik productiegegevens

Rapport Richtlijn gebruik productiegegevens Rapport Richtlijn gebruik productiegegevens Documenthistorie Datum en versienummer Auteur Opmerking Versie 1.0, 20 december 2005 M. van der Werff, B. de Wit Ter vaststelling door DPB Goedkeuring Datum

Nadere informatie

Customer Case: WoningNet

Customer Case: WoningNet Customer Case: WoningNet WoningNet en Webservices Woonruimtebemiddeling Shared service center Business uitdaging Architectuur visie Woonruimtebemiddeling Woningzoekende Corporatiemedewerker Corporatiemedewerker

Nadere informatie

De tester als bruggenbouwer

De tester als bruggenbouwer De tester als bruggenbouwer Tim Koomen Testnet voorjaarsevenement 9 juni 2004 Agenda Bruggen Enkele bruggen toegelicht De bruggenbouwer Trends Sogeti Nederland B.V. Pagina 1 Bruggen Systeem Beheer Stuur

Nadere informatie

Teststrategien. Hebben we wel het juiste gebouwd? Pieter van den Hombergh. 20 februari 2014

Teststrategien. Hebben we wel het juiste gebouwd? Pieter van den Hombergh. 20 februari 2014 Teststrategien Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 20 februari 2014 HOM/FHTeL Teststrategien 20 februari 2014 1/33 1 points 2 Review plan debugging

Nadere informatie

PROJECT MANAGEMENT 1 PROJECT MANAGERS CHECKLIST

PROJECT MANAGEMENT 1 PROJECT MANAGERS CHECKLIST 1 WE SCHIJNEN ALTIJD TIJD TE VINDEN OM HET OVER TE DOEN?! LATEN WE HET DE EERSTE KEER - GELIJK GOED DOEN! Overdracht van het Offerte Team Heb je een kopie van het kosten- en/of prijsmodel? Heb je een kopie

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

Service Virtualization @RABOBANK

Service Virtualization @RABOBANK Service Virtualization @RABOBANK TMA Dag 2015 eter Claassen RABOBANK Marc van Lint - IBM Agenda 1. Rabobank Context 2. DevOps Vision 3. roof en Implementeren 4. Voorbeelden 5. Ervaringen & Best ractices

Nadere informatie

Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010

Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010 Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010 Organisatie Het CIBG is een uitvoeringsorganisatie van het ministerie van Volksgezondheid, Welzijn en Sport.

Nadere informatie

your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008

your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008 your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008 Onderwerpen vandaag Geen theoretische achtergrond Gebaseerd op eigen praktijk Niet uit boeken te halen

Nadere informatie

Titel, samenvatting en biografie

Titel, samenvatting en biografie Titel, samenvatting en biografie \ Peter Wanders De Black Box Dialog methode Voorjaarsevent Testnet: 22 juni 2009 Samenvatting Nog nooit heb ik heb een klant horen zeggen: Enorm vervelend dat het IT project

Nadere informatie

End-to-End testen: de laatste horde

End-to-End testen: de laatste horde End-to-End testen: de laatste horde Dieter Arnouts Agenda Begrip End-to-End testen in het test proces Praktische aanpak End-to-End Test Omgeving Uitdagingen End-to-End testen: De laatste horde 11/10/2010

Nadere informatie

Testaanpak: leidraad voor het kiezen van een testtechniek

Testaanpak: leidraad voor het kiezen van een testtechniek Testaanpak: leidraad voor het kiezen van een testtechniek SYSQA B.V. Almere Datum : 18 november 2012 Status : Definitief Opgesteld door : Organisatie: SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding...

Nadere informatie

Teststrategien. Pieter van den Hombergh. 20 februari 2014. Fontys Hogeschool voor Techniek en Logistiek Software Engineering

Teststrategien. Pieter van den Hombergh. 20 februari 2014. Fontys Hogeschool voor Techniek en Logistiek Software Engineering Teststrategien Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 20 februari 2014 HOM/FHTeL Teststrategien 20 februari 2014 1/33 1 Acceptatietesten Belangen Inhoud

Nadere informatie

Whitepaper Test Management Business case voor geautomatiseerd testen

Whitepaper Test Management Business case voor geautomatiseerd testen Whitepaper Test Management Business case voor geautomatiseerd testen Waarom we informatiesystemen testen behoeft geen uitleg: Testen is nodig om inzicht te geven in de kwaliteit. Het voorkomen van risico

Nadere informatie

Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur

Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur Acceptatietesten en testmanagement Examennummer: 93453 Datum: 29 maart 2014 Tijd: 10:00 uur - 11:30 uur Dit examen bestaat uit 7 pagina s. De opbouw van het examen is als volgt: - 20 meerkeuzevragen (maximaal

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

Offerte voor het bouwen van een website Klant: Ideefiks, IdeeKids

Offerte voor het bouwen van een website Klant: Ideefiks, IdeeKids Offerte voor het bouwen van een website Klant: Ideefiks, IdeeKids Consultant: Dirk Derom Inhoudstafel Algemene structuur van de website...6 Front pagina...6 Pagina IDEEFIKS/IDEEKIDS...6 Functionaliteit...10

Nadere informatie

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer

Nadere informatie

End-to-End Testen Acceptatietesten

End-to-End Testen Acceptatietesten End-to-End Testen Acceptatietesten Gerard Numan Polteq Test Services BV Agenda Krachtenveld V-model Hoe 2 1 Krachtenveld Techniek drijft de wereld Techniek overschrijdt alle grenzen Continue en parallelle

Nadere informatie

Vraag 1... Vraag 2... Vraag 3...

Vraag 1... Vraag 2... Vraag 3... Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. Elke theorie-vraag staat ofwel op 1.5 ofwel op 2 punten, en elke oefening op 10 punten. Het geheel staat op 60. Vraag 1...[.../3]

Nadere informatie

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technisch systemen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Systeem categoriën Technische op computer gesteunde systemen Systemen die HW en SW bevatten, maar waar

Nadere informatie

TMap NEXT Test Engineer

TMap NEXT Test Engineer Voorbeeldexamen TMap NEXT Test Engineer Editie juni 2013 Copyright 2013 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

Tools die je móét hebben voor je (gaat) testen!

Tools die je móét hebben voor je (gaat) testen! Voorjaarsevenement 2008 Tools die je móét hebben voor je (gaat) testen! Jurian van de Laar (jla@improveqs.nl) 1 Improve Quality Services Dienstverlener Testen & Kwaliteitsmgt. Advisering, Detachering en

Nadere informatie

SEN1 Software Engineering 1

SEN1 Software Engineering 1 SEN1 Software Engineering 1 Pieter van den Hombergh Ferd van Odenhoven Fontys Hogeschool voor Techniek en Bedrijfsmanagement Software Engineering 6 maart 2008 FvO,PvdH/FHTBM SEN1 Software Engineering 1

Nadere informatie

TMap NEXT Test Engineer

TMap NEXT Test Engineer Voorbeeldexamen TMap NEXT Test Engineer Editie juli 2011 Copyright 2011 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

Proces to model en model to execute

Proces to model en model to execute Proces to model en model to execute Een end-to-end (bedrijfs)proces (figuur 1) is het geheel van activiteiten die zich, op een bepaalde plaats door een bepaalde rol, in bepaalde volgorde opvolgen en waarvan

Nadere informatie

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

Nadere informatie

Agile bij grote administratieve systemen. Omgaan met requirements

Agile bij grote administratieve systemen. Omgaan met requirements Agile bij grote administratieve systemen Omgaan met requirements 1 Agenda Wat is een groot systeem? Aanpak van een groot systeem Agile alignment Agile en requirements (en architectuur) Agile en governance

Nadere informatie

Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele

Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele Whitepaper Exploratory Testing Waarom doen we dat niet altijd? door Dennis Joele Dennis Joele is werkzaam als test designer bij TriOpSys en heeft als zodanig voor de Dienst der Hydrografie van de Koninklijke

Nadere informatie

Inhoud Deel een Het ontwikkeltraject 1 2 3

Inhoud Deel een Het ontwikkeltraject 1 2 3 5 Inhoud Inleiding 11 Deel een Het ontwikkeltraject 13 1 Werken binnen organisaties 15 1.1 Non-profit-organisatie 15 1.2 Profit-organisatie 16 1.3 Doelen 16 1.4 Rechtsvormen 16 Rechtspersoon 17 Persoonlijke

Nadere informatie