Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Maat: px
Weergave met pagina beginnen:

Download "Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V."

Transcriptie

1 Requirements en testen Een introductie Algemene informatie voor medewerkers van: SYSQA B.V.

2 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING ALGEMEEN VERSIEBEHEER REQUIREMENTS EN TESTEN INLEIDING EEN PRAKTIJKVOORBEELD REQUIREMENTSPROCESSEN IN RELATIE TOT TESTEN HET TESTPROCES DE RELATIE TUSSEN HET REQUIREMENTS- EN TESTPROCES IN HET SYSTEEMONTWIKKELTRAJECT TIPS VOOR GEBRUIK IN DE PRAKTIJK: HET BELANG VAN REQUIREMENTS VOOR HET TESTPROCES LITERATUUROPGAVEN... 10

3 Organisatie SYSQA B.V. Pagina 3 van 10 1 Inleiding 1.1 Algemeen In dit document is beschreven welke rol requirements en requirementsprocessen spelen in relatie tot testen. Tevens bevat dit document verwijzing naar hulpmiddelen en sjablonen en een verwijzing naar literatuur voor verdere verdieping in dit onderwerp. De informatie vanuit Requirements, een introductie, een ander document vanuit de kennisbank van SYSQA wordt als bekend verondersteld. Het document staat ter beschikking van elke Sysqa-professional die rechtstreeks met deze materie van doen krijgt, of zich hierin wil verdiepen. In het gehele document wordt de term requirements in plaats van eisen gebruikt, omdat: voor requirements engineering als overkoepelende term geen Nederlands equivalent beschikbaar is (mocht een Nederlandse term nodig zijn, dan kan eisenbeheer & -ontwikkeling worden gebruikt); veel bedrijven deze term hanteren; het aantal hits op internet (alleen Nederlandse sites) overwegend het gebruik van de term requirements voor eisen in ICT-trajecten weergeeft 1.2 Versiebeheer Versie Status Datum Auteur Opmerkingen 0.9 Concept Sysqa Op basis van requirementsdocument van de expertisegroep requirements, omgezet naar SYSQA-sjabloon en tekstuele aanpassingen. 1.0 Definitief Sysqa Opmerkingen verwerkt, definitief gemaakt. 1.1 Definitief Sysqa Aanpassen opmaak.

4 Organisatie SYSQA B.V. Pagina 4 van 10 2 Requirements en testen 2.1 Inleiding Requirements en testen zijn onderwerpen die onlosmakelijk met elkaar verbonden zijn. In de praktijk komen vaak tijdens de testfase, of erger nog, in productie, bevindingen naar voren die voorkomen kunnen worden door een betere afstemming tussen de requirements-; ontwikkel- en testprocessen. Onderzoek toont aan dat van de oorspronkelijk gedefinieerde requirements slechts 42% tot 67% daadwerkelijk door het project wordt gerealiseerd (the Standish Group, 2003) Uit: Tmap Next (6). De requirementsbaseline is de formele vastlegging van de overeengekomen klanteneisen voor het op te leveren informatiesysteem en de wijzigingsprocedure op de requirements. Deze formele vastlegging is de basis voor het verder analyseren, definiëren, ontwerpen, bouwen, testen, accepteren en beheren van het systeem. Dit stuk gaat in op de problematiek van de vele vertaalslagen die liggen tussen de klanteneisen en een resulterend informatiesysteem en hoe de testdiscipline hier op af te stemmen. Met testen wordt hier zowel de verificatie (is gebouwd conform specificaties) als de validatie (is gebouwd wat gevraagd is) bedoeld. 2.2 Een praktijkvoorbeeld Het volgende voorbeeld illustreert het belang van het testproces in relatie tot requirements. Klanteneis: Het management van een huizensite besluit dat geregistreerde bezoekers voortaan via een speciale optie het interieur van aangeboden objecten virtueel kunnen bezoeken. Enkele hieruit voorkomende Requirements: Business: geregistreerde bezoekers moeten via een speciale optie het interieur van aangeboden objecten virtueel kunnen bezoeken. User: De per aangeleverde virtuele films moeten met maximaal 3 handelingen aan een object kunnen worden gekoppeld. Systeem: De maximale belasting is 100 gelijktijdige bezoekers, tot aan deze belasting moet een bezoeker met een 2 MB verbinding ongestoord rond kunnen surfen met maximale wachttijden van 5 seconden Bij het testen komen enkele belangrijke bevindingen naar voren: Het user-requirement is niet haalbaar, er zijn 5 handelingen per object nodig. Het systeem-requirement van 100 gelijktijdige bezoekers blijkt onverwacht ontzettend kostbaar te zijn, tot een belasting van 50 gelijktijdige bezoekers wordt voldaan aan de 5 seconden-eis maar daarboven neemt de wachttijd dramatisch toe. Na analyse: Het blijkt dat 5 handelingen geen enkel probleem is, 4 van de 5 zijn een simpele muisklik en in totaal duurt het koppelen van een object maximaal 3 minuten, ver onder de verwachting van 15 minuten per keer. De dramatische terugval is te wijten aan een instelling op de database-server van de provider. In productie: De eerste dagen loopt het systeem als voorheen, er komen complimenten binnen van potentiële kopers en al snel neemt het bezoek toe. Na 2 weken beginnen de problemen en na 3 weken is de site vrijwel dagelijks onbereikbaar.

5 Organisatie SYSQA B.V. Pagina 5 van 10 Na analyse: Het blijkt dat het aantal geregistreerde bezoekers ver boven verwachting is. Dagelijks zijn gemiddeld ongeveer 5000 bezoeken aan virtuele interieurs met piekbelastingen van 500 gelijktijdige. Nader onderzoek wijst uit dat alle bezoekers geregistreerd worden (al dan niet na het invullen van persoonlijke gegevens), de oorspronkelijke bedoeling van het management was geautoriseerd. Vanwege de concurrentiegevoeligheid was over het aantal echte (geregistreerde in de taal van het realisatieteam) bezoekers geen informatie beschikbaar gesteld, in de veronderstelling dat bezoekers die gebruik wilden maken van de virtueel-optie zich zouden aanmelden en dat hierover dus een flinke controle was. Uit dit fictieve voorbeeld blijkt dat bij een relatief eenvoudige klanteneis flinke verstoringen van het bedrijfsproces kunnen veroorzaken als er fouten in de vertaalslagen worden gemaakt of requirements onvoldoende specifiek zijn. Het probleem in dit geval is dat het businessrequirement onvoldoende onderzocht en gevalideerd is. 2.3 Requirementsprocessen in relatie tot testen De set requirements vastgelegd in de requirementsbaseline is idealiter juist en volledig opgesteld bij de start van het project en de individuele requirements zijn hierbij SMART 1, geprioriteerd op basis van de risicoanalyse, testbaar, voorzien van toelichtingen en consistent met andere requirements. Middels requirements management worden wijzigingsvoorstellen gecontroleerd afgehandeld. In de praktijk zal men echter vaak een set requirements hanteren die op veel punten niet aan deze eisen voldoet. Een pragmatisch uitgangspunt bij de voorbereidingen voor het testproces is dan ook een zo vroeg mogelijke betrokkenheid bij de totstandkoming van (wijzigingen op) de requirements in de vorm van bijvoorbeeld reviews, validaties, use-case- en teststrategie-overleggen etc. 2.4 Het testproces De rode draad door het testproces is de set overeengekomen requirements tussen opdrachtnemer en opdrachtgever op basis waarvan het informatiesysteem wordt gerealiseerd. De requirements worden in het ontwikkelproces uitgewerkt in ontwerp-, bouw-, gebruiks- en beheerdocumenten en vormen als geheel de testbasis. Het testproces is erop ingericht de bij de requirements behorende productrisico s af te dekken. Bij de ontwikkel- en systeemtesten worden als basis voor het testen met name de technische en functionele ontwerpen gebruikt, welke zijn afgeleid uit de requirements. Hierbij ligt de nadruk op verificatie van het ontwikkelde systeem ten opzichte van de ontwerpspecificaties. Vervolgens worden bij de acceptatietesten de (dan actuele!) requirements als basis gebruikt. Hierbij ligt de nadruk op het valideren van het gebouwde systeem tegen de overeengekomen klanteneisen. Het eindproduct van het testproces is een advies dat aangeeft in hoeverre de geïdentificeerde risico s zijn afgedekt. De relatie naar requirements vanuit de risico-analyse en de ontwerpspecificaties moet zijn geborgd zodat inzichtelijk is in hoeverre de requirements zijn gerealiseerd Testbaarheid De formulering van de requirements dient zo te zijn dat onder gegeven omstandigheden (S van specifiek) een eenduidig, voorspelbaar en meetbaar (M) resultaat kan worden afgeleid. Het toevoegen van acceptatiecriteria, voorzien van meetvoorschriften, verhoogt de testbaarheid en versnelt het acceptatieproces door de gebruikers- en beheerorganisatie. Tijdens de voorbereiding en specificatie van de testen wordt getoetst of hieraan wordt voldaan. Vanuit de testdiscipline wordt hiervoor een formele intake op de requirements gedefinieerd. Hiermee wordt de testbaarheid beter geborgd. 1 Specifiek, Meetbaar, Acceptabel, Realistisch, Tijdgebonden

6 Organisatie SYSQA B.V. Pagina 6 van 10 Een goede testbaarheid geeft ook veel meer inzicht in de benodigde testtijd. Zo kan in een vroegtijdig stadium een realistischer testplanning worden afgegeven. Door de definitie en uitwerking van testgevallen worden requirements inzichtelijker en wellicht geherformuleerd zodat ze beter aansluiten op de werkelijke klanteneisen. In de praktijk is het testproces vaak laat gepland zodat geen ruimte en budget meer is om de requirements aan te passen. Er kunnen overigens altijd requirements zijn die niet testbaar zijn, bijvoorbeeld omdat het een business requirement is gebaseerd op een marktonderzoek. Voor zover mogelijk worden met nadere detaillering en uitwerking wel testbare requirements geformuleerd Teststrategie De requirements spelen een belangrijke rol bij het bepalen van de overall teststrategie, vastgelegd in het mastertestplan. Hierin wordt bepaald welke testsoorten en testvormen worden onderkend en in welke volgorde deze worden uitgevoerd. Voor het vaststellen van de teststrategie is de productrisicoanalyse in combinatie met de requirements het uitgangspunt. Testen is het afdekken van de productrisico s. Deze risico s worden geanalyseerd op basis van de gestelde requirements en de gekozen oplossingsrichting. Veelal wordt de teststrategie gedurende de specificatiefase uitgevoerd. Het risico van het parallel uitvoeren van teststrategie en -specificatie is dat tijdens de teststrategie ontdekte fouten in de requirements niet worden meegenomen in de specificaties. Dit verhoogt de herstelkosten. De gekozen ontwikkelmethodiek is ook van groot belang bij het opstellen van de teststrategie. Bij een iteratief ontwikkelproces is een goede afstemming tussen ontwikkel- en testteam nodig. Dit leidt tot betere keuzes over inhoud, volgorde van de diverse te ontwikkelen incrementen of onderdelen van het systeem. Ofwel welke requirements worden wanneer gerealiseerd Testdekking Voor de verschillende testen wordt vastgesteld welke requirements relevant zijn. Andersom wordt per requirement vastgesteld welke testen onderzoeken in hoeverre het informatiesysteem hieraan voldoet. De testdekking is de mate waarin het risico behorende bij bepaalde requirements wordt afgedekt. In een traceerbaarheidmatrix wordt hiervoor de relatie aangegeven tussen de requirements en de bijbehorende testen. Omdat dit een arbeidsintensief proces is het raadzaam hierbij een geautomatiseerd requirements/testtool in te zetten.

7 Organisatie SYSQA B.V. Pagina 7 van De relatie tussen het requirements- en testproces in het systeemontwikkeltraject Als we de requirements- en testprocessen in de context van het ontwikkelproces bekijken dan kan de samenhang schematisch worden weergegeven: Figuur 5.1: Requirements- en testproces in het systeemontwikkeltraject Let wel: er zijn verschillende manieren en modellen mogelijk waarin requirements- en testprocessen met elkaar in relatie worden gebracht. Bovenstaand is een mogelijke weergave afgebeeld en toegelicht. In de praktijk kan bij organisaties de rangschikking hiervan afwijken. Toelichting: 1. De oorsprong van de klanteneisen wordt gevormd door de voor het project relevante bedrijfsprocessen. Klanteneisen kunnen ook leiden tot veranderingen in de bedrijfsprocessen. Let op: het nieuwe systeem kan leiden tot nieuwe processen (bijvoorbeeld in geval van buitenaf opgelegde eisen als wetgeving). 2. Zodra de klanteneisen vorm gaan krijgen en besluitvorming plaatsvindt om een verandertraject in te gaan zal het requirements managementproces gestart worden. Vanuit RM wordt aandacht gegeven om de scope te bepalen. Later in het verandertraject zal deze relatie steeds formeler en strakker worden naarmate het project zijn opleverdatum nadert. De requirements- en testmanager zullen hierbij de projectmanager adviseren bij het stellen van prioriteiten. 3. Vanuit de klanteneisen wordt verder gefocust op het verzamelen, analyseren en ontwikkelen van de requirements. 4. Gedurende de requirements ontwikkeling zal het requirements management ook verder inhoud krijgen. Vanuit RM zal sturing aanwezig zijn om de scope (opnieuw) vast te stellen. 5. Requirements ontwikkeling leidt tot een vastgestelde versie van de requirementsbaseline, de basis voor verdere projectactiviteiten. 6. De requirementsbaseline is de brug tussen requirements ontwikkeling en requirements management. 7. De requirementsbaseline dient (o.a.) als basis voor ontwikkeling, met name het basisontwerp. 8. De requirementsbaseline dient (o.a.) als basis voor test, met name de teststrategie. 9. Gedurende ontwikkeling en test vindt voortdurende afstemming plaats in de vorm van toetsen, testen en overleggen (van verkennende gesprekken tot formele bevindingenoverleggen). 10. Het ontwikkelproces levert informatie aan requirements management in de vorm van wijzigingsvoorstellen door voortschrijdend inzicht, traceerbaarheidsgegevens en statusgegevens.

8 Organisatie SYSQA B.V. Pagina 8 van Het testproces levert informatie aan requirements management in de vorm van bevindingen op de requirements, traceerbaarheidsgegevens en statusgegevens. 12. Het gerealiseerde en geteste informatiesysteem (software, hardware, data, procedures, documentatie, getraind personeel, etc.) wordt opgeleverd ter acceptatie. Bevindingen uit het acceptatieproces leiden eventueel tot extra ontwikkelinspanning zonder dat requirements management hier een rol in speelt zie ook Het testadvies wordt opgeleverd ter ondersteuning van acceptatie. Bevindingen uit het acceptatieproces leiden eventueel tot extra testinspanning zonder dat requirements management hier een rol in speelt zie ook De requirementsbaseline dient (o.a.) als referentiekader voor acceptatie, in de vorm van (voor zover mogelijk meetbare) acceptatiecriteria. 15. Het acceptatieproces leidt wellicht tot wijzigingsvoorstellen. Requirements management levert input en stuurt waar nodig het acceptatieproces. 16. Bij het acceptatieproces spelen de relevante bedrijfsprocessen een cruciale rol. Hier vindt de uiteindelijke validatie plaats in hoeverre het gerealiseerde informatiesysteem bij zal dragen aan de realisatie of verbetering van de bedrijfsprocessen. 17. Requirements management leidt tot terugkoppeling naar klanteneisen, requirements ontwikkeling (bij ingrijpende wijzigingen) en de requirementsbaseline (overzichtelijk, direct formeel vast te leggen wijzigingen). 18. Directe terugkoppeling uit requirements management op het ontwikkelproces zonder impact op de requirementsbaseline. 19. Directe terugkoppeling uit requirements management op het testproces zonder impact op de requirementsbaseline. 20. Het gerealiseerde informatiesysteem wordt na acceptatie in gebruik en beheer genomen. 21. Gebruik en beheer levert input aan requirements management bij incidenten en onderhoud. Directe terugkoppeling uit requirements management op het gebruik- en beheerproces zonder impact op de requirementsbaseline. 22. Gedurende de eerste fase van ingebruikname zal het gerealiseerde informatiesysteem steeds beter geïntegreerd raken in de relevante bedrijfsprocessen en op den duur zal deze lijn dan ook niet meer nodig zijn, het gerealiseerde systeem maakt dan deel uit van de relevante bedrijfsprocessen (stippellijn). 23. Bij de requirements ontwikkeling zullen de relevante bedrijfsprocessen altijd als belangrijk referentiekader dienen. 24. Bij het ontwikkelproces zullen de relevante bedrijfsprocessen altijd als belangrijk referentiekader dienen. 25. Bij het testproces zullen de relevante bedrijfsprocessen altijd als belangrijk referentiekader dienen. 2.6 Tips voor gebruik in de praktijk: het belang van requirements voor het testproces Het testteam heeft direct belang bij een goede uitvoering van de requirementsprocessen. Blijf hierop (gedoseerd) hameren. Gebruik argumenten als testbaarheid, een beter beheersbaar acceptatieproces, minder misverstanden tussen de diverse disciplines, met name gebruikers, ontwikkelaars en testers, een duidelijker wijzigingsproces waar alle betrokkenen (uiteindelijk) profijt van hebben. De grootte en volwassenheid van de organisatie spelen een belangrijke rol: stel vanuit het testen zo goed mogelijk vast op welk niveau de requirementsprocessen worden uitgevoerd. Gebruik hierbij de beschikbare checklist Requirements Engineering vanuit de kennisbank. Houd interviews met belanghebbenden. Informeer bij collega s uit andere projecten. Zachte aspecten als politiek, verhoudingen tussen afdelingen of medewerkers spelen geregeld een grote rol. Gecombineerd met tijdsdruk, complexiteit, (onvoorziene) wijzigingen etc. kan de spanning en werkdruk aanzienlijk oplopen. Vaak wordt de pijn naar achteren in het traject geduwd met als resultaat een testtraject dat zwaar onder druk komt te staan. Heldere requirements, een goede risico- en impactanalyse, duidelijke wijzigingsvoorstellen e.d. zijn dan een wapen om het testtraject beter te beheersen. De essentie is dat uit het (eventueel geforceerd naar voren gehaalde) testadvies de risico s inzichtelijk worden gemaakt op basis van de testresultaten, de requirements, aanvullende acceptatiecriteria etc.

9 Organisatie SYSQA B.V. Pagina 9 van 10 Traceerbaarheid kan goed geregeld worden met tools. Bij traceerbaarheid gaat (zoals gewoonlijk) de kost voor de baat uit. Helaas zien veel partijen de baten van traceerbaarheid te laat in (op het moment van grote wijzigingen als impactanalyses nodig zijn). Het kan helpen als vanaf de aanvang van het testtraject inzichtelijk wordt gemaakt hoeveel tijdwinst geboekt kan worden als traceerbaarheidsgegevens beschikbaar zijn. Uiteraard verhogen de traceerbaarheidsgegevens ook het overzicht van en inzicht in de voortgang. Daar waar specifieke tools niet beschikbaar zijn: begin eenvoudig met word of excel (zie sjablonen). Alleen al met een excelsheet is inzichtelijk te maken dat er requirements zijn die niet beantwoord worden in concrete producten en andersom producten die geen relatie hebben met een (geprioriteerde en gevalideerde) eis. Daarnaast maken alle eerste inspanningen in Word of Excel duidelijk aantoonbaar dat het beheren van requirements zonder adequete tooling lastig en arbeidsintensief is. Daarmee wordt als het ware vanzelf een businesscase gegegeneerd voor aanschaf van tooling. De tool wordt dan ook ontvangen als hulpmiddel om een lastige klus te vergemakkelijken. Direct starten met een kostbaar en complex tool leidt daarentegen vaak tot de beleving dat het werk door het tool complexer wordt gemaakt; voordat het tool werd gehanteerd hoefde al die ingewikkelde rompslomp immers niet Start vanuit het testproces hoe dan ook met reviews op requirements of andere goedgekeurde documenten die als requirement fungeren binnen het project. Daar waar testen pas later bij het project wordt betrokken is veelal de inhoud onvoldoende concreet om testen op te kunnen baseren. Bijkomend effect is dat uit de reviews blijkt dat de kwaliteit eigenlijk ook nog onvoldoende is om op te bouwen en veel ruimte geeft voor aannames. Tracht vanuit het reviewproces de bevindingen om te zetten als besparingen. Onderzoek toont aan dat ieder uur geïnvesteerd in reviewen gemiddeld vijf tot zeven uur minder herstelwerk oplevert. Met behulp van de wet van Boehm is binnen een specifiek project aantoonbaar te maken dat fouten vroegtijdig gevonden uiteindelijk de herstelkosten verlagen. Daarmee is zichtbaar dat reviewen het project geld én tijd oplevert in plaats van dat het tijd kost. Dit verhoogt de acceptatie van reviewen en verstevigt de positie, belang en besef van toegevoegde waarde van de testdiscipline binnen het project.

10 Organisatie SYSQA B.V. Pagina 10 van 10 3 Literatuuropgaven 1. Wiegers Karl E., Software Requirements, Microsoft Press, CMMI for Development CMMI-DEV, V1.2, Carnegie Mellon University, Barry W Boehm, Software Engineering Economics, Prentice-Hall, ISBN , Cannegieter, Jan Jaap, Kwaliteitszorg in ICT projecten - de PROQA methode, Ten Hagen Stam, ISBN , M. Arendsen, H.J.J. Cannegieter, A. Grund, P. Heck, S. de Klerk en J. Zandhuis, Succes met de requirements!, SDU, ISBN , Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon, Tmap Next, Tutein Nolthenius, ISBN , Requirements, een introductie, kennisbank SYSQA.

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

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

Nadere informatie

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

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

Nadere informatie

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

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

Nadere informatie

van TESTmanagement naar testmanagement

van TESTmanagement naar testmanagement Ontwikkelingen in testmanagement: van TESTmanagement naar testmanagement Presenta9e TestNet Voorjaarsevenement 10 mei 2011 Peter Logman & Arno Dijkmans Agenda Wie zijn wij? TESTmanagement Sleutelmomenten

Nadere informatie

Testen kost te veel tijd

Testen 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 informatie

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

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

Nadere informatie

Handout. Hoe testers de kwaliteit van requirements kunnen beïnvloeden. Slechte requirements zijn overal. Testnet thema-avond Requirements.

Handout. Hoe testers de kwaliteit van requirements kunnen beïnvloeden. Slechte requirements zijn overal. Testnet thema-avond Requirements. Hoe testers de kwaliteit van requirements kunnen beïnvloeden Testnet thema-avond Slechte requirements zijn overal 2 Pagina 1 En dan heb je goede requirements 3 proces proces ontwikkeling validatie management

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

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

Nadere informatie

PROQA 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. 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 informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

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

Nadere informatie

Vrijgaveadvies. Project <naam project>

Vrijgaveadvies. 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 informatie

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Data 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 informatie

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

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

Nadere informatie

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

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

Nadere informatie

Procesvalidatie voor een veiliger ketentest

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

Nadere informatie

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

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

Nadere informatie

Reviewtypen en reviewplanning. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Reviewtypen en reviewplanning. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Reviewtypen en reviewplanning Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 INLEIDING ALGEMEEN... 3 1.2 INTRODUCTIE

Nadere informatie

Testaanpak: leidraad voor het kiezen van een testtechniek

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

Nadere informatie

Voorbeeldexamen. Testen Foundation. Editie maart 2012

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

Nadere informatie

De tester als bruggenbouwer

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

Nadere informatie

Johan Zandhuis Boek: Succes met de requirements! Voorjaarsevent Testnet: 22 juni 2009

Johan Zandhuis Boek: Succes met de requirements! Voorjaarsevent Testnet: 22 juni 2009 Titel, samenvatting en biografie Samenvatting: Boek: Succes met de! Voorjaarsevent Testnet: 22 juni 2009 Waarom nog een boek over, ik heb al een boek. In het boektrack Succes met de! gaat een van de auteurs

Nadere informatie

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

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

Nadere informatie

Ontwikkelaar ICT. Context. Doel

Ontwikkelaar 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 informatie

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

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

Nadere informatie

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

8-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 informatie

TMap NEXT Test Manager

TMap NEXT Test Manager TMap NEXT Test Manager Preparation Guide Editie 201607 Copyright 2016 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system or

Nadere informatie

2.F.12 CHECKLIST REQUIREMENTS ENGINEERING DOEL

2.F.12 CHECKLIST REQUIREMENTS ENGINEERING DOEL 2.F.12 CHECKLIST REQUIREMENTS ENGINEERING DOEL Het doel van deze checklist is het bepalen van de sterke en zwakke punten van de huidige werkwijze ten aanzien van requirements engineering. Met behulp van

Nadere informatie

Informatiebeveiliging voor de requirementsanalist

Informatiebeveiliging voor de requirementsanalist voor de requirementsanalist SYSQA B.V. Almere Datum : 15 april 2013 Versie : 1.0 Status : Definitief Opgesteld door : Organisatie: SYSQA BV Pagina 2 van 11 Inhoudsopgave Inhoudsopgave... 2 1 Inleiding...

Nadere informatie

Handleiding. Teststrategie

Handleiding. Teststrategie Handleiding Teststrategie SYSQA B.V. Datum : 12-01-2009 Status : Definitief Opgesteld door : Nico van Mourik Organisatie SYSQA B.V. Pagina 2 van 27 Inhoudsopgave 1 INLEIDING... 4 1.1 ALGEMEEN... 4 1.2

Nadere informatie

De 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. 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 informatie

Mastertestplan <<Naam project>> <<Organisatie>>

Mastertestplan <<Naam project>> <<Organisatie>> Mastertestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie Pagina 2 van 17 Inhoudsopgave 1 Management

Nadere informatie

Risico s bij ERP. SYSQA B.V. Almere. Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door :

Risico s bij ERP. SYSQA B.V. Almere. Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door : Risico s bij ERP SYSQA B.V. Almere Datum : 6 mei 2013 Status : Definitief Versie : 2.0 Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 13 Titel Risico s bij ERP Versie 2.0 Datum 06-05-2013 Inhoudsopgave

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library 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

Nadere informatie

Linkedin discussie: Hoe kan je best geld besparen op testen?

Linkedin 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 informatie

EISEN AAN TESTPLANNEN

EISEN AAN TESTPLANNEN EISEN AAN TESTPLANNEN Auteur : Datum : Versie :.. Status :.. Datum overdracht : Overgedragen aan : Inhoudsopgave 1 Inleiding...

Nadere informatie

Testgedreven ontwikkeling dat is pas veilig!

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

Nadere informatie

BDD/Gherkin. Een introductie

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

Nadere informatie

Test Management Assessment

Test Management Assessment Test Management Assessment Bart Knaack 1 Spreker wie ben ik? Bart Knaack Testmanager LogicaCMG Medewerker Test Research Centre Huidige opdracht: Legacy transformation testing bij Nationale Nederlanden.

Nadere informatie

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

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

Nadere informatie

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

Functiepuntanalyse. 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 informatie

ISACA round-table 7 december 2009 Rik Marselis

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

Nadere informatie

Martin van Leeuwen Happy Testing

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

Nadere informatie

Outsourcing zorgt voor betere requirements

Outsourcing zorgt voor betere requirements outsourcing t We moeten wel! Outsourcing zorgt voor betere requirements In veel organisaties is sprake van gebrekkige requirements en requirementsprocessen. Outsourcing lijkt dan geen goed idee. Outsourcing

Nadere informatie

Checklist Slimme vragenlijst regievoering

Checklist Slimme vragenlijst regievoering Checklist Slimme vragenlijst regievoering versie 2.0 Slimme vragenlijst Leveranciersselectie Hoe stel ik vast dat dit beste leverancier is? Welke criteria hanteer ik daarbij? Wat als het selectieproces

Nadere informatie

14/11/2010. Een duurzame testaanpak voor een veranderd informatiesysteem. Agenda. Wie is Albert?

14/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 informatie

TMAP NEXT. BDTM voor opdrachtgevers

TMAP NEXT. BDTM voor opdrachtgevers TMAP NEXT BDTM voor opdrachtgevers auteurs: Aalst, L. van der, Baarda, R., Roodenrijs, E., Vink, J., Visser, B. gebaseerd op de originele publicatie in: TMap NEXT, Business Driven Test Management, Aalst,

Nadere informatie

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

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

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

Nadere informatie

Testen+ 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+ 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 informatie

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

Requirements. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Requirements Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SysQa BV Pagina 2 van 19 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 2 WAT ZIJN REQUIREMENTS... 4 2.1

Nadere informatie

Testen bij DWH-projecten

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

Nadere informatie

Het W-model: de groei naar voren. Jan Jaap Cannegieter. Praktijk van ICT-projecten

Het W-model: de groei naar voren. Jan Jaap Cannegieter. Praktijk van ICT-projecten Het W-model: de groei naar voren Jan Jaap Cannegieter Adjunct Directeur SYSQA B.V. Praktijk van ICT-projecten Req Ontwerp Realisatie Testen Testen Testen 44% van de projecten overschrijdt budget of tijd

Nadere informatie

HERGEBRUIK VAN REQUIREMENTS

HERGEBRUIK 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 informatie

Riskpoker - Confirmation - Planningpoker. Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink

Riskpoker - Confirmation - Planningpoker. Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink Riskpoker - Confirmation - Planningpoker 10-7-2013 Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink 1 Presentatie (sprint) backlog items 1 2 3 4

Nadere informatie

Auteur Kenmerk Versie 1.0 Datum Bestandnaam Status Definitief. NK Software Testen 2017

Auteur 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 informatie

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

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

Nadere informatie

Najaarsspecial Oktober 2013

Najaarsspecial 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 informatie

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Extended ISO 9126: 2001. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Extended ISO 9126: 2001 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 informatie

Een 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 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 informatie

Geef de titel van het wijzigingsverzoek zo kort mogelijk weer.

Geef de titel van het wijzigingsverzoek zo kort mogelijk weer. Naam indiener WIJZIGINGSVOORSTEL Nummer: xxx Datum: dd-mm-jj Status: stap 1, 2, 3, 4 of 5 Bedrijfsonderdeel/afdeling/ functie Naam projectmanager Naam wijzigingsbehandelaar (indien van toepassing) Het

Nadere informatie

1,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? 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 informatie

notitie Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen Definitief; vastgesteld Stuurgroep 4P

notitie Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen Definitief; vastgesteld Stuurgroep 4P notitie Van project onderwerp opgemaakt door Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen status datum opmaak 20-7-2012 bijlagen Definitief; vastgesteld Stuurgroep 4P

Nadere informatie

Software Test Plan. Yannick Verschueren

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

Nadere informatie

PROJECT INITIATION DOCUMENT

PROJECT INITIATION DOCUMENT PROJECT INITIATION DOCUMENT Versie: Datum: x.x dd-mm-jj DOCUMENTATIE Versie Naam opdrachtgever Naam opsteller Datum: dd-mm-jj Voor akkoord: Datum:. INHOUDSOPGAVE 1. Managementsamenvatting

Nadere informatie

Agenda. Introductie Aan het werk Conclusie / restrospective

Agenda. 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 informatie

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

TMapNext. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. TMapNext Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 15 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...FOUT! BLADWIJZER

Nadere informatie

Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten

Verschillen 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 informatie

2 TESTEN: HET RISK SPEL

2 TESTEN: HET RISK SPEL 2 TESTEN: HET RISK SPEL 2.1 De relatie tussen testen en risico Eén van de moeilijkste onderdelen van testen is het vinden van een goede balans tussen de hoeveelheid tijd en geld die aan testen besteed

Nadere informatie

Het plan van aanpak, een hele klus

Het plan van aanpak, een hele klus Het plan van aanpak, een hele klus door Wim - 02-02-2011 http://www.itpedia.nl/2011/02/02/het-plan-van-aanpak-een-hele-klus/ Hoe groot of hoe klein maak je een plan van aanpak? Welke onderdelen neem je

Nadere informatie

Requirements Management Werkgroep Traceability

Requirements Management Werkgroep Traceability Requirements Management Werkgroep Traceability Plan van Aanpak (1) Doel en definitie van Traceability Traceability heeft tot doel om tijdens het ontwikkelproces status informatie te verschaffen omtrent

Nadere informatie

Business Intelligence Teststrategie

Business Intelligence Teststrategie Business Intelligence Teststrategie een teststrategie volgens TMap NEXT Schiphol, 30 september 2009 Bart Vrenegoor, Sogeti Nederland B.V. Programma Waarom een teststrategie? Opstellen BI-Teststrategie

Nadere informatie

Testen en QA bij pakketimplementaties

Testen 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 informatie

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

Balanced Scorecard. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Balanced Scorecard 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 DE

Nadere informatie

Van Samenhang naar Verbinding

Van Samenhang naar Verbinding Van Samenhang naar Verbinding Sogeti Page 2 VAN SAMENHANG NAAR VERBINDING Keuzes, keuzes, keuzes. Wie wordt niet horendol van alle technologische ontwikkelingen. Degene die het hoofd koel houdt is de winnaar.

Nadere informatie

Checklist testen Lopende zaken MijnOverheid. Versie 1.1

Checklist 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 informatie

Met dit whitepaper bieden we u een overzicht we een aantal soorten (product-) toetsing. Dit overzicht is niet volledig!

Met 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 informatie

Jan Jaap Cannegieter Reviews succesvol toepassen bij uitbesteding Najaarsevent TestNet: 22 september 2009

Jan Jaap Cannegieter Reviews succesvol toepassen bij uitbesteding Najaarsevent TestNet: 22 september 2009 Titel, samenvatting en biografie Samenvatting Jan Jaap Cannegieter Reviews succesvol toepassen bij uitbesteding Najaarsevent TestNet: 22 september 2009 Reviews, het testen aan de voorkant, worden als zeer

Nadere informatie

Van Risicoanalyse tot Teststrategie

Van 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 informatie

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA.

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven Johan Zandhuis SYSQA Start: 1999 Onafhankelijk Quality Assurance in IT 150 medewerkers (en groeiend) 2 SYSQA Operationeel

Nadere informatie

TMAP NEXT. TMap in essenties

TMAP 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 informatie

Whitepaper Test Management Business case voor geautomatiseerd testen

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

Nadere informatie

Kwaliteit van testen. Onbeheersbaar of ongecontroleerd? thema

Kwaliteit 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 informatie

TMap Process Template voor Visual Studio Het

TMap Process Template voor Visual Studio Het Testen TMap Process Template voor Visual Studio 2010 TESTAANPAK VOOR EFFICIËNT GEBRUIK VS2010 ALM TOOLS Rob Kuijt en Clemens Reijnen Begin jaren 90 brak het besef door dat testen niet iets is dat een ontwikkelaar

Nadere informatie

Productrisicoanalyse in de praktijk

Productrisicoanalyse 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 informatie

Testplan IpMEDT3 project

Testplan IpMEDT3 project Testplan IpMEDT3 project Versie: 1.0 Groepsbegeleider: Bob Zadok Blok Groepsleden: Luuk Gortzak (s1062708) Jens Brokaar (s1066589) Ellis Stroet (s1066586)

Nadere informatie

Bijlage 3: Master testplan

Bijlage 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 informatie

Software Test Plan. Yannick Verschueren

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

Nadere informatie

NGI-Noord. Mei 2007. Tim Koomen Leo van der Aalst Michiel Vroon

NGI-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 informatie

DATAMODELLERING SIPOC

DATAMODELLERING 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 informatie

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

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

Nadere informatie

DATAMODELLERING BEGRIPPENBOOM

DATAMODELLERING BEGRIPPENBOOM DATAMODELLERING BEGRIPPENBOOM Inleiding In dit whitepaper wordt de datamodelleervorm begrippenboom inclusief de begrippenlijst beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.

Nadere informatie

10 trends in Performance testen of: wat hebben we écht te bieden?

10 trends in Performance testen of: wat hebben we écht te bieden? 10 trends in Performance testen of: wat hebben we écht te bieden? Martijn Ruff 30 mei 2012 Agenda Even voorstellen... Introductie 10 Trends Conclusies KETENBEWAKING TM 2 Even voorstellen... KETENBEWAKING

Nadere informatie

Themasessie Verificatie & Validatie, `Testen in de praktijk. Hotel v.d. Valk Nieuwerkerk, Parallelweg Zuid 185, 2914 LE Nieuwerkerk aan den IJssel

Themasessie Verificatie & Validatie, `Testen in de praktijk. Hotel v.d. Valk Nieuwerkerk, Parallelweg Zuid 185, 2914 LE Nieuwerkerk aan den IJssel Verslag: Themasessie Verificatie & Validatie, `Testen in de praktijk Datum: 21 juni 2017 Locatie: Aanwezig: Hotel v.d. Valk Nieuwerkerk, Parallelweg Zuid 185, 2914 LE Nieuwerkerk aan den IJssel Zie bijgaande

Nadere informatie

1.1 Controles DNB voert verschillende controles uit wanneer een rapportage in het DLR is ingediend. Deze zijn in onderstaand schema aangegeven:

1.1 Controles DNB voert verschillende controles uit wanneer een rapportage in het DLR is ingediend. Deze zijn in onderstaand schema aangegeven: Onderwerp: CRD-IV Alert XBRL Special Februari 2016 Divisie Statistiek Afdeling Bancaire Toezichtstatistieken In deze editie van de CRD-IV Alert XBRL Special gaan we verder in op het verwerkingsproces van

Nadere informatie

TESTEN DUUR? NIET TESTEN IS DUURDER!

TESTEN DUUR? NIET TESTEN IS DUURDER! TESTEN DUUR? NIET TESTEN IS DUURDER! Bepaal het testkostenoptimum met eenvoudige kengetallen auteurs: Leo van der Aalst en Corné de Koning gebaseerd op de originele publicatie in: Informatie 2010, Sogeti

Nadere informatie

REFERENTIE BIJLAGE 1 PRA-FORMULIER BIJLAGE 2 INTERACTIE MATRIX (VOORBEREIDING PRA

REFERENTIE BIJLAGE 1 PRA-FORMULIER BIJLAGE 2 INTERACTIE MATRIX (VOORBEREIDING PRA Werkinstructie : HSEW Blz. : 1 van 10 INDEX 1 SCOPE 2 DOEL 3 PROCEDURE 3.1 Inleiding: 3.2 Voorwaarden: 3.3 Organisatie: 3.4 Werkwijze 3.4.1 PRA-0 3.4.2 PRA-1 3.4.3 PRA-2 3.4.4 Toll-gate 4 UITKOMST 5 RAPPORTAGE

Nadere informatie

Inspecties. Een introductie SYSQA B.V.

Inspecties. Een introductie SYSQA B.V. Inspecties Een introductie SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 INLEIDING ALGEMEEN... 3 1.2 HISTORIE... 4 2 FASERING VAN INSPECTIE... 5 2.1 PLANNING... 5

Nadere informatie

Sjabloon testplan op basis van SYSQA -teststrategieaanpak. <<Organisatie>>

Sjabloon 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 informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

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

Nadere informatie

Woordenlijst bij TMap

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

Nadere informatie