Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V.
|
|
- Ruth Kuiper
- 8 jaren geleden
- Aantal bezoeken:
Transcriptie
1 Regressietesten De aanpak en aandachtspunten Algemene informatie voor medewerkers van: SYSQA B.V.
2 Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING ALGEMEEN VERSIEBEHEER WAT IS REGRESSIETESTEN? WAAROM REGRESSIETESTEN? WANNEER REGRESSIETESTEN? KOSTEN VAN REGRESSIETESTEN RANDVOORWAARDEN VOOR REGRESSIETESTEN TESTTOOLS AANPAK VOOR REGRESSIETESTEN INTAKE OPSTELLEN REGRESSIETESTSTRATEGIE VOLDOEN AAN RANDVOORWAARDEN UITVOEREN VAN DE REGRESSIETEST...8
3 Organisatie SYSQA B.V. Pagina 3 van 8 1 Inleiding 1.1 Algemeen Doel van dit document is de aanpak voor het toepassen van regressietesten vastgelegd. Het document kan gebruikt worden als aanvulling op Tmap bij het voorbereiden en uitvoeren van regressietesten, zowel in onderhouds- als in nieuwbouwtrajecten. 1.2 Versiebeheer Versie Status Datum Opmerkingen 0.1 Concept 16 juni 2000 Eerste concept 1.0 Definitief 30 juni 2000 Aanpassingen en definitief maken
4 Organisatie SYSQA B.V. Pagina 4 van 8 2 Wat is regressietesten? Regressie is de zekerheid dat de kwaliteit van het systeem niet terugloopt. Bij een regressietest wordt een eerdere test opnieuw uitgevoerd om de gevolgen van een doorgevoerde wijziging of correctie op de rest van het systeem te controleren. Een regressietest stelt vast of het informatiesysteem nog steeds volgens specificaties functioneert. Op het eerste gezicht verschilt regressietesten daarmee niet zoveel van normaal gestructureerd testen. Nog steeds zijn bijvoorbeeld testplanning, fasering en testtechnieken van toepassing. Vanwege het herhalen van de test is er echter een aantal specifieke aspecten waar rekening mee moet worden gehouden. In hoofdstuk 8 treft u deze aspecten aan. Een regressietest vormt integraal onderdeel van een systeem-, integratie of acceptatietest. Naast het testen van nieuwe of gewijzigde functionaliteit wordt in de regressietest het gehele systeem doorgemeten om vast te stellen of het systeem als geheel nog steeds functioneert conform specificaties. 3 Waarom regressietesten? Uit onderzoek is gebleken dat, vergeleken met een nieuw systeem, systemen waarop onderhoud wordt gepleegd 10 maal vaker fouten bevatten (Interface Design Group, 1997). Dit komt omdat het aanpassen van systemen vele malen moeilijker is gebleken dan een nieuw systeem te ontwikkelen. Oorzaak van deze hoge foutscore ligt vermoedelijk in het gegeven dat diegenen die wijzigingen aanbrengen, vaak anderen zijn dan de originele bouwers. Een andere mogelijke oorzaak is het gegeven dat er niet voldoende gedocumenteerd is of dat de documentatie niet meer up-to-date is. Nu hoeft het niet zo te zijn dat die veelvoud van fouten zit in de systeemdelen waar de wijzigingen worden doorgevoerd. Vaak zitten de fouten juist in andere delen van het systeem. Wijzigingen en/of uitbreidingen op een bepaald systeemonderdeel veroorzaken regelmatig fouten in andere systeemonderdelen. Dit geeft aan waarom er te allen tijde een regressietest moet worden uitgevoerd. Als er geen regressietest zou plaatsvinden, dan zouden die nieuwe fouten niet ontdekt worden. Immers, alleen de wijzigingen en/of uitbreidingen worden getest. Door middel van deze regressietest wordt zeker gesteld dat de kwaliteit van het systeem als geheel niet terugloopt. 4 Wanneer regressietesten? Er zijn enkele mogelijkheden om tot regressietesten over te gaan: Systeemaanpassingen in een ander deel van het informatiesysteem. Wijziging in de omgeving (ander platform, hardware componenten worden vervangen, ander ontwikkelplatform). Iedere keer dat er een wijziging en/of uitbreiding op een bestaand systeem plaatsvindt (softwareen/of hardwarematig). Dat kan zowel plaatsvinden als het systeem in productie is als in de préproductiefase. Als het systeem in productie is worden systemen regelmatig aangepast omdat de business dat verlangt, de wetgeving verandert, door technisch vooruitgang of om andere redenen. Elke keer als na een aanpassing het veranderde systeem in productie moet worden genomen, mag de kwaliteit van het systeem als geheel niet zijn teruggelopen. Dat kan alleen gegarandeerd worden door er een regressietest op uit te voeren. In de pré-productiefase worden er ook regelmatig aanpassingen gedaan nadat het leeuwendeel van het nieuwe systeem reeds is voltooid. Dat gebeurt dan omdat het nieuwe systeem nog niet helemaal voldoet aan wat de business verlangt of omdat het nog niet goed aansluit op het administratieve proces of om andere redenen. Ook nu dient er na elke aanpassing een regressietest plaats te vinden, voordat het definitief in produktie gaat.
5 Organisatie SYSQA B.V. Pagina 5 van 8 Voor zowel de pré-productie- als de productiefase geldt dat er aanpassingen plaats kunnen vinden, omdat er zich fouten bevinden in het systeem. Als dat het geval is, dan dienen de systeemonderdelen waarin de fouten zijn hersteld te worden hertest conform de richtlijnen die daarvoor gelden. Maar ook hierbij dient er nog een regressietest plaats te vinden. Welke systeemdelen in aanmerking komen voor een regressietest wordt per situatie bekeken (zie ook hoofdstuk 7). 5 Kosten van regressietesten Uit het bovenstaande lijkt het elke keer moeten uitvoeren van een regressietest veel extra werk. Toch is dat niet het geval. Het testproces bestaat uit 5 fases: planning en beheer, voorbereiding, specificatie, uitvoering en consolidatie van testware. Ongeveer 60% van de totale testinspanning bij testen wordt besteed in de voorbereidings- en specificatiefase. Wanneer er voor het te testen systeem reeds herbruikbare testware aanwezig is, dan is er voor elke regressietest een minimale inspanning nodig om de voorbereidings- en specificatiefase te voltooien. Er is namelijk al voorbereid en gespecificeerd tijdens de test. Dit betekent dat elke regressietest niet 100% extra testinspanning vergt (zoals deze is gebruikt in de acceptatietest), maar ongeveer 40%. Er kunnen afwijkingen op dit percentage voorkomen als er alleen correctieve aanpassingen hebben plaatsgevonden (het percentage zal dan wellicht iets kleiner worden), of als er sprake is van het toevoegen van nieuwe functionaliteit (het percentage zal dan iets groter zijn, omdat de aanpassingen ook invloed kunnen hebben op de bestaande testware), etc. Het impliceert wel dat in voorgaande testtrajecten aan consolidatie van testware is gedaan. Anders zouden de testscripts voor een regressietest opnieuw moeten opgebouwd, hetgeen leidt tot een hogere opslag dan 40%. Gezien de relatief lage kosten en het realiseren van een hogere betrouwbaarheid van het systeem loont het in de praktijk zeer de moeite om na elke aanpassing een regressietest uit te voeren. 6 Randvoorwaarden voor regressietesten Om een regressietest succesvol en met zo weinig mogelijk inspanning te kunnen uitvoeren, dient aan een aantal voorwaarden te worden voldaan. Dit zijn de randvoorwaarden die in elk testtraject aan de orde zijn (zie Tmap Checklist Randvoorwaarden en uitgangspunten). Daarnaast moet specifieke aandacht geschonken worden aan onderstaande 4 randvoorwaarden. 1. Alle documentatie (zowel testdocumentatie als systeemdocumentatie) moet actueel, volledig en onderling consistent zijn. 2. Er moeten heldere en correcte verwijzingen van de testware naar de systeemdocumentatie (en naar het systeem zelf) zijn. 3. Het te testen systeem moet functioneren conform specificaties en er moet bekend zijn welke veranderingen er hebben plaatsgevonden in het systeem. Tevens moet bekend zijn hoe en waar in andere delen van het systeem deze veranderingen invloed hebben. Er moet inzicht zijn in programmastructuren zowel in technisch als functioneel opzicht. 4. Voor kwalitatief goede testware is correct versiebeheer noodzakelijk. Bij elke (regressie)test dient vastgesteld te worden dat de juiste versies van de bestanden, sources, documentatie, systeemsoftware, hardware componenten e.d. gebruikt worden. 7 Testtools Voor het uitvoeren van regressietesten kan het interessant zijn record & playback testtools in te zetten. Tools bereiken in de regel een hoge mate van betrouwbaarheid van de test.
6 Organisatie SYSQA B.V. Pagina 6 van 8 Echter, de aanschaf van een testtool en de implementatie ervan nemen relatief hoge kosten met zich mee. De terugverdientijd is uit te drukken in aantallen regressietesten. De ervaring is dat de baten tegen de kosten opwegen indien een regressietest ongeveer 3 tot 5 keer herhaald kan worden (uiteraard ook afhankelijk van de grootte van het systeem, de kenmerken van het informatiesysteem, de data-bestanden, benodigde invoer e.d.). Het informatiesysteem moet stabiel zijn om het meeste effect en efficiency uit de inzet van het record & playback testtool halen. Aanpassingen in het systeem die betrekking hebben op databases en functies grijpen relatief sterk in in de testscripts die worden gebruikt bij het toepassen van testtools. Maar vooral ook in de programma-scripts die met de tool zijn gemaakt. 8 Aanpak voor regressietesten Om tot een regressietest te komen, kunnen we op hoofdlijn vier fases onderscheiden. 1. Intake op huidige situatie met betrekking tot de randvoorwaarden uit hoofdstuk 6. Er wordt bepaald in welke mate voldaan wordt aan de randvoorwaarden. De bevindingen worden gerapporteerd en vormen mede de basis voor het bepalen van de te nemen regressieteststrategie. 2. Opstellen regressieteststrategie. 3. Voldoen aan de randvoorwaarden opdat de teststrategie voor een regressietest uitgevoerd kan worden. 4. Uitvoeren van de regressietest. 8.1 Intake Specifiek voor de regressietest wordt een intake uitgevoerd op onderstaande punten. De status van de test- en systeemdocumentatie. Wat is er aan documentatie, hoe actueel, volledig en onderling consistent is het? In hoeverre staan er verwijzingen in de testware naar de bijbehorende systeemdocumentatie? Gecontroleerd wordt op juistheid en volledigheid van de verwijzingen, en wat de mate van detail is van de verwijzingen. In hoeverre staan er verwijzingen in de testware naar de bijbehorende systeemdelen? In hoeverre sluit de testware aan op de werking van het systeem; hoe juist, volledig en gedetailleerd zijn de verwijzingen naar het systeem? In welke mate functioneert het systeem conform systeemdocumentatie? Welke veranderingen (functioneel en/of correctief) zijn aangebracht in het systeem? In welke delen van het systeem hebben deze veranderingen invloed? In hoeverre en in welke mate zijn de veranderingen in het systeem gedocumenteerd in de systeemdocumentatie? In hoeverre is bekend met welke versies bestanden, sources, documentatie, systeemsoftware, hardware componenten e.d. getest wordt / moet worden? Er ontstaat met de intake inzicht in de mate van samenhang en onderlinge aansluiting van testware, systeemdocumentatie en programmatuur. De bevindingen vormen onderdeel voor het opstellen van een teststrategie. 8.2 Opstellen regressieteststrategie De basis voor het opstellen van een regressieteststrategie wordt gevormd door: Beschikbare budget voor regressietesten. Beschikbare testtijd voor regressietesten.
7 Organisatie SYSQA B.V. Pagina 7 van 8 Gewenste betrouwbaarheid en andere acceptatiecriteria gesteld aan het systeem of bepaalde systeemdelen (zoals bedrijfskritische processen ondersteunen, die bepaalde kritische bedrijfseigenschappen moeten realiseren, die in het verleden relatief veel problemen in produktie opleverden en/of die cruciale interfaces met omliggende systemen hebben). Bevindingen uit de intake op de randvoorwaarden. Gevolgen uit de intake v.w.b. het kunnen realiseren van de gewenste betrouwbaarheid van het systeem of systeemdelen, alsmede de benodigde tijd en capaciteit om een inhaalslag te doen op de testware en systeemdocumentatie. Per testtraject moet met de betrokkenen (projectleider, testmanager, accountantsdienst/controller, opdrachtgever, lijnmanagement etc.) een afweging gemaakt worden om tot een gewenste strategie te komen. De strategie geeft aan: Wat de acceptatiecriteria zijn voor de regressietest. Hij geeft o.a. inzicht in de gewenste betrouwbaarheid van het systeem/de systeemdelen. De criteria zijn dermate concreet en meetbaar dat ze eensluidend getest kunnen worden. De diepgang en dekkingsgraad van de regressietest. Welke systeemdelen en/of welke functies binnen welke systeemdelen en/of interfaces worden met welke diepgang getest? Welke uitspraken wil men doen op basis van de gekozen diepgang en dekkingsgraad? Welke testtechnieken worden toegepast en welke acceptatiecriteria toetsen ze? De verdeling van testtijd/inspanningen over de systeemdelen, functies, interfaces en acceptatiecriteria. De acties die uitgezet worden om aan de randvoorwaarden voor de gewenste regressietest te voldoen (inhaalslag op de testware en systeemdocumentatie). En vooral de onderbouwing van de regressieteststrategie. Leg de besluitvorming hierover vast, zodat een verantwoording van keuzes later snel en eenvoudig kan worden gemaakt. Voor het kiezen van te testen systeemdelen, functies en interfaces zijn er 4 alternatieven. 1. Men kan een keuze maken om maar één deel van het systeem met een regressietest te raken (krimpen in de breedte). 2. Men kan er ook voor kiezen om elk deel van het systeem te testen, maar niet met dezelfde diepgang als bij de systeem-, integratie- of acceptatietest (krimpen in de diepgang). 3. Men kan de hoeveelheid werk beperken door het zogenaamde steen-in-vijver principe. Stel, de plaats waar de steen het water raakt is de plaats waar de wijziging in het systeem heeft plaatsgevonden. Dan wil het principe zeggen dat hoe verder een bepaalde functie afstaat van de wijziging (qua afhankelijkheid of qua belangrijkheid), hoe minder uitgebreid zo n functie getest hoeft te worden en andersom. Hoe dichterbij een bepaalde functie staat van de wijziging (qua afhankelijkheid of qua belangrijkheid), hoe uitgebreider zo n functie wordt getest. 4. Een vierde optie is om alleen de bedrijfskritische functies te regressietesten. Hierbij wordt geen rekening gehouden met de invloed van wijzigingen op andere delen van het systeem, maar neemt men genoegen met de wetenschap dat alleen de belangrijkste functies foutloos werken. Van de overige functies heeft men dus geen kwaliteitsoordeel en worden er voor die delen risico s genomen. Sterker nog, wanneer sommige bedrijfskritische functies afhankelijk zijn van andere functies, dan loopt hiermee ook het bedrijfskritische proces gevaar. Kortom, de laatste optie is mogelijk, maar dan moet men zeker weten dat er niet te veel risico s voor het bedrijfskritische proces worden gelopen.
8 Organisatie SYSQA B.V. Pagina 8 van Voldoen aan randvoorwaarden Indien uit de intake op de randvoorwaarden en de gekozen regressieteststrategie naar voren is gekomen dat invulling aan de randvoorwaarden in bepaalde mate noodzakelijk is, volgt fase 3, het voldoen aan de gewenste randvoorwaarden. Afhankelijk van de strategie spelen onderstaande stappen een rol. 1. Synchronisatie van het systeem en de systeemdocumentatie. De werking van het systeem is hierbij leidend. Dit is geen activiteit van een testteam, maar hoort thuis bij de eenheid die verantwoordelijk is voor de systeemdocumentatie. 2. Opstellen en/of aanvullen van de testware voor het bestaande systeem. Het realiseren van consistentie, correctheid en volledigheid van testware t.o.v. het systeem. Deze stap kan parallel aan stap 1 worden uitgevoerd. Deze stap is wel de verantwoordelijkheid van het testteam. De testware wordt zodanig aangepast dat voldaan wordt aan de keuzes die ten grondslag liggen aan de strategie. De testware moet dienen tot het toetsen van vooraf benoemde acceptatiecriteria en vooraf benoemde systeemdelen, functies en interfaces. 3. Bij het opstellen en verbeteren van de testware wordt aangegeven hoe de testgevallen afgeleid zijn van de logisch testsituaties en die op hun beurt van het systeem. Zo weet je welke systeemfuncties je test met welke logische en fysieke testgevallen. En ben je snel in staat later testware aan te passen als bepaalde systeemfuncties worden gewijzigd of toegevoegd. 4. Zekerstellen dat het systeem, de systeemdocumentatie en de testware onderling consistent zijn. Zekerstellen dat er heldere en correcte verwijzingen van de testware naar de systeemdocumentatie zijn. 5. Aanpassen van de systeemdocumentatie naar aanleiding van de systeemwijzigingen. Dit is geen activiteit van het testteam, maar van de eenheid die verantwoordelijk is voor de systeemdocumentatie. 6. Aanpassen testware op grond van de gewijzigde systeemdocumentatie. Hiervoor geldt de aanpak voor testvoorbereiding en -specificatie die in Tmap wordt beschreven. 8.4 Uitvoeren van de regressietest Voor het uitvoeren van de regressietest gelden dezelfde stappen en aandachtspunten die voor testuitvoering van toepassing zijn, welke uitvoerig in Tmap worden beschreven. Let wel: wanneer er bevindingen zijn als gevolg van de regressietest, zorg eerst dat de gecorrigeerde functionaliteit eerst sec wordt gehertest, totdat hij correct functioneert, voordat weer de regressietest start.
EISEN AAN TESTPLANNEN
EISEN AAN TESTPLANNEN Auteur : Datum : Versie :.. Status :.. Datum overdracht : Overgedragen aan : Inhoudsopgave 1 Inleiding...
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 informatieOntwikkelen 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 informatieRAD 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 informatieWoordenlijst 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 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 informatieSjabloon detailtestplan. <<Organisatie>>
Sjabloon detailtestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 18 Inhoudsopgave 1 Managementsamenvatting...
Nadere informatieChecklist basisontwerp SDM II
Organisatie SYSQA B.V. Pagina 1 van 5 Checklist basisontwerp SDM II Documentatie. Zijn de uitgangspunten voor het basisontwerp Is een plan van aanpak Zijn er wijzigingen op het Software Quality Assurance
Nadere informatieVerschillen in QA aanpak tussen ERP projecten en niet-erp projecten
Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten SYSQA B.V. Almere Datum : 06 mei 2013 Status : definitief Versie : 2.0 Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 5 Overzicht
Nadere informatieMastertestplan <<Naam project>> <<Organisatie>>
Mastertestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie Pagina 2 van 17 Inhoudsopgave 1 Management
Nadere informatieAandachtspunten inzet testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V.
Aandachtspunten inzet testtool Een aanpak Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA BV Pagina 2 van 12 INHOUDSOPGAVE 1. INLEIDING...3 1.1 DOEL EN AFBAKENING...3 1.2 CAPTURE
Nadere informatieTestplan IpMEDT3 project
Testplan IpMEDT3 project Versie: 1.0 Groepsbegeleider: Bob Zadok Blok Groepsleden: Luuk Gortzak (s1062708) Jens Brokaar (s1066589) Ellis Stroet (s1066586)
Nadere informatieTesting 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 informatieISTQB 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 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 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 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 informatieSjabloon testplan op basis van SYSQA -teststrategieaanpak. <<Organisatie>>
Sjabloon testplan op basis van SYSQA -teststrategieaanpak SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie Sjabloon detailtestplan op basis
Nadere informatieTestaanpak: 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 informatieVrijgaveadvies. Project <naam project>
Vrijgaveadvies Project SYSQA B.V. Almere Datum : 08-02-2013 Status : Versie : Opgesteld door : Organisatie Project Pagina 2 van 16 Inhoudsopgave 1 Management samenvatting...
Nadere informatie14/11/2010. Een duurzame testaanpak voor een veranderd informatiesysteem. Agenda. Wie is Albert?
Een duurzame testaanpak voor een veranderd informatiesysteem Albert Mohan & Han Toan Lim Agenda Introductie Koffiepauze Afronding testproject Afsluiting No. 2 Wie is Albert? Albert Mohan Testmanager, Testadviseur
Nadere informatieData Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.
Data Warehouse Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DOEL VAN
Nadere informatieDe SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.
De SYSQA dienst auditing Een introductie 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 informatiePROQA Project Quality Assurance. Checklist. Behorend bij het PROQA-assessment SYSQA B.V.
PROQA Project Quality Assurance Checklist Behorend bij het PROQA-assessment SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING CHECKLIST WERKEN VOLGENS PROQA... 3 1.1 DE 5 FASEN
Nadere informatieDe 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 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 informatieSDM II - System Development Methodology II. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.
SDM II - System Development Methodology II Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 12 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2
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 informatieEibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008
Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test
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 informatieTestFrame. 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 informatieRAD en testen. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V.
RAD en testen Een aanpak Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA Pagina 1 van 23 Managementsamenvatting Rapid Application Development (RAD) is een systeem-ontwikkelingsmethode
Nadere informatieWhitepaper 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 informatieTesten en QA bij pakketimplementaties
Testen en QA bij pakketimplementaties Eric Begeer Sogeti Nederland B.V. Testnet 5 november 2003 Agenda Waarom maken organisaties gebruik van pakketten? Welke risico s lopen ze hierbij? Welke maatregelen
Nadere informatieTMap in een notedop. Martin Pol en Erik van Veenendaal
TMap in een notedop Martin Pol en Erik van Veenendaal De vier pijlers onder een gestructureerde testaanpak zijn een aan de ontwikkelingscyclus gerelateerde fasering van de testactiviteiten, een goede organisatorische
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 informatieKwaliteit van testen. Onbeheersbaar of ongecontroleerd? thema
thema Kwaliteit van testen Onbeheersbaar of ongecontroleerd? Testtrajecten hebben de naam moeilijk planbaar en beheersbaar te zijn. Vraag aan tien willekeurige testmanagers naar de oorzaken die hieraan
Nadere informatieData en Applicatie Migratie naar de Cloud
Data en Applicatie Migratie naar de Cloud Iris Pinkster Professional Testing 1 Agenda - Introductie - De Cloud een introductie - Keuze van geschikte applicaties - Migratie strategieën - Test strategieën
Nadere informatieSmartTestAssistant. Het slimme testhulpmiddel. door Frank Stolker
SmartTestAssistant Het slimme testhulpmiddel door Frank Stolker Inhoud Waarom wéér een ander tool? Omdat dit is wat we willen Wat is SmartTestAssistant dan? Hoe zit het in elkaar? Hoe werkt het? Schematische
Nadere informatieExamen TMPA Test Management Approach (TMap) Professional Advanced
Examen TMPA Test Management Approach (TMap) Professional Advanced Publicatiedatum Startdatum 6 juni 2003 1 mei 2003 Doelgroep De module is bestemd voor (beginnende) professionele testers met een ½ tot
Nadere informatieOntwikkelaar ICT. Context. Doel
Ontwikkelaar ICT Doel Ontwikkelen en ontwerpen van ICT-producten, binnen overeen te komen dan wel in een projectplan vastgelegde afspraken ten aanzien van tijd, budget en kwaliteit, opdat overeenkomstig
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 informatieSoftware 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 informatieVan Risicoanalyse tot Teststrategie
Van Risicoanalyse tot Teststrategie Cees Dulfer, Sr. Testconsultant Rabobank Nederland TestNet, 2 november 2005 1/28 TestNet, 2 november 2005 2/28 Agenda Historie Testproces en positionering Product Risico
Nadere informatieSoftware 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 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 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 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 informatieTest Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden
Test Process Improvement Benchmark SPIder Conferentie 23 september Wim van Uden Agenda Korte inleiding TPI -model TPI benchmark overall Vergelijking branches DO s& DON Ts Test Process Improvement Optimaliseren
Nadere informatieTesten kost te veel tijd
Testen kost te veel tijd De oplevering van een nieuwe ICT applicatie betekent in de praktijk voor de opdrachtgever nog geen reden voor een feest. Vaak blijkt het product in onvoldoende mate te voldoen
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 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 informatieTestplan <NAAM INFORMATIESYSTEEM/PROJECT>
Testplan é 2000 Pag. 1 Inhoud 1. DOCUMENTGEGEVENS... 4 1.1 WIJZIGINGSHISTORIE... 4 1.2 DISTRIBUTIE... 4 1.3 OPENSTAANDE PUNTEN... 4 1.4 ACCORDERING... 4 1.5 WIJZIGINGSPROCEDURE...
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 informatieWhitepaper. 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 informatieSmartTestAssistant. Het slimme testhulpmiddel. door Frank Stolker
SmartTestAssistant Het slimme testhulpmiddel door Frank Stolker Inhoud Waarom wéér een ander tool? Omdat dit is wat we willen Wat is SmartTestAssistant dan? Hoe zit het in elkaar? Hoe werkt het? Schematische
Nadere informatie<<Naam document>> <<Organisatie>>
SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Managementsamenvatting...3 2 Opdracht...4
Nadere informatieUittreksel. Ten geleide
Ten geleide TMap, Test Management Approach, is een aanpak voor het gestructureerd testen van informatiesystemen. Het geeft antwoord op de wat/wanneer, hoe, waarmee en wie vragen van het testen. Om de inrichting
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 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 informatieLinkedin discussie: Hoe kan je best geld besparen op testen?
Linkedin discussie: Hoe kan je best geld besparen op testen? Snelle besparingen In deze tijden moet iedereen besparen. Dit wordt natuurlijk ook verwacht van een testteam: Waar kan je binnen testen besparen?
Nadere informatie1,3 miljoen regels mission critical code omzetten naar C++, hoe test je dat?
1,3 miljoen regels mission critical code omzetten naar C++, hoe test je dat? XXXXXX Najaarsevenement 2016 Jaap Kuilman 11 oktober 2016 Introductie Jaap Kuilman Testconsultant bij InTraffic Ervaring in
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 informatieISACA 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 informatiea. 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 informatieProductrisicoanalyse in de praktijk
Productrisicoanalyse in de praktijk Kees Blokland Polteq IT Services BV Agenda Intro Voorbereiding Aandachtspunten voorbereiding Bijeenkomst risicoanalyse Aandachtspunten bijeenkomst risicoanalyse Bepaling
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 informatievoorbeeldexamen 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 informatieBijlage 3: Master testplan
Bijlage 3: Master testplan KIS Testplan Inaxion Lelystad Adres: Jol -20 Postbus : 609 Postcode Plaats 8483 ED Lelystad I www.inaxion.nl Plaats Lelystad Datum 22 maart 200 Auteur Saidou Diallo Status Finaal.0
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 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 informatieDoel. Context VSNU UFO/INDELINGSINSTRUMENT FUNCTIEFAMILIE ICT FUNCTIONEEL (INFORMATIE) BEHEERDER VERSIE 1 MEI 2012
Functioneel (informatie) beheerder Doel Zorgdragen voor het inrichten, aanpassen, vernieuwen en onderhouden van de informatievoorziening (processen, procedures en/of systemen), passend binnen het informatiebeleid
Nadere informatieERP 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 informatieFunctiepuntanalyse. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.
Functiepuntanalyse Een introductie 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 2 WAT
Nadere informatiebedrijfsprocessen 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 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 informatieAnko Tijman Een agile teststrategie op basis van MoSCoW
Titel, samenvatting en biografie Anko Tijman Een agile teststrategie op basis van MoSCoW Samenvatting: Deze presentatie behandelt de toepassing van de teststrategie vanuit een agile perspectief: welke
Nadere informatiePraktijkgerichte aanpak voor End to End (E2E) testen
Praktijkgerichte aanpak voor End to End (E2E) testen Gerard Numan gerard.numan@polteq.com Polteq 2014 E2E wil zeggen: End to End, van het ene uiterste einde naar het andere einde. E2E-processen lopen over
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 informatieTMap 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 informatieChecklist risicofactoren IT-projecten
Organisatie SYSQA B.V. Pagina 1 van 5 Checklist risicofactoren IT-projecten In onderstaande checklists zijn de factoren die het slagen van een project beïnvloeden opgenomen. Projectomvang Hoe groot is
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 informatieNajaarsspecial Oktober 2013
Najaarsspecial Oktober 2013 Pagina 12 TESTEN IS GEEN KUNSTJE ; ADAPTIVITEIT MAAKT VAN TESTEN IN JOUW CONTEXT EEN KUNDE! Door Leo van der Aalst en Rik Marselis leo.vander.aalst@sogeti.nl rik.marselis@sogeti.nl
Nadere informatieTMap 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 informatieTaakgebied Bepalen huidige bedrijfsprocessen
Weten wat je doet, maar ook hoe je het doet, is de basis voor elke toekomst. Hoofdstuk 22 Taakgebied Bepalen huidige bedrijfsprocessen V1.1 / 01 september 2015 MCTL v1.1 Hoofdstuk 22... 3 Plaats in het
Nadere informatieDe vereenvoudigde beslistabel
De vereenvoudigde beslistabel Auteur: Patrick Zweegman Datum: 08-12-2004 Versie: 1.0 De aanleiding Diverse testafdelingen gebruiken de beslistabellen techniek (zie TMap, paragraaf 15.5 Beslissingstabellentest,
Nadere informatieTMAP NEXT. TMap in essenties
TMAP NEXT TMap in essenties auteurs: Aalst, L. van der, Broekman, B., Koomen, T., Vroon, M. gebaseerd op de originele publicatie in : TMap NEXT, voor resultaatgericht testen, Aalst, L. van der, Broekman,
Nadere informatie1 Data migratie project 1
1 Data migratie project 1 1.1 Inleiding 1.1.1 Achtergrond Het netwerkgebied van Netbeheerder Y is per 1 januari eigendom van Netbeheerder X. Het gaat om circa 100.000 elektriciteits- en 400.000 gasaansluitingen
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 informatieGestructureerde Testaanpak
Gestructureerde Testaanpak Gestructureerde Testaanpak; Agenda Introductie Waarom, hoe? Van dagelijkse praktijk naar structuur. Voordelen, Extra s Vragen Gestructureerde Testaanpak; Introductie. Bas Koreman
Nadere informatieNGI-Noord. Mei 2007. Tim Koomen Leo van der Aalst Michiel Vroon
NGI-Noord Mei 2007 Tim Koomen Leo van der Aalst Michiel Vroon TMap of TMap Next? TMap = methode TMap Next = boektitel TMap Next = externe communicatie. Waarom? Actualisering van de methode Testen integraal
Nadere informatieReleases en change-management bij maatwerkapplicaties
Releases en change-management bij maatwerkapplicaties door Wim - 01-26-2011 http://www.itpedia.nl/2011/01/26/releases-en-change-management-bij-maatwerk-applicaties/ Op grote maatwerk informatiesystemen
Nadere informatiePrivacy Dashboard 6 KPI s en Aandachtspunten
Bijlage 4. Implementatie AVG Privacy dashboard AVG@VenJ Privacy Dashboard 6 KPI s en Aandachtspunten Rapportage KPI-3-2017 Opsteller: DJI AVG@VenJ Privacy Dashboard: KPI s en Aandachtspunten (Juli 2017
Nadere informatieC.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 informatieBusiness case Digikoppeling
Business case Digikoppeling Versie 1.0 Datum 02/06/2014 Status Definitief Van toepassing op Digikoppeling versies: 1.0, 1.1, 2.0, 3.0 Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900
Nadere informatieWie doet wat? 30-5-2013. Gebruik en beheer van applicaties. Een kader VHIC VHIC. Pagina 1. Pagina 2
Gebruik en beheer van applicaties Wie doet wat? Pagina 1 Een kader Pagina 2 Bron: daanrijsenbrij, Elementaire bedrijfsinformatica 1 Functioneel beheer Applicaties worden gebruikt door de gebruikersorganisatie.
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 informatieEen duivelse samenwerking (Projectmanagement vs. Testmanagement) Albrie Beemer & Erik Bits 18 april 2012
Een duivelse samenwerking (Projectmanagement vs. Testmanagement) Albrie Beemer & Erik Bits 18 april 2012 Het duivelsvierkant Agenda Introductie 19.00u 19.10u Klassiek Projectmanagement: Prince 2 Testmanagement:
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 informatieTestrapport Kiezen op Afstand Inhoudelijke Stresstest
Testrapport Inhoudelijke Stresstest Dit document heeft 10 pagina 's Testrapport 1nhoudelijke Stresstest vo.21 Document historie Versie Datum Bijzonderheden Autorisatie 0.1 20-09-2006 Opzet 0.2 22-09-2006
Nadere informatie