Whitepaper Process Driven Requirements Testing
|
|
- Thijs van de Veen
- 8 jaren geleden
- Aantal bezoeken:
Transcriptie
1 Whitepaper Process Driven Requirements Testing
2 Inleiding Een acceptatietest is een door gebruikers uitgevoerde test met als doel het vaststellen of een oplossing (ICT en non-ict) voldoet aan de requirements en aansluit op de processen. Deze whitepaper bedoelt met gebruikers de mensen die (delen van) de oplossing gaan gebruiken of beheren. Elke gebruiker is afnemer van de oplossing en heeft er belang bij dat de oplossing correct werkt. Gebruikers kunnen mensen zijn binnen de business (bijvoorbeeld binnen marketing, operations, finance). Andere gebruikers zijn klanten, leveranciers en beheerders van ICT-systemen. Bij acceptatietesten speelt een aantal problemen. Dit document gaat in op drie van deze problemen en reikt handvatten aan om ze te voorkomen. Probleemstelling 1. Acceptatietesten vinden veelal plaats op basis van systeemdocumentatie en niet tegen de oorspronkelijke requirements. Gevolg is dat de oplossing niet aansluit op de werkelijke gebruikersbehoefte. 2. Een acceptatietest legt een groot beslag op gebruikers. Testen kost hen veel tijd. Tijd die schaars is en ten koste gaat van hun dagelijks werk. 3. Bij de oplevering van een project is niet altijd duidelijk: Welke requirements binnen de scope waren. Of ze gerealiseerd zijn. Of ze expliciet getest zijn. Wat de uitkomst van de test was. Kostbare tijd gaat verloren om dit uit te zoeken. Process Driven Requirements Testing (PDRT) Process Driven Requirements Testing (PDRT) is een acceptatietest methode die vanuit gebruikers perspectief de oplossing toetst. Het is een aanvulling op de systeem(keten)test welke met name de werking van ICT-systemen beoordeelt. een project. PDRT neemt met andere woorden niet de systeemdocumentatie als uitgangspunt. Die documentatie beschrijft namelijk hoe de requirements worden gerealiseerd. De gebruikers zijn actief betrokken bij het bepalen welke requirements en processen kritiek zijn en grote impact hebben op hun dagelijks werk. Hierdoor creëert PDRT een afgewogen risicoanalyse met risico s vanuit business én ICT perspectief. Gebruikers zoveel mogelijk ontlasten PDRT biedt een vaste structuur voor testgevallen. Het format en de methode staan vast. Daardoor kan de testuitvoering eenvoudig worden uitbesteed aan professionele testers en kunnen gebruikers tijd besteden aan hun echte werk. Kortom, PDRT zet gebruikers in waar ze het meest van toegevoegde waarde zijn en houdt rekening met hun dagelijkse werk. Track en trace Projecten creëren veel documentatie waarin requirements, processchema s, testgevallen en dergelijke staan. Echter, het verband tussen (de juiste versies van) die elementen is lastig of niet te vinden. PDRT lost dit probleem met een Requirements Traceability Matrix (RTM) die de samenhang weergeeft tussen requirements, processen, testscripts, (ICT-)oplossingen, et cetera. Door deze informatie in de RTM op te slaan en in overige documenten ernaar te verwijzen worden overlap en duplicatie voorkomen. Zo bespaart PDRT veel zoektijd. Wat vertelt deze whitepaper over PDRT? PDRT is een aanvulling op bestaande testmethoden, zoals ISTQB en TMap NEXT. Omdat deze methoden noch technieken kennen om vanuit processen en requirements een risicoanalyse op te stellen noch handvatten aanreiken om op basis van requirements testcases te maken, biedt PDRT de benodigde aanvullingen. Deze whitepaper beschrijft met name hoe acceptatietestgevallen worden opgesteld. Business requirements en risico s zijn leidend PDRT gaat uit van testen op basis van de business requirements. Business requirements (hierna: requirements) zijn de verzameling eisen die gebruikers stellen bij aanvang van ICT zonder risico Pagina 2 van 10
3 Processen als brug tussen requirements en oplossing Een requirement maakt een reis door diverse documenten, voordat het uiteindelijk vertaald wordt naar een oplossing. De testbasis om deze oplossing te testen, bestaat doorgaans uit documenten zoals functionele en technische ontwerpen en niet de oorspronkelijke requirements. De vraag is dan of de test wordt uitgevoerd tegen de juiste testbasis. En of de acceptatietest een uitspraak kan doen of de oplossing aansluit op de gebruikersbehoefte. Zelfs als de requirements goed worden geïmplementeerd, dan nog is het voor de gebruiker moeilijk om zijn requirements te herkennen in de oplossing. En hoe weet een gebruiker dat een requirement niet is geïmplementeerd? Door in plaats van de ontwerpen en de systemen, de requirements als uitgangspunt te nemen, kunnen bovenstaande problemen worden voorkomen. Maar hoe verbind je de requirements met de oplossing als je de ontwerpdocumenten niet kunt gebruiken? Een proces vormt namelijk het bindende element tussen de requirements enerzijds en de oplossing anderzijds (zie afbeelding 1; links staan de requirements, in het midden het proces en rechts de oplossing). Immers, de requirements hebben betrekking op processen en de oplossing ondersteunt deze processen. Daarnaast biedt het centraal stellen van processen nog een aantal andere voordelen: Prioritering Processen zijn te onderscheiden in bedrijfskritische en niet-bedrijfskritische processen. Processen kennen een frequentie waarin ze voorkomen en hebben impact op een organisatie. Frequentie, impact en belang van processen zijn vanuit business perspectief belangrijke aspecten om te prioriteren. Herkenning Gebruikers zijn vertrouwd met hun processen. Ze werken er dagelijks mee. Acceptatietesten beschreven in termen van processen verbeteren de communicatie tussen gebruiker, tester en ICT. Het antwoord is eigenlijk eenvoudig: gebruik de processen als brug tussen de requirements en oplossing. Afbeelding 1. Processen als brug ICT zonder risico Pagina 3 van 10
4 Stappenplan PDRT hanteert een stappenplan om vanuit de requirements tot acceptatie van de oplossing te komen: 1. Opstellen risicoanalyse. Koppelen requirements aan processen en producten. Identificeren gebeurtenissen (business events) die een proces triggeren en opstellen business use cases (BUC s). Koppelen oplossingen aan BUC s. Opstellen risicoanalyse. 2. Opstellen testgevallen. 3. Uitvoeren acceptatietesten. 4. Afsluiten acceptatietest. Stap 1 gebeurt in twee fases. Eerst wordt op globaal niveau inzicht verkregen in de risico s. Daarna vindt verdieping van de risicoanalyse plaats. Bij kleine projecten worden beide iteraties geïntegreerd tot één stap. Stap 1. Opstellen risicoanalyse Het doel van een risicoanalyse is om te identificeren welke processen, requirements en onderdelen van de oplossing van belang zijn om te testen. Voor het testen bestaan grenzen in tijd en geld, waardoor een project afwegingen moet maken waar ze haar testtijd en geld in steekt. Koppelen requirements PDRT gaat er van uit dat de requirements aanwezig en geaccordeerd zijn. En dat er een beschrijving of schema van de processen bestaat. Per requirement wordt onderzocht op welk proces of product het requirement betrekking heeft (zie afbeelding 2). Een product is een input of output van een proces. Procesniveaus PDRT onderscheidt vier hiërarchische procesniveaus. Als voorbeeld staat achter elk niveau tussen haakjes een proces voor een online webshop. 1. Keten (Inkopen-Verkopen-Factureren) 2. Bedrijfsproces (Verkopen) 3. Werkproces (Bestellen) 4. Activiteit (Bevestigen bestelling) Deze hiërarchie is ook van toepassing op requirements. Een globale requirement geldt voor een gehele keten, bedrijfsproces of werkproces. Een detail requirement geldt voor een specifieke activiteit binnen een werkproces. Een voorbeeld Requirement A luidt: Tijdens het bestellen ziet de klant op elk moment de inhoud van zijn winkelwagentje. Dit requirement geldt voor het gehele werkproces Bestellen, dus alle activiteiten hierin. PDRT noemt dit een globaal requirement. Requirement B luidt: Als de klant de order bevestigt, moet hij ook de verkoopvoorwaarden accepteren. Dit requirement hoort alleen bij de activiteit Bevestigen bestelling. PDRT noemt dit een detail requirement. Koppeling van een detail requirement aan een keten, bedrijfsproces of werkproces voegt geen waarde toe: het is namelijk niet duidelijk voor welke stap in het proces het requirement geldt. Koppeling van een globale requirement aan een activiteit is weinig zinvol, omdat het requirement ten opzichte van de activiteit te globaal geformuleerd is, waardoor deze niet te testen is. Afbeelding 3 toont het tabel waarin de detail requirements worden gekoppeld aan activiteiten. Afbeelding 2. Koppelen requirements aan processen, input en output Het is zaak dat een requirement aan het juiste procesniveau gekoppeld wordt. Zie ook het kader over procesniveaus hiernaast. Afbeelding 3. Tabel requirements en activiteiten
5 Identificeren business events en business use cases Procesmodellen tonen hoe processen met elkaar samenhangen. Ze laten echter niet eenvoudig de volgorde van processen zien naar aanleiding van een bepaalde gebeurtenis. Deze extra dimensie wordt een business use case (BUC) genoemd. Een BUC beschrijft hoe een gebeurtenis (business event) wordt afgehandeld in combinatie met randvoorwaarden (precondities). De BUC doorloopt een aantal processen van een bepaald procesniveau en leidt tot een resultaat, bijvoorbeeld een product, dienst of halffabricaat (zie afbeelding 4). Afbeelding 4. Business use case structuur Een business event is bijvoorbeeld het plaatsen van een order. De preconditie is dat dit door een bestaande klant wordt gedaan (NAW-gegevens zijn al bekend). De klant doorloopt het orderproces en aan het eind daarvan heeft hij een order geplaatst. Het resultaat is derhalve een order. Op deze manier worden requirements en oplossing, via de processen, aan elkaar geknoopt (zie afbeelding 6). Afbeelding 6. Oplossing koppelen aan BUC s Zo wordt duidelijk welke ICT-systemen en handmatige oplossingen welke processen ondersteunen. Op het niveau van ketens, bedrijfs- en werkprocessen legt PDRT koppelingen met bijvoorbeeld systemen of interfaces uit de ICT architectuur. Op het niveau van activiteiten met systeemfuncties en schermen. De informatie over de oplossing haalt PDRT voor een globale risicoanalyse uit de globale impactanalyse van ICT en business en uit schema s van de ICT architectuur. De samenhang van de oplossing met de processen uit de BUC s komt terug in een tabel (zie afbeelding 7). Met het opstellen van de BUC s wordt feitelijk de tabel uit afbeelding 3 verder uitgebreid. Voor elke BUC wordt een tabel opgesteld zoals te zien in afbeelding 5. Afbeelding 7. Samenhang processen uit de BUC met de oplossing Afbeelding 5. Requirements opgenomen in BUC Koppelen oplossing Nadat inzichtelijk is welke BUC s samenhangen met welke requirements, koppelt PDRT de oplossing aan de BUC s. Globale risicoanalyse Het opstellen van een risicoanalyse vindt voor grote en complexe projecten plaats in twee fases. Eerst stelt PDRT een globale risicoanalyse op vanuit business en ICT perspectief. Voor een globale risicoanalyse is informatie nodig op een hoog niveau met betrekking tot requirements, BUC s en oplossingen. Op business niveau voert PDRT een analyse uit op het belang en de impact van de requirements en BUC s op de organisatie. De BUC s hebben bij een globale analyse betrekking op de ketens, bedrijfsprocessen of werkprocessen. ICT zonder risico Pagina 5 van 10
6 Vanuit ICT perspectief analyseert PDRT de risico s verbonden met de systemen en interfaces in de ICT architectuur. Risico s worden in verband gebracht met complexiteit en foutgevoeligheid van systemen, de mate waarin er expertise is over de systemen, et cetera. Vervolgens integreert PDRT de business- en ICT-risico s en volgt een afgewogen beeld welke BUC s/oplossingen moeten worden getest en met welke mate van diepgang. Detail risicoanalyse Voor een detailanalyse maakt PDRT een verdieping op de BUC s die getest gaan worden. Er blijven met andere woorden ook requirements en BUC s buiten beeld van de acceptatietest. In de RTM staat welke requirements en BUC s buiten scope liggen, zodat het altijd inzichtelijk is, wat wordt getest en wat niet. De te testen BUC s worden nader geanalyseerd op voor testen- nieuwe relevante business events. Deze events krijgen een waardering op basis van hun belang, impact en frequentie. Daarmee ontstaat een compleet beeld welke business events en bijbehorende BUC s en requirements in de test meegaan. Afbeelding 8. BUC aangevuld met informatie over de oplossing en testinstructies Stap 2. Opstellen testgevallen Voor de nieuwe en bestaande business events worden de BUC s op het niveau van activiteiten ontworpen. Er vindt een koppeling plaats tussen de detail requirements en de activiteiten uit de BUC s. Bovendien verbindt PDRT aan elk requirement een oplossing, bijvoorbeeld een scherm, procedure of rapport. Om te weten welke oplossing bij welk requirement hoort, is input nodig vanuit de functionele ontwerpen en detail impactanalyses van business en ICT. Het uitschrijven van de testgevallen is gebaseerd op de structuur van de BUC s (zie afbeelding 5). Informatie zoals het te tonen scherm, te ondernemen testacties en het verwachte testresultaat plaatst PDRT in de BUC s. Deze informatie wordt aan de rechterkant van de BUC toegevoegd (zie afbeelding 8). Nu ontstaat een totaaloverzicht dat alle partijen begrijpen: aan de linkerkant het proces en de requirements in heldere taal voor de gebruikers en aan de rechterkant de testgevallen voor de tester. Stap 3. Uitvoeren acceptatietesten Zodra de oplossing, of een deel ervan opgeleverd is aan het testteam, start de testuitvoering. De helder beschreven testgevallen maakt de testuitvoering logisch en eenvoudig. Feitelijk voert een tester de BUC s uit, waarbij stap voor stap de processen worden uitgevoerd in samenhang met de ICT oplossing en andere procedurele oplossingen. In het testgeval (afbeelding 8) staan rechts twee kolommen die worden ingevuld door de tester. Hij geeft aan wat het testresultaat is en of de test OK is. Over het uitvoeren van acceptatietesten is nog veel meer te vertellen. Denk aan aspecten met betrekking tot testtechnieken, bevindingenregistratie, testomgevingen, et cetrea. Echter, voor deze whitepaper gaat het te ver om hier stil bij te staan. Stap 4. Afsluiten acceptatietest PDRT sluit de acceptatietest af met het vrijgave advies. Een belangrijk hulpmiddel hierbij is de RTM. Hierin staat welke requirements zijn afgetest en akkoord bevonden en welke requirements nog opstaande bevindingen kennen. De RTM helpt bovendien bij het vinden wie de eigenaar is van een requirement, om mee af te stemmen hoe ernstig een openstaande bevinding is. Immers, via de RTM is traceerbaarheid gewaarborgd van testresultaat, naar testgeval, naar oplossing, naar requirement, naar eigenaar van een requirement. Requirements Traceability Matrix (RTM) Een requirements traceability matrix (RTM) is het overzicht, meestal in de vorm van tabellen, dat de samenhang weergeeft tussen verschillende elementen, zoals stakeholders of gebruikers, requirements, business events, ICT zonder risico Pagina 6 van 10
7 BUC s, ICT-systemen, procedurele oplossingen en testgevallen. Afbeelding 9 toont een gesimplificeerd, logisch model van een RTM. Elk element kent een tabel, bijvoorbeeld een tabel voor requirements, een tabel voor stakeholders. Behalve deze tabellen worden ook de relaties tussen gegevens uit de tabellen vastgelegd. Elke organisatie bepaalt zelf welke elementen ze wil vastleggen en waar ze relaties tussen wil leggen. Een RTM is daardoor altijd op maat. Minder documenten Projecten kennen doorgaans veel documenten met veel proza. De inhoud van die documenten kan overlappend, redundant en tegenstrijdig zijn. Requirements kunnen bijvoorbeeld in meerdere documenten voorkomen met verschillende versies of zijn niet herkenbaar in de documenten, maar staan als tekst verstopt tussen andere tekst. De samenhang tussen de documenten kan vragen opleveren. Bijvoorbeeld processchema s staan over meerdere documenten verspreid zonder onderlinge samenhang. Of in functionele ontwerpen of use cases staan verwijzingen naar processen waarbij de verwijzingen onjuist zijn. Kostbare tijd gaat door deze zaken verloren aan lezen en interpreteren. Afbeelding 9. Model van een RTM In het voorbeeld in afbeelding 9 wordt requirement r2 gekoppeld met stakeholder S2. Requirement r2 wordt ook gekoppeld met proces P4. De combinatie van r2 en P4 wordt in BUC B2 beschreven. Systeem R1 ondersteunt proces P4, en de testgevallen ts2, ts3 en ts4 testen het requirement r2. Op deze manier is precies na te gaan welk testgeval welk requirement afdekt. Het is ook mogelijk om na te gaan welke requirements niet door testgevallen zijn afgedekt. Omgekeerd is het ook mogelijk om te controleren welke requirements door een bepaald testgeval zijn afgedekt. Uitbreidbaarheid en op maat De RTM structuur laat zich eenvoudig uitbreiden met elementen die meer projectgerelateerd zijn, zoals change requests, projecten, sprints of releases. Door koppeling van een requirement aan bijvoorbeeld een release, is het eenvoudig na te gaan wanneer een requirement wordt opgeleverd. De RTM ondervangt dit probleem door als centrale opslag te fungeren. Relevante elementen uit documenten krijgen met de RTM een centraal opslagpunt. Vanuit projectdocumenten zoals een functioneel ontwerp of impactanalyse kan worden gerefereerd naar elementen uit de RTM. Door alleen te refereren blijft de informatie op slechts één plaats opgeslagen. Genereren van documenten De RTM is bovendien een middel om bijvoorbeeld testgevallen uit te genereren. Immers, alle gegevens van een testgeval zoals PDRT die voorschrijft, staan in de RTM. Testen bestaat voor een belangrijk deel uit het opstellen van testgevallen. Deze testgevallen bevatten gegevens die al eerder zijn vastgelegd, zoals een BUC en requirements. Dan is het efficiënt als de gegevens slechts éénmaal hoeven te worden geregistreerd en testgevallen kunnen worden gegenereerd uit een centraal opslagmiddel. Inzet van gebruikers bij PDRT Acceptatietesten leggen een groot tijdsbeslag op gebruikers. Enerzijds begrijpen gebruikers dat ze een belangrijke rol spelen bij de acceptatie van een oplossing. Maar anderzijds hebben ze er relatief weinig tijd voor. Hun dagelijks werk gaat gewoon door, ook al plannen ze projecttijd in. Zodra er iets misgaat ICT zonder risico Pagina 7 van 10
8 in de operatiën, dan gaan die problemen uiteraard voor en krijgt de acceptatietest een lagere prioriteit. PDRT heeft door zijn aanpak een logische en werkbare knip gelegd tussen waar gebruikers een grote toegevoegde waarde hebben en waar ze die minder hebben. Gebruikers zijn met name intensief betrokken bij stap 1 van PDRT. Stap 1 is het opstellen van een risicoanalyse. Dat kan alleen gebeuren door mensen die verstand hebben van de organisatie, processen en ICT architectuur. Daar hebben gebruikers dan ook de hoogste toegevoegde waarde voor de acceptatietest. Bij stap 2 en 4 spelen gebruikers een reviewende rol. Voor het opstellen van de BUC s in stap 2 is een check door gebruikers waardevol, omdat BUC s over hun processen en requirements gaan. Stap 4 betreft het afsluiten van de test en het adviseren over in productiename van de oplossing. Het uitbrengen van het advies kan weliswaar door derden gebeuren, maar niet het goedkeuren van het advies. Daar spelen gebruikers de hoofdrol. Stap 3 tot slot, gaat over de testuitvoering. Deze kan zonder problemen volledig worden uitbesteed aan derden. Hooguit zouden gebruikers betrokken kunnen worden bij het testoverleg waar de testbevindingen worden doorgesproken. Voorbeeld case Aan de hand van een fictief autoleasebedrijf demonstreert onderstaande case de PDRT aanpak om tot testgevallen te komen. Het leasebedrijf wil haar verkoopproces zodanig veranderen dat 90% van haar omzet online verloopt. Een projectteam heeft de taak gekregen om de processen en website hiervoor aan te passen. In de voorbereiding heeft de business analist, samen met de gebruikers, de requirements opgesteld, het procesmodel in kaart gebracht en de business events geïdentificeerd. Een klant kan online een offerte opvragen, die hij eerder heeft aangevraagd bij het autoleasebedrijf. Deze offerte kan hij vervolgens omzetten naar een bestelling. Zie afbeelding 10 voor het bijbehorende procesmodel met een drietal activiteiten. Afbeelding 10. Procesmodel voor het bestellen op basis van een bestaande offerte Voor elke activiteit in het procesmodel bestaan enkele requirements (zie afbeeldingen 11, 12 en 13). Afbeelding 11. Requirements voor activiteit Ophalen bestaande offerte Afbeelding 12. Requirements voor activiteit Bevestigen offerte Afbeelding 13. Requirements voor activiteit Bestellen Na het koppelen van de requirements aan de activiteiten, worden de business events en business use cases bepaald. Een van de business events is dat de klant een bestaande offerte wil opvragen. ICT zonder risico Pagina 8 van 10
9 Bij dit event horen de volgende precondities: 1. Bestaande klant die al is ingelogd. 2. Er is een geldige offerte (de offerte is jonger dan 31 dagen EN op basis van de offerte is nog geen auto besteld). Het business event wordt afgehandeld door een business use case met als titel Bestellen op basis van bestaande geldige offerte. Het verwachte resultaat ná het uitvoeren van de business use case is: 1. De bestelling is geplaatst. 2. De klant ontvangt een elektronische bevestiging van zijn bestelling. 3. De order wordt doorgestuurd naar het bedrijfsproces Beheren wagenpark. 4. De order wordt binnen 24 uur doorgestuurd naar het bedrijfsproces In- /excasseren. Met voorgaande informatie wordt de template van de BUC ingevuld (zie afbeelding 14). Alleen die requirements die relevant zijn voor de BUC zijn opgenomen. De overige requirements zijn weggelaten. Afbeelding 14. BUC Bestellen op basis van bestaande geldige offerte ICT zonder risico Pagina 9 van 10
10 Het autoleasebedrijf gebruikt het systeem CARS. In CARS worden schermen toegevoegd om het online verkoopproces te ondersteunen. In afbeelding 15 staat de schermopbouw die hoort bij de BUC uit het voorbeeld. In CARS komt nieuwe functionaliteit om offertes door klanten te laten beheren en om andere bedrijfsprocessen aan te sturen. Afbeelding 16 geeft dit weer. Links staat het proces met de drie activiteiten. Rechts staan per activiteit de database en systeemfuncties van de ICT-oplossing. Afbeelding 15. Schermopbouw Een klant krijgt binnen CARS een eigen omgeving (MyCars) waarin hij persoonlijke zaken, zoals offertes kan beheren. In het scherm MyOffertes heeft de klant de mogelijkheid om zijn offertes te wijzigen en te verwijderen, maar ook de mogelijkheid om offertes om te zetten in een bestelling. Afbeelding 16. Koppeling procesmodel Bestellen o.b.v. bestaande offerte met ICT-oplossing De informatie uit de schermopbouw, de database en systeemfuncties worden aan de BUC in afbeelding 17 toegevoegd. Ook worden er testinstructies aan de BUC toegevoegd, zodat de tester weet welke stappen hij moet uitvoeren. In het voorbeeld moet de tester in directory c:\cars\acc\outbox controleren dat er XML-berichten zijn aangemaakt die de andere bedrijfsprocessen aansturen. Afbeelding 17. Volledig uitgewerkt testgeval ICT zonder risico Pagina 10 van 10
Whitepaper Process Driven Requirements Engineering
Whitepaper Process Driven Requirements Engineering Introductie Veel projecten worstelen met het vaststellen van de probleemstelling en oplossing die daar het beste bij past. Projecten leveren wel goed
Nadere informatieVan 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 informatieVAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER
VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april
Nadere informatieSoftware 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 informatieProcesvalidatie 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 informatieSjabloon testspecificatie. <<Organisatie>>
Sjabloon testspecificatie SYSQA B.V. Almere : Status : Opgesteld door : Organisatie Pagina 2 van 5 Inhoudsopgave Inleiding...3 1 Analyse functiebeschrijving...4
Nadere informatieTesten. 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 informatieMartin 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 informatieSubwerkgroep 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 informatieTaak 2.1.4 Eerst zien dan geloven... 1. Inhoud
Taak 2.1.4 Eerst zien dan geloven Inhoud Taak 2.1.4 Eerst zien dan geloven... 1 Inhoud... 1 Inleiding... 2 Modules van urenregistratiesysteem (Blokboek)... 3 Module applicatiebeheer... 3 Module projectbeheer...
Nadere informatieWorkshop verkrijgen requirements. Draaiboek requirementsontwikkeling sessie. SYSQA B.V. Almere
Workshop verkrijgen requirements Draaiboek requirementsontwikkeling SYSQA B.V. Almere Organisatie SYSQA B.V. Pagina 2 van 6 Titel Workshop verkrijgen requirements Versie 1.1 Onderwerp Datum 16-03-2011
Nadere informatieBusiness Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans
Business Scenario Voorbeeld Archimate Risico Extensie versie 0.1 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging Review historie Naam Afdeling Functie Datum
Nadere informatieDATAMODELLERING SIPOC
DATAMODELLERING SIPOC Inleiding In dit whitepaper wordt de datamodelleervorm Sipoc beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil je een beeld krijgen van
Nadere informatieHERGEBRUIK VAN REQUIREMENTS
HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...
Nadere informatieTestNet 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 informatieOrganisatie 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 informatieWebtesten 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 informatieAnt: B Dit is het doel van het proces.
In welk proces vormt het voor aanpassingen in de informatievoorziening beschikbaar gestelde budget een mandaat voor besluitvorming? A: Contractmanagement B: Financieel management C: Transitie D: Wijzigingenbeheer
Nadere informatieHet sturend niveau: onderlinge afstemming en jaarplannen Een whitepaper van The Lifecycle Company
Het sturend niveau: onderlinge afstemming en jaarplannen Een whitepaper van The Lifecycle Company Met dit whitepaper lichten we de sturende processen uit het BiSL-model nader toe en laten we zien hoe jaarplannen
Nadere informatieProcesbeschrijving Punch out aansluiting DigiInkoop
Procesbeschrijving Punch out aansluiting DigiInkoop Versie 1.1 Datum 28 mei 2014 Status Definitief Colofon Projectnaam DigiInkoop Versienummer 1.1 Contactpersoon Centraal Functioneel Beheer DigiInkoop
Nadere informatieDetailniveau van Procesbeschrijving Handvatten voor financiële instellingen
Detailniveau van Procesbeschrijving Handvatten voor financiële instellingen Dus u heeft besloten om de processen in kaart te brengen. Maar welk detailniveau kiest u daarbij? Moet nu echt exact vastgelegd
Nadere informatieAgenda. Introductie Aan het werk Conclusie / restrospective
Agenda Introductie 13.45 14.30 Aan het werk 14.30 16.30 Conclusie / restrospective 16.30 17.00 Introductie High performance Testing Voorstellen Waar ben je echt goed in (3 minuten) Teams vormen op basis
Nadere informatieRegressietesten. 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 informatieTESTEN 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 informatieArchitectuurredeneermodel Afgewogen keuzes maken
Architectuurredeneermodel Afgewogen keuzes maken Robert Deckers SASG okt 2012 v3 Architectuur: technologie in perspectief Klantbehoefte Toepassing Systeem T 2 Vele wegen die naar ergens leiden Bewuste
Nadere informatieMinisterie 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 informatieNK Testen Testrapport team 4. Team: #Test. SUT: Fructasys. Datum Team #test Claudia Star Robin Duiker DYongmit Lepcha Daniël Venhuizen
Datum 01-05-2017 Team #test Claudia Star Robin Duiker DYongmit Lepcha Daniël Venhuizen NK Testen Testrapport team 4 Versie 1.0 Team: #Test SUT: Fructasys Inhoud 1 Goedkeuringsverklaring 2 2 Document informatie
Nadere informatieUse case. Profiel beheer
s Dit zijn de Usecases. Hier staat tot in detail uitgeschreven wat het systeem moet doen als de gebruiker ergens op klikt. Later in de test fase zullen deze functies ook getest worden met de bijbehorende
Nadere informatieMet dit whitepaper bieden we u een overzicht we een aantal soorten (product-) toetsing. Dit overzicht is niet volledig!
Toetsingen Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht we een aantal soorten (product-) toetsing. Dit overzicht is niet volledig! 1. Product-, proces- of organisatie-audit
Nadere informatieAcceptatietesten 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 informatieWij 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 informatieTesten+ Testaanpak Sogeti testteam bij de Friesland Bank. Versie: 13 februari 2012 André Louwes / Arjan van der Haar
Testen+ Testaanpak Sogeti testteam bij de Friesland Bank Versie: 13 februari 2012 André Louwes / Arjan van der Haar Testen+ Voorstellen André Louwes Senior Testmanager (Sogeti) Manager testline (Friesland
Nadere informatieTe hoog gemikte silver bullets missen doel Te hoog gemikte silver bullets missen doel
Te hoog gemikte silver bullets missen doel TestNet Voorjaarsevenement 2013 13-05-2013 Tom Heintzberger Praegus Ltd. Te hoog gemikte silver bullets missen doel 1-4-2013 1 Agile & testen? Want Geen geautomatiseerde
Nadere informatieTestrapport Kiezen op Afstand Backup en Recoverytest Stembus
Testrapport Backup en Recoverytest Stembus Dit document heefi 9 pagina 's Testrapport backup en recoverytest stembus vo.2 Document historie Versie Datum Bijzonderheden Autorisatie 0.1 03-10-2006 Opzet
Nadere informatieHandleiding Bancontact
Handleiding Bancontact door Patricia Sturm - van Zijl 8 september 2016 Versie 2.1 Openbaar Inhoud 1. Introductie... 3 2. Bancontact... 4 2.1. Verloop van een Bancontact transactie... 4 2.2. Aanleveren
Nadere informatieDATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING
DATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING Inleiding In dit whitepaper wordt de datamodelleervorm ArchiMate data- & applicatiemodellering beschreven. Deze modelleervorm staat in verhouding
Nadere informatieTesten van Datawarehouses en Informa2e. Kan het 2x zo snel, 2x zo goedkoop en 2x zo volledig?
Testen van Datawarehouses en Informa2e Kan het 2x zo snel, 2x zo goedkoop en 2x zo volledig? Wat verwachten we van DWH testen? 1. 2. 3. 4. 5. Gestructureerd Bekende afwijkingen Herhaalbaar (regressietesten)
Nadere informatieDocumentatie Handleiding Hunter-CRM Desktop v1.0
Documentatie Handleiding v1.0 1 Voorwoord Hunter-Desktop is een product van Hunter-CRM. Onze CRM software is gemaakt met het oog op gemak. Deze documentatie bevat een overzicht van de meest gebruikte functionaliteiten
Nadere informatieHandleiding AfterPay. door Patricia Sturm 5 september Versie 2.5 Openbaar
Handleiding AfterPay door Patricia Sturm 5 september 2016 Versie 2.5 Openbaar Inhoud 1. Introductie... 3 2. AfterPay... 4 2.1. Verloop van een AfterPay transactie... 4 2.2. Aanleveren van een AfterPay
Nadere informatieHANDLEIDING. Emjee ICT diensten Ticketsysteem
HANDLEIDING Emjee ICT diensten Ticketsysteem Inhoud Snel aan de slag... 3 Wachtwoord opvragen... 3 Inloggen... 4 Ticket aanmaken... 4 Schermopbouw... 4 Inleiding... 5 Ticket maken of bellen?... 5 Inloggen...
Nadere informatieUitstroom + Crebonummer Applicatie- en mediaontwikkelaar; Crebonummer 25187 Niveau Niveau 4
VOORBLAD FORMAT BLAUWDRUK VAN DE OPLEIDING Algemene informatie Blauwdruk Ontwerper: Isolde Kolkhuis Tanke Ontwerpdatum: 23 september 2015 Versie: 03 Domein: Informatie- en communicatietechnologie Kwalificatiedossier:
Nadere informatieFunctioneel Applicatie Beheer
Functioneel Applicatie Beheer Functioneel Applicatie Beheer Goed functioneel beheer werkt als smeerolie voor uw organisatie en zorgt voor een optimale aansluiting van de informatievoorziening op de primaire
Nadere informatieTo cloud or not to cloud Afgewogen keuzes maken met DYA Software
To cloud or not to cloud Afgewogen keuzes maken met DYA Software Robert Deckers Engineering World 2011 v1 Architectuur: technologie in perspectief Klantbehoefte Toepassing Systeem T 2 Vele wegen die naar
Nadere informatieProcesvisie 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 informatieNieuwe ontwikkelingen in de LSP-keten
Nieuwe ontwikkelingen in de LSP-keten leveranciers en gebruikersvertegenwoordiging Datum: 6 december 2018 Status: Definitief Versie: 2 Classificatie: Openbaar Eigenaar: VZVZ Dit document bevat de proces-
Nadere informatieAccelerate? Automate!
Accelerate? Automate! TA Flying Squad bij KPN Marco Jansen van Doorn Test Tool Consultant, Business Line Test Automation What s Cooking, Vianen, 24 mei 2016 Vraag & Antwoord Meer rendement uit testautomatisering?
Nadere informatieTesten 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 informatieAgile Testing isn t Risking IT! Bram Bronneberg Test Manager Logica - CGI
Agile Testing isn t Risking IT! Bram Bronneberg Test Manager Logica - CGI B.W.F.P.M. BRONNEBERG TEST MANAGER UIREMENT & QUALITY MANAGEMENT Introductie Q & A Achtergrond Agile Testing isn t Risking IT!
Nadere informatieDATAMODELLERING DATA MAPPING MODEL
DATAMODELLERING DATA MAPPING MODEL Inleiding In dit whitepaper wordt de datamodelleervorm data mapping model beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil
Nadere informatieMethodiek. Versie: 16/05/2012 13:42:35
Methodiek Versie: 16/05/2012 13:42:35 Inhoudsopgave Methodiek... 2 Onze visie op het functioneel ontwerp... 2 Stappen in het ontwerpproces... 3 Methodiek Inleiding In dit deel van de encyclopedie wordt
Nadere informatieBDD/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 informatieHandleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark
Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Inhoudsopgave Inhoudsopgave... 2 1. Beheer helpdesk... 3 1.1. Settings... 3 1.2. Applicaties... 4 1.3. Prioriteiten... 5 1.4. Gebruik mailtemplates...
Nadere informatie2SOURCE4.biz geeft u, als klant van 2SOURCE4, inzicht in de beschikbaarheid van IT producten wereldwijd.
2SOURE4.biz geeft u, als klant van 2SOURE4, inzicht in de beschikbaarheid van IT producten wereldwijd. Eenmaal aangemeld met uw persoonlijke toegangscode kunt u niet alleen beschikbaarheid controleren.
Nadere informatieGasunie inkoopproces 2012
Gasunie inkoopproces 2012 Gasunie inkoopproces 2012 Of het nu gaat om het optimaliseren van het gastransport of om het beheren en aansturen van onze leveranciers, bij Gasunie zijn we continu op zoek naar
Nadere informatieAAN DE SLAG L O G I S T I E K G E D E E LT E i
AAN DE SLAG LOGISTIEK GEDEELT E i Inhoudsopgave Inleiding... 3 Begin... 4 Schermuitleg... 6 Beschrijving inkoopproces... 7 Beschrijving verkoopproces... 9 Voor veel gestelde vragen (FAQ) kunt u terecht
Nadere informatieHet BiSL-model. Een whitepaper van The Lifecycle Company
Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte
Nadere informatieTaakcluster Tactisch support
Als wij de bal hebben kunnen zij niet scoren. (Johan Cruijff) Hoofdstuk 18 Taakcluster Tactisch support V1.17.2 / 1 september 2017 Auteur: Ton van den Hoogen Met dank aan alle bedrijven en personen die
Nadere informatiekwaliteitsmeterplus 4
kwaliteitsmeterplus 4 Testen voor de toekomst Eenvoudig en intuïtief Werkproces georiënteerd Scheiding bevindingen en issues Hertest methode Schermafdruk en -opnames SaaS Open platform kwaliteitsmeterplus
Nadere informatieOnze Project oplossing
1 SalesManager Online Onze Project oplossing Hoe kunnen wij uw keten optimaliseren? SalesManager Online maakt het eenvoudig om uw klanten en relaties structureel en overzichtelijk te beheren en te bedienen.
Nadere informatietesting with a smile
testing with a smile Online software voor volledig en gebruiksvriendelijk testmanagement! TESTEN MOET LEUK ZIJN Functioneel acceptatieen gebruikerstesten. Ongeëvenaard in compleetheid en eenvoud. On-Line,
Nadere informatieICT 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 informatieChecklist testen Lopende zaken MijnOverheid. Versie 1.1
Checklist testen Lopende zaken MijnOverheid Versie 1.1 Datum Status 01 oktober Definitief Definitief Checklist testen Lopende zaken MijnOverheid 01 oktober 2013 Colofon Projectnaam MijnOverheid Versienummer
Nadere informatieFunctieprofiel Functioneel Beheerder Functieprofiel titel Functiecode 00
Functieprofiel Functioneel Beheerder Functieprofiel titel Functiecode 00 Doel Zorgdragen voor adequaat beheer en onderhoud van systemen en applicaties, voor tijdige en effectieve ondersteuning van en kennisontwikkeling
Nadere informatieKoppeling met Elektronische Communicatie Hypotheken
Koppeling met Elektronische Communicatie Hypotheken Haal het maximale uit uw aansluiting met Elektronische Communicatie Hypotheken (ECH): de makkelijkste en snelste digitale weg tussen hypotheekverstrekker
Nadere informatieAuteur Kenmerk Versie 1.0 Datum Bestandnaam Status Definitief. NK Software Testen 2017
Auteur Versie 1.0 Datum 01-05-2017 Bestandnaam Definitief NK Software Testen 2017 Inhoudsopgave 1 Distributie lijst 3 2 Management samenvatting 4 2.1 Opdracht 4 2.2 Scope van de opdracht 4 2.3 tabel 5
Nadere informatieKwaliteitsbewaking 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 informatieTESTAUTOMATISERING 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 informatieAuditen van Agile projecten
Auditen van Agile projecten Platform voor Informatiebeveiliging 10 december 2013 Merijn van der Zalm & Marcel Trijssenaar Agenda Belang van assurance op agile ontwikkelen Agile versus Waterval Perspectief
Nadere informatieSoftware 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 informatieAcceptatiemanagement meer dan gebruikerstesten. bridging it & users
Acceptatiemanagement meer dan gebruikerstesten bridging it & users Consultancy Software Training & onderzoek Consultancy CEPO helpt al meer dan 15 jaar organisaties om integraal de kwaliteit van hun informatiesystemen
Nadere informatieDoe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen.
Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. ERP, CRM, workflowmanagement en documentmanagement systemen, ze hebben één ding gemeen: Veel van de
Nadere informatieSjabloon 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 informatieProject Fasering Documentatie Applicatie Ontwikkelaar
Project Fasering Documentatie Applicatie Ontwikkelaar Auteurs: Erik Seldenthuis Aminah Balfaqih Datum: 31 Januari 2011 Kerntaak 1 Ontwerpen van applicaties De volgordelijke plaats van de documenten binnen
Nadere informatieElektronisch factureren
Elektronisch factureren Inleiding Elektronisch Factureren in RADAR is mogelijk vanaf versie 4.0. Deze module wordt niet standaard meegeleverd met de RADAR Update maar is te bestellen via de afdeling verkoop
Nadere informatieHandleiding CCV Shop - Yuki
Handleiding CCV Shop - Yuki www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van CCV Shop naar Yuki. De koppeling zorgt dat voor bestellingen in CCV Shop automatisch een factuur
Nadere informatieHandleiding OpenCart - factuursturen.nl
Handleiding OpenCart - factuursturen.nl www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van OpenCart naar Factuursturen.nl. De koppeling zorgt dat voor bestellingen in OpenCart
Nadere informatieTest 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 informatieHandleiding OpenCart - Yuki
Handleiding OpenCart - Yuki www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van OpenCart naar Yuki. De koppeling zorgt dat voor bestellingen in OpenCart automatisch een factuur
Nadere informatieRisk And Requirement Based Testing bij Acerta
Risk And Requirement Based Testing bij Acerta Bart.Dooms@acerta.be Testverantwoordelijke Acerta November 2005 RRBT bij Acerta AGENDA Acerta? Risk en Requirements Based Testing (RRBT)? Hoe? Risicoanalyse
Nadere informatieVoorbeeldexamen. 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 informatieTestrapport NK Softwaretesten. Team: Testwerk1
Testrapport NK Softwaretesten Team: Testwerk1 Versie: 1.0 Definitief Auteur: Richard Braun, Peter Huisman, Marc Kuper, John van der Molen Datum: 1 mei 2017 Inhoudsopgave 1. Inleiding en toelichting...
Nadere informatieBijlage Inlezen nieuwe tarieven per verzekeraar
! Bijlage inlezen nieuwe tarieven (vanaf 3.2) Bijlage Inlezen nieuwe tarieven per verzekeraar Scipio 3.303 biedt ondersteuning om gebruikers alle tarieven van de verschillende verzekeraars in één keer
Nadere informatieHandleiding. VSV-testomgeving voor softwareleveranciers; de Proeftuin
Handleiding VSV-testomgeving voor softwareleveranciers; de Proeftuin 1/6 Inhoudsopgave Hoofdstuk 1 Inleiding... 3 1.1 Het gebruikersveld... 3 1.2 Historie... 3 Hoofdstuk 2 Gebruikte criteria voor inrichting
Nadere informatiePROJECT 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 informatieHandleiding IDEAL. door Patricia Sturm 27 september Versie 2.1 Openbaar
Handleiding IDEAL door Patricia Sturm 27 september 2016 Versie 2.1 Openbaar Inhoud 1. Introductie... 3 2. ideal... 4 2.1. Verloop van een ideal transactie... 4 2.2. Aanleveren van een ideal transactie...
Nadere informatieInhoudsopgave 1. Opdrachtformulering Beschouwingsgebied Binnen de opdracht Buiten de opdracht
Test rapport Dit document beschrijft de testopdracht voor het Nederlands Kampioenschap software testen 2017. De website Fructasys (Software Under Test SUT) is een totaal backoffice pakket waarmee je bestellingen
Nadere informatieStappenplan koppelen Kringloopwijzer
Stappenplan koppelen Kringloopwijzer Het is van belang om z.s.m. te koppelen met Kringloopwijzer zodat uw klanten met een druk op de knop de leveringsgegevens kunnen inlezen in Kringloopwijzer. Als u tijdig
Nadere informatieHANDLEIDING TRACK & 1. Track & Trace e-mails bewerken 2. 1.1 Algemeen 3 1.2 E-mails 3 1.3 E-mails bewerken 4 1.4 Triggers 4 1.5 Beschikbare Tags 5
HANDLEIDING TRACK & INHOUDSOPGAVE Trigger Based Track & Trace e-mails 1. Track & Trace e-mails bewerken 2 1.1 Algemeen 3 1.2 E-mails 3 1.3 E-mails bewerken 4 1.4 Triggers 4 1.5 Beschikbare Tags 5 2. Track
Nadere informatieTestgedreven 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 informatieTESTEN % ITIL & ASL & BISL WAT HEEFT EEN TESTER AAN ITIL? EEN PRAKTISCH HULPMIDDEL OF BUREAUCRATISCHE BALLAST?
TESTEN % ITIL & ASL & BISL WAT HEEFT EEN TESTER AAN ITIL? EEN PRAKTISCH HULPMIDDEL OF BUREAUCRATISCHE BALLAST? ITIL INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY OPGEKOMEN IN DE JAREN 1980 ITIL V2 IN 2001
Nadere informatieHandleiding PrestaShop - Reeleezee
Handleiding PrestaShop - Reeleezee www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van PrestaShop naar Reeleezee. De koppeling zorgt dat voor bestellingen in PrestaShop automatisch
Nadere informatiecase: use-case-diagram
Hoofdstuk 9 case: use-case-diagram Dit hoofdstuk beschrijft de totstandkoming van de use-cases voor EasyShop, het maaltijdsysteem van Hans en Jacqueline. Het zijn de functionele systeemeisen die hier worden
Nadere informatieHandleiding Magento - Asperion
Handleiding Magento - Asperion www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van Magento naar Asperion. De koppeling zorgt dat voor facturen in Magento automatisch een factuur
Nadere informatieDe tester als Product Owner Wat denk je zelf?
De tester als Product Owner Wat denk je zelf? Evert van Hamersveld en Olivier Mesker Testers en Product Owners in gesprek Volgens mij is dit een belangrijke feature en moet dit goed getest worden Mooi
Nadere informatieGAMP 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 informatie8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten
Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Hoe test je een pen? 1 Bekijk eerst het filmpje over
Nadere informatieWhat s in it for me? Workshop veldtesten. Testteam Studielink Frans Lodewijkx Jasper Lindhout Ron Derks
What s in it for me? Workshop veldtesten Testteam Studielink Frans Lodewijkx Jasper Lindhout Ron Derks Doel workshop Medewerkers van instellingen voeling laten krijgen met testen van hun SIS in relatie
Nadere informatieArchimate risico extensies modelleren
Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.
Nadere informatieHandleiding MijnWebWinkel - Yuki
Handleiding MijnWebWinkel - Yuki www.webwinkelfacturen.nl Samenvatting Dit is de handleiding voor de koppeling van MijnWebWinkel naar Yuki. De koppeling zorgt dat voor bestellingen in MijnWebWinkel automatisch
Nadere informatieVerbeteren bij de Belastingdienst: Niet in de cloud maar beide benen op de grond
Verbeteren bij de Belastingdienst: Niet in de cloud maar beide benen op de grond Mieke van Tongeren Bart Broekman Belastingdienst - Cluster IV 1 Mieke van Tongeren mj.van.tongeren@belastingdienst.nl 06-18304456
Nadere informatie