Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.
|
|
- Joanna van de Berg
- 8 jaren geleden
- Aantal bezoeken:
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. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING...3 1.1 ALGEMEEN...3 1.2 VERSIEBEHEER...3
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 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 informatievan 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 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 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 informatieHandout. 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 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 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 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 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 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 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 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 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 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 informatieReviewtypen 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 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 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 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 informatieJohan 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 informatieRUM. 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 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 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 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 informatieTMap 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 informatie2.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 informatieInformatiebeveiliging 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 informatieHandleiding. 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 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 informatieMastertestplan <<Naam project>> <<Organisatie>>
Mastertestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie Pagina 2 van 17 Inhoudsopgave 1 Management
Nadere informatieRisico 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 informatieBISL 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 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 informatieEISEN AAN TESTPLANNEN
EISEN AAN TESTPLANNEN Auteur : Datum : Versie :.. Status :.. Datum overdracht : Overgedragen aan : Inhoudsopgave 1 Inleiding...
Nadere informatieTestgedreven ontwikkeling dat is pas veilig!
Testgedreven ontwikkeling dat is pas veilig! INTRODUCTIE ANKO TIJMAN 2 Software tester sinds 1997 (TMap, ISEB Practitioner) Eerste agile ervaring in 2001 Presentaties op (inter)nationale congressen Nov
Nadere 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 informatieTest 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 informatiePROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D
PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT
Nadere 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 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 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 informatieOutsourcing 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 informatieChecklist 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 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 informatieTMAP 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 informatieEvo 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 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 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 informatieRequirements. 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 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 informatieHet 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 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 informatieRiskpoker - 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 informatieAuteur Kenmerk Versie 1.0 Datum Bestandnaam Status Definitief. NK Software Testen 2017
Auteur Versie 1.0 Datum 01-05-2017 Bestandnaam Definitief NK Software Testen 2017 Inhoudsopgave 1 Distributie lijst 3 2 Management samenvatting 4 2.1 Opdracht 4 2.2 Scope van de opdracht 4 2.3 tabel 5
Nadere 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 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 informatieExtended 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 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 informatieGeef 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 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 informatienotitie 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 informatieSoftware Test Plan. Yannick Verschueren
Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1
Nadere informatiePROJECT 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 informatieAgenda. Introductie Aan het werk Conclusie / restrospective
Agenda Introductie 13.45 14.30 Aan het werk 14.30 16.30 Conclusie / restrospective 16.30 17.00 Introductie High performance Testing Voorstellen Waar ben je echt goed in (3 minuten) Teams vormen op basis
Nadere informatieTMapNext. 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 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 informatie2 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 informatieHet 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 informatieRequirements 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 informatieBusiness 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 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 informatieBalanced 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 informatieVan 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 informatieChecklist testen Lopende zaken MijnOverheid. Versie 1.1
Checklist testen Lopende zaken MijnOverheid Versie 1.1 Datum Status 01 oktober Definitief Definitief Checklist testen Lopende zaken MijnOverheid 01 oktober 2013 Colofon Projectnaam MijnOverheid Versienummer
Nadere 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 informatieJan 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 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 informatieHandout. 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 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 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 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 informatieTMap 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 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 informatieTestplan IpMEDT3 project
Testplan IpMEDT3 project Versie: 1.0 Groepsbegeleider: Bob Zadok Blok Groepsleden: Luuk Gortzak (s1062708) Jens Brokaar (s1066589) Ellis Stroet (s1066586)
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 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 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 informatieDATAMODELLERING SIPOC
DATAMODELLERING SIPOC Inleiding In dit whitepaper wordt de datamodelleervorm Sipoc beschreven. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen. Wil je een beeld krijgen van
Nadere 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 informatieDATAMODELLERING 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 informatie10 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 informatieThemasessie 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 informatie1.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 informatieTESTEN 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 informatieREFERENTIE 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 informatieInspecties. 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 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 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 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 informatie