Handleiding. Teststrategie

Save this PDF as:
 WORD  PNG  TXT  JPG

Maat: px
Weergave met pagina beginnen:

Download "Handleiding. Teststrategie"

Transcriptie

1 Handleiding Teststrategie SYSQA B.V. Datum : Status : Definitief Opgesteld door : Nico van Mourik

2 Organisatie SYSQA B.V. Pagina 2 van 27 Inhoudsopgave 1 INLEIDING ALGEMEEN VERSIEBEHEER TESTEN EN DE REST VAN DE WERELD TESTEN IN DE ORGANISATIE RELATIE TOT PROJECTMODELLEN GEBRUIK VAN DEZE HANDLEIDING OPSTARTEN VAN HET TESTTRAJECT (DE STRATEGIE OP HOOFDLIJNEN) WIE DOELSTELLING INPUT SAMENVATTING PROCESSCHEMA BESCHRIJVING ACTIVITEITEN Intake (vastleggen van de testopdracht) Vastleggen randvoorwaarden en omgevingsfactoren Bepalen van de projectrisico s Inrichten risicomanagement Vaststellen van de stakeholders Vastleggen van de gewenste oplossingsrichting Product risico analyse m.b.v. de stakeholders Risico s koppelen aan een kwaliteitsattribuut De totale teststrategie Definitieve teststrategie Opstellen master testplan OUTPUT INRICHTING VAN HET DEEL TESTTRAJECT (DE DETAIL TESTSTRATEGIE) WIE DOELSTELLING OVERIGE INPUT SAMENVATTING PROCESSCHEMA BESCHRIJVING ACTIVITEITEN Detailintake aanwezige documentatie Uitvoeren van een Joint Testware Development (JTD) sessie Vaststellen specifieke productrisico s Koppelen van risico s en requirements Het opstellen van de detail teststrategie Het opstellen van het detail testplan testsoort Het opstellen van de testspecificaties en het testdraaiboek Uitvoeren van testrun Evaluatie van de testrun Bijwerken/detailleren van de testspecificaties Opstellen van een testverslag OUTPUT... 23

3 Organisatie SYSQA B.V. Pagina 3 van 27 5 TIPS & VALKUILEN LITERATUURVERWIJZINGEN BIJLAGEN SJABLONEN CHECKLISTS OVERIGE INFORMATIE... 27

4 Organisatie SYSQA B.V. Pagina 4 van 27 1 Inleiding 1.1 Algemeen In de testwereld in Nederland zijn diverse testmethodes gangbaar die allen een goede basis bieden voor het beheersen van een testtraject. Deze methodes bieden in sommige gevallen weinig houvast bij (of een beperkte blik op) het vaststellen van de teststrategie. Het gestructureerd testen zoals binnen SYSQA wordt toegepast, is grotendeels gebaseerd op TMap Next. Binnen SYSQA bestond de behoefte om met name het opzetten van de teststrategie verder te ontwikkelen zonder de goede items van de huidige aanpak te verliezen. Hiervoor is de expertisegroep Teststrategie in het leven geroepen. De opdracht van de directie van SYSQA aan de expertisegroep Teststrategie was: Ontwikkel praktisch toepasbaar materiaal om teststrategieën op te stellen, gebaseerd op risico s en/of requirements. Hierbij is aangetekend dat dit geen verzameling van praktijkervaringen dient te worden maar een algemeen toepasbare methodiek om te komen tot een teststrategie. Testen is geen stand alone activiteit. Het neerzetten van een teststrategie is dan ook niet alleen een zaak van het testen op zich. Testen heeft in de eerste plaats te maken met het project waar binnen wordt gewerkt en dus met projectmanagement. Daarnaast heeft testen te maken met overige kwaliteitsmaatregelen binnen een project, met de opdrachtgevers, met beheerorganisaties, etc. Om dit alles in perspectief te zetten is gekozen om de opdracht uit te breiden en is eerst het testtraject als model neergezet. Van daaruit is de stap gemaakt naar het proces van het komen tot een teststrategie. Vanuit het model van een testtraject zijn de relaties weergegeven met de binnen SYSQA gehanteerde modellen voor kwaliteit en projectmanagement. Dit impliceert wel dat kennis van Prince2 en PROQA, een methode voor het inrichten van kwaliteitszorg in ICT-projecten, als bekend wordt verondersteld. Deze handleiding is één van de producten die door de expertisegroep is geproduceerd. Tevens zijn er diverse templates en checklists opgeleverd. Een eventueel vervolg kan zijn de complete uitwerking van het testproces. 1.2 Versiebeheer Versie Status Datum Auteur Opmerkingen 0.1 Concept Expertisegroep Eerste concepten 0.2 Concept Expertisegroep Aanpassingen n.a.v. samenvoegen diverse stukken van leden van de expertisegroep Teststrategie. 0.3 Concept Expertisegroep Aanpassingen n.a.v. review en opmerkingen van leden expertisegroep, inpassen in template SYSQA 0.4 Concept Expertisegroep Aanpassingen na review 0.5 Concept Expertisegroep Toegevoegd hoofdstuk Concept Expertisegroep Document voor interne review door de expertisegroep leden. 0.9 Concept Expertisegroep Document aangeboden aan de Review Board van SYSQA BV 0.91 Concept Expertisegroep Eerste verwerking van de review punten 0.92 Concept Expertisegroep Verdere verwerking review punten 0.93 Concept Expertisegroep Verdere verwerking review punten 0.94 Concept Expertisegroep Verwerking review punten na bespreking expertise groep 0.95 Concept Expertisegroep Aanpassingen na review gesprek met JJ Cannegieter 1.0 Definitief Expertisegroep Finale aanpassingen obv discussie over reviewpunten 1.01 Definitief Expertisegroep Enkele spellingsfouten verwijderd 1.02 Concept SYSQA Verwijzingen van TMap veranderd naar TMap Next 1.03 Definitief SYSQA Aanpassingen gemaakt na de review.

5 Organisatie SYSQA B.V. Pagina 5 van 27 2 Testen en de rest van de wereld Testen is geen activiteit op zich. Het maakt deel uit van het totaal aan kwaliteitsmaatregelen binnen een project, het wordt beïnvloed door de wijze waarop een project wordt gemanaged, het heeft belangen en relaties met business management en het heeft een relatie met de gebruikers. In paragraaf 2.1 wordt de positie van het testen binnen de IT-organisatie weergegeven. Het gehanteerde schema betreft een organisatiewijze van de IT die anno 2006 breed wordt toegepast. In veel gevallen wordt de IT ontwikkeling georganiseerd via projecten. Dit betekent dat het testproces relaties heeft met onder andere projectmanagement en kwaliteitsmanagement. Beide onderdelen hebben vele verschijningsvormen. Voor dit schrijven hanteren we de volgende modellen: Projectmanagement: Prince2 Kwaliteitsmanagement: PROQA Deze beide modellen zijn in IT projecten het meest gebruikt. De relatie tot deze twee modellen wordt in paragraaf 2.2 verder uitgewerkt. 2.1 Testen in de organisatie Hoewel de IT afdeling bij iedere organisatie anders ingericht is, is binnen de meeste organisaties de volgende situatie te herkennen (NB: onderstaande figuur is een verduidelijking van de problematiek en geen alles omvattende situatieschets): Business Units/ afdelingen Business Units/ afdelingen Business Units/ afdelingen Requirements Business process design Acceptatie criteria SLA business project manager testcoördinator GAT IT - ontwikkeling IT project manager test manager testcoördinator PAT IT - beheer Teamleider Bouw testcoördinator Systeem Integratie Test Acceptatie criteria o.b.v. SLA Applicatie beheerder In bovenstaand schema wordt duidelijk in welk een dilemma de testmanager zich soms bevindt. In bovenstaande situatie is het voor de testmanager lastig zijn positie te bepalen. Wie is nu de opdrachtgever?

6 Organisatie SYSQA B.V. Pagina 6 van 27 In sommige organisaties is dit dilemma opgelost door de grenzen zeer scherp neer te zetten en ontstaat aldus een leveranciersmodel waarbij de IT afdeling diensten levert aan de business. Deze diensten worden dan vervolgens afgerekend. Hierbij kan er een situatie ontstaan dat er twee testmanagers zijn: één voor IT en één voor het accepteren namens de opdrachtgever. Andere organisaties kiezen voor een integrale projectbenadering waarbij één projectmanager eindverantwoordelijk is. Hierbij wordt de testmanager één van de teamleiders (naast bijvoorbeeld de teamleiders verantwoordelijk voor de bouw, het ontwerp en de businessimplementatie) In alle gevallen is het voor de testmanager belangrijk om een duidelijke focus te hebben op de opdracht die hij / zij heeft. 2.2 Relatie tot projectmodellen Aangezien de ontwikkeling van de meeste IT nog steeds in projectvorm plaatsvindt heeft testen een belangrijke relatie met projectmanagement. Daarnaast heeft testen een relatie met kwaliteitsmanagement aangezien door middel van het testen een inzicht wordt verschaft in enerzijds de productrisico s welke op kunnen treden bij implementatie en anderzijds in de mate waarin de applicatie aan de vastgelegde eisen, wensen en verwachtingen voldoet. Hierbij dient in acht te worden genomen dat productrisico s niet alleen op de daadwerkelijke applicatie betrekking hebben maar ook op processen, organisatie inrichting, marketing, etc. Wanneer testen wordt neergezet tegenover de meest gebruikte modellen voor projectmanagement en kwaliteitsmanagement krijgen we het volgende resultaat: Tijdspad Starting Up a project Initiating a project Executing a project Closing a project Prince2 project brief PID Stage plans Testmanagement Testproces Intake Opstarten testproces Inrichten deel test traject Coördineren test uitvoering Specificeren uitvoeren Rapportage test testcycli evaluatie testproces Decharge MTP DTP PROQA kwaliteit definitie kwaliteitsborging kwaliteitsverbetering Afronding testen

7 Organisatie SYSQA B.V. Pagina 7 van 27 De beschrijving van projectmanagement is gebaseerd op Prince2. Om het overzichtelijk te houden is ervoor gekozen niet het volledige model weer te geven in bovenstaand diagram. In het model is voor de testprocessen ook de structuur gekozen van Prince2. Hiermee wordt de consistentie tussen de modellen gewaarborgd. Het tijdspad van het testtraject start met de intake door de testmanager. Dit is niet apart beschreven in dit document, maar opgenomen in het proces Opstarten testtraject. Een tussenproduct van deze fase is een intake inschatting ten behoeve van de Project Brief. Het belangrijkste eindproduct van deze fase is het master testplan, hetgeen tegelijkertijd met het Project Initiation Document wordt opgeleverd. De stappen Intake en Opstarten testtraject zijn dus stappen die in projectmanagement termen plaatsvinden tijdens zowel de Starting Up a project fase als de Initiating a project fase. De fase Inrichten deel testtraject vindt plaats tijdens de Execution stage van het project. Ten opzichte van PROQA wordt gestart met testen vanuit de kwaliteitsdefinitie. Tijdens de intakestap van het testproces wordt geïnventariseerd welke kwaliteitsaspecten van belang zijn voor het testtraject. Tijdens de stap Opstarten testtraject worden dan tevens de kwaliteitsmaatregelen voor de Kwaliteitsborging van PROQA meegenomen en wordt daar op aangesloten. 2.3 Gebruik van deze handleiding In het diagram in paragraaf 2.2 wordt het totale testproces weergegeven. In deze handleiding richten we ons op de teststrategie. Dit betekent dat de eerste 3 stappen, zijnde Intake, Opstarten testtraject en Inrichten deel testtraject worden behandeld. Dit zijn de stappen waarin de strategievorming primair plaatsvindt. In het document zijn wel delen opgenomen die betrekking hebben op het verloop van het verdere testtraject tijdens de Execution Stage (met name in hoofdstuk 4), maar deze hebben slechts tot doel om het belang van de strategie aan te geven in het verloop van het testtraject. Daarnaast biedt dit de link naar het gehele testproces. Hoofdstuk 3 gaat met name in op de rol van de testmanager, de activiteiten die uitgevoerd dienen te worden om te komen tot een gefundeerde teststrategie voor het project en de producten die daaruit voortkomen. In hoofdstuk 4 wordt de rol van de testcoördinator toegelicht. Hierin wordt omschreven hoe de testcoördinator en de testengineer van de bovenliggende teststrategie komen tot de detail teststrategie, gebaseerd op specifieke risico s van de productkenmerken. Uit deze teststrategie volgen dan de testspecificaties. Het uitgangspunt hierbij is dat voor iedere testsoort (of een aantal samengevoegde testsoorten) een detail testplan wordt gemaakt. Als laatste zijn er enkele tips en valkuilen benoemd waar de testmanager en/of de testcoördinator rekening mee dient te houden.

8 Organisatie SYSQA B.V. Pagina 8 van 27 3 Opstarten van het testtraject (de strategie op hoofdlijnen) 3.1 Wie Dit onderdeel wordt uitgevoerd onder verantwoordelijkheid van de testmanager. 3.2 Doelstelling Vaststellen van de globale productrisico s en de beschikbaarheid van de requirements welke door middel van het testtraject moeten worden afgedekt. Daarnaast worden de testsoorten en de bijbehorende resources bepaald, en de projectrisico s vastgelegd. 3.3 Input Projectbelangen ( politieke zaken); Doelstelling van het project; Business case; Planningsrestricties (m.b.t. tijd en resources); Budgetrestricties; Ervaringen uit eerdere, soortgelijke projecten; Project-/ organisatiestandaarden; Business requirements vanuit het requirements ontwikkelproces van de business; Reeds beschikbare niet functionele requirements (zoals bijvoorbeeld business rules, kwaliteitsitems, operationele acceptatiecriteria). 3.4 Samenvatting In een zo vroeg mogelijk stadium dient de testmanager vast te stellen wat de projectrisico s, de globale productrisico s en de requirements zijn. In dit stadium kunnen de specifieke productrisico s nog niet worden gegeven aangezien de oplossingsrichting nog te abstract is. Deze productrisico s worden verkregen van de stakeholders (zie ook paragraaf De benoemde productrisico s worden vervolgens geclassificeerd. Deze classificatie wordt uitgevoerd op basis van de factoren faalkans en impact. Vervolgens wordt aan de productrisico s een kwaliteitsattribuut gehangen. Doordat hier nog wordt gesproken over een productrisico op een hoog abstractieniveau (i.c. niet op specifieke productkenmerken gericht) zijn de kwaliteitsattributen van ISO9126 te gebruiken als indicatie voor de testsoorten. Op basis van deze productrisico s en de overige gegevens kan de testmanager een opzet maken voor de overall teststrategie. Hierin wordt aangegeven welke testsoorten worden gehanteerd en hoe deze de benoemde productrisico s afdekken.

9 Organisatie SYSQA B.V. Pagina 9 van Processchema 1. Intake (vastleggen van de testopdracht) 2. Vastleggen van randvoorwaarden en omgevingsfactoren 5. Vaststellen van de stakeholders ja Is definitiestudie aanwezig? nee 6. Vaststellen gewenste oplossing 3. Vaststellen van de projectrisico s 7. Productrisico analyse m.b.v. stakeholders 4. Risicomanagement inrichten 8. Koppelen globale risico s aan kwaliteitsattributen 9. Bepalen van de totale teststrategie 10. Vaststellen definitieve strategie 11. Opstellen master testplan

10 Organisatie SYSQA B.V. Pagina 10 van Beschrijving activiteiten Intake (vastleggen van de testopdracht) Het is van belang dat de testmanager zo snel mogelijk na zijn/haar aanstelling in gesprek gaat met de opdrachtgever en de project- of programmamanager. Tijdens dit gesprek dienen de volgende items te worden vastgesteld: Het doel van de test; De afbakening van het testobject; De standaarden welke binnen de organisatie worden gebruikt. Het is belangrijk dat de verwachtingen van de opdrachtgever worden gemanaged. Tevens kan op deze wijze worden geobserveerd hoe de verhoudingen binnen de organisatie liggen (wie zijn de daadwerkelijke beslissers bijvoorbeeld). Beschrijf vervolgens de testopdracht en stem deze af met de opdrachtgever en de project- of programmamanager. Na eventuele aanpassingen wordt de definitieve opdrachtbeschrijving naar de opdrachtgever verzonden en een kopie naar de project-/programmamanager. Het beste is deze ook daadwerkelijk te laten ondertekenen door alle partijen. Dit vormt de eerste paragraaf van het master testplan. In het testproces (paragraaf 2.2.) wordt dit weergegeven als de stap Intake. Vaak is dit onderdeel van de Project Brief van de projectmanager. Hierbij dient aan de volgende twee zaken aandacht te worden besteed: 1. een detailinschatting van het proces Opstarten testtraject (de rest van dit proces); 2. een eerste globale inschatting van de kosten van het gehele testtraject Vastleggen van randvoorwaarden en omgevingsfactoren Nadat de opdracht duidelijk is, kan worden gestart met het verzamelen van informatie die van belang is voor het bepalen van de overall teststrategie. Onderstaand de items die minimaal van belang zijn voor het kunnen opstellen van een teststrategie: Al dan niet aanwezig zijn van een tijdsrestrictie. Vaak zijn er tijdsrestricties als gevolg van business wensen, wetgeving, etc. Deze zijn van grote invloed op de teststrategie; Al dan niet aanwezig zijn van budgetrestricties. Ook deze hebben invloed op de teststrategie; Consistentiebepaling tussen het projectplan, project quality plan en andere door het project reeds opgeleverde documenten enerzijds en de testopdracht anderzijds; Is er een standaard testwerkwijze aanwezig en zo ja, hoe hier binnen de organisatie en binnen het project mee wordt omgegaan; Wat zijn de testresultaten uit eerdere, vergelijkbare projecten; Systeemlandschap (architectuur) waarbinnen de oplossing dient te functioneren; Business case, business requirements, vooronderzoek. Dit zijn zaken die of al gestructureerd aanwezig zijn binnen een organisatie óf de testmanager moet er zelf naar op zoek gaan. Naast de al genoemde harde factoren waarnaar de testmanager op zoek is, kan de testmanager gedurende dit proces een indruk krijgen van de organisatie en de houding die men heeft richting testen en kwaliteit.

11 Organisatie SYSQA B.V. Pagina 11 van 27 Het is van groot belang voor een testmanager om een gevoel te krijgen van de omgeving waarin hij / zij acteert. Dit is het zogenaamde politieke krachtenveld waar ieder project (en zeker de wat grotere) mee te maken krijgt. De testmanager tracht zo een indruk te krijgen hoe belangrijk het project is voor de organisatie. Hiermee krijgt de testmanager een indicatie van de speelruimte in de tijd/geld/kwaliteit driehoek. Dit wordt vaak niet specifiek omschreven in het master testplan maar geeft wel beperkingen aan de mogelijkheden bij het opstellen van de strategie Vaststellen van de projectrisico s Definieer de projectrisico s op basis van de verzamelde informatie. Hierbij kan gebruik worden gemaakt van de werkzaamheden op risico management gebied die al door de projectmanager zijn opgestart. Vanzelfsprekend wordt hier gefocust op die risico s welke van invloed zijn op het testtraject Risicomanagement inrichten voor projectrisico s Alleen het vastleggen van risico s heeft weinig zin. Om de risico s te beheersen gedurende het testtraject, dient een proces voor het managen van deze risico s te worden ingericht (of er moet gebruik gemaakt worden van het risico management proces indien dat binnen de organisatie is ingericht). Voor meer informatie over risico management wordt verwezen naar het productmanagement van SYSQA Vaststellen van de stakeholders Maak op basis van de verzamelde informatie een overzicht van alle stakeholders die binnen dit project een rol hebben (zie ook de checklist Stakeholders). In sommige gevallen zijn deze stakeholders benoemd in de vorm van een afdeling of een bepaalde functie (bijvoorbeeld het senior management ). Dit is niet voldoende om in het testtraject mee te kunnen werken. Bepaal per stakeholder een persoon die als vertegenwoordiger kan optreden. Deze persoon dient de volmacht te hebben om besluiten te kunnen nemen in het kader van het betreffende project Vastleggen gewenste oplossingsrichting Deze stap is alleen van belang wanneer er geen definitiestudie (of een globaal ontwerp, informatie ontwerp of informatie analyse) aanwezig is. Om vervolgens toch tot een inzicht te komen wat nu eigenlijk de wens van de business en/of de gebruikers is, in termen van een informatiesysteem en welke oplossingsrichting daarvoor gekozen is, dient er een document te komen waarin een beschrijving staat van de gewenste oplossing. Een aandachtspunt hierbij is dat wanneer de ontwikkeling al begonnen is, de beschreven oplossing hier haaks op komt te staan, hetgeen tot diverse problemen kan leiden (vertraging, extra wijzigingsverzoeken, etc.) Dit is een proces waar de testmanager geen directe rol of verantwoordelijkheid heeft, maar waarvan de uitkomst wel van groot belang is voor het testtraject. De testmanager dient dan ook aan te sturen op de realisatie hiervan door de betrokkenen. De projectmanager c.q. opdrachtgever is voor dit proces verantwoordelijk Productrisico analyse m.b.v. stakeholders In de risico analyse sessie wordt vastgesteld wat de globale productrisico s zijn. Gezien het tijdstip van deze activiteit (vroeg in het proces) is het slechts mogelijk om de globale productrisico s vast te stellen. Het is niet altijd noodzakelijk om hiervoor een sessie te beleggen, ook interviews en documentstudie zijn mogelijkheden. Een sessie is echter wel aan te raden. Dit omdat door middel van een sessie vaak tot een beter inzicht in risico s kan worden gekomen als gevolg van het groepsproces. Er zijn diverse werkwijzen om een risico analyse sessie uit te voeren. Hieronder volgt een beschrijving die kan worden gevolgd.

12 Organisatie SYSQA B.V. Pagina 12 van Laat iedere stakeholder zich voorbereiden op de sessie door hem een uitnodiging te sturen met daarbij de volgende documenten: - Projectvoorstel/project brief; - Het beschikbare business ontwerp c.q. requirementsdocument of de vastgelegde oplossingsrichting (zie paragraaf 3.6.6); - Checklist met mogelijke productrisicofactoren; - Eventueel: een beschrijving van alle kwaliteitsattributen. In de uitnodiging dient expliciet en specifiek te worden beschreven wat de doelstelling is van deze sessie. Ook dient het belang te worden aangegeven: namelijk dat de teststrategie gebaseerd wordt op de input van de deelnemers. 2. Leg eerst alle risico s vast die iedere stakeholder benoemt. Vermijd hierbij de bekende valkuilen (bagatelliseren van de risico s, persoonlijke oordelen, etc.). Maak al wel onderscheid in project- en productrisico s. Focus vooral op de laatste. (De projectrisico s dienen natuurlijk wel meegenomen te worden in het risicomanagementproces, zeker als ze nog niet eerder zijn onderkend). Tijdens de sessie kun je gebruik maken van diverse werkwijzen: brown paper methode, scenario denken, workshop methode. Meer informatie hierover is verkrijgbaar bij product management van SYSQA. 3. Bepaal vervolgens per geïdentificeerd risico de impact en de faalkans. Factor Omschrijving Classificatie Waarde Faalkans De kans dat deze fout zich voor zal doen indien dit Hoog Dit zal zich zeer zeker (herhaaldelijk) voor gaan doen in productie 7 10 niet in de test wordt Medium Dit zal waarschijnlijk plaatsvinden in 4 6 ondervangen productie situatie Laag Zeer kleine kans dat de fout zich voor zal 1 3 doen Impact Het effect dat de mogelijke Hoog De bedrijfszekerheid komt in gevaar, een 7 10 fout heeft op de blokkade van de bedrijfsvoering zal bedrijfsvoering of de plaatsvinden, er wordt grote schade bedrijfszekerheid ondervonden Medium Er zal een korte blokkade zijn met schade, het systeem blijft operationeel 3 6 maar met duidelijke performance problemen, er is aanzienlijke herstelschade Laag Geen of nauwelijks waarneembare 1 2 schade en/of hinder Binnen de classificaties kan eventueel nog gewerkt worden met waardes (de laatste kolom) om een verdere verfijning aan te kunnen brengen. Dit is afhankelijk van het project en de te ontwikkelen producten. 4. Ken aan ieder risico een risicocategorie toe. Hiervoor worden de factoren impact en faalkans tegen elkaar afgezet: Faalkans Hoog Medium Laag Hoog A A B Impact Medium A B C Laag B C C Bovenstaande indeling is een indicatie. Andere indelingen kunnen worden gemaakt met daarin bijvoorbeeld meer verfijning. De classificatie geeft een indruk van de zwaarte van de gewenste test: Risicoklasse A: maximale testdekking. Dit betekent voor het detail testplan dat een groot deel van deze specifieke productrisico s in een test afgedekt dienen te worden.

13 Organisatie SYSQA B.V. Pagina 13 van 27 Risicoklasse B: Risicoklasse C: medium testdekking. Hierbij maak je een keuze voor de specifieke risico s die als cruciaal kunnen worden aangemerkt. geringe testdekking. Het is hierbij voldoende om steekproefsgewijs een aantal testcases vast te stellen Koppelen globale risico s aan kwaliteitsattributen Doordat hier wordt gewerkt met risico s op een behoorlijk hoog abstractieniveau zijn de kwaliteitsattributen van ISO9126 te gebruiken als indicatie voor de testsoorten. Allereerst dient per risico te worden vastgesteld op welk kwaliteitsattribuut het risico betrekking heeft (zie de checklist kwaliteitsattributen). Ook wordt vermeld welke risicoklasse er is gedefinieerd (zie vorige paragraaf). Deze worden vervolgens vastgelegd in een overzicht als hieronder staat. Risico s Risico klasse Kwaliteitsattribuut Hoofdattribuut Batch met betalingsopdrachten is te groot waardoor deze blijft hangen en de betalingen niet tijdig bij Interpay zijn A Middelenbeslag Efficiëntie Bepalen van de totale teststrategie Op basis van de kwaliteitsattributen en de hoofdattributen kan vervolgens worden vastgesteld welke testsoorten gebruikt kunnen worden. Per testtraject kan worden gekozen voor een uitbreiding van de testsoorten of het laten vallen van bepaalde testsoorten. Bij het bepalen van de testsoorten waarmee in het testtraject wordt gewerkt, is de testmanager afhankelijk van de wijze waarop het project is ingestoken. Wanneer bijvoorbeeld wordt gewerkt met een waterval methode, kan gekozen worden voor de testsoorten zoals omschreven in TMap Next (programmatest, systeemtest, etc.). Wanneer wordt gekozen voor een vorm van iteratief ontwikkelen zijn deze testsoorten wellicht niet bruikbaar en dienen andere testsoorten gedefinieerd te worden. Om zelf tot een vaststelling van testsoorten te komen, wordt uitgegaan van de stelling dat testen een vorm van risicomanagement is: door te testen kun je bepaalde risico s voorkomen. Feitelijk is testen dus de één van de uitvoerende takken van het risicomanagement binnen een programma of het project. Dit risicomanagement heeft betrekking op het informatiesysteem dat het onderwerp van de test is. Er zijn vele manieren om een informatiesysteem te beschrijven. Voor het doel om testsoorten vast te stellen zijn er grofweg benaderingen van belang: De procesmatige kant (informatieplanning / System Lifecycle); De productkant (de facetten van een informatiesysteem). De procesmatige kant: Een System Lifecycle bestaat uit de volgende onderdelen:

14 Organisatie SYSQA B.V. Pagina 14 van 27 Gebruik Informatie planning Ontwikkelen Accepteren & invoeren Wijzigen Exploitatie Als gevolg van het bedenken, ontwikkelen, implementeren, gebruiken en exploiteren van een informatiesysteem kunnen risico s ontstaan. Bij elk van de stappen kunnen één of meerdere testsoorten worden benoemd. De productkant: Een informatiesysteem bestaat uit verschillende facetten: hardware mensen software Informatie systeem processen data Problemen kunnen ontstaan op de diverse facetten van een informatiesysteem. Voor elk van deze facetten kunnen weer testsoorten worden benoemd. Het belangrijkste is dat de testmanager zich niet limiteert tot alleen de software, iets dat snel gebeurt wanneer met het testen wordt gefocust op de ontwikkelzijde van het project. Wanneer de testsoorten zijn vastgesteld gaat de testmanager deze koppelen aan de kwaliteitsattributen. Op basis van de risico categorie die aan een bepaald kwaliteitsattribuut hangt (zie de tabel in de vorige paragraaf) wordt vastgesteld hoeveel aandacht aan de betreffende testsoort wordt besteed. Uitgezet in een tabel geeft dat het volgende resultaat (voorbeeld): Testsoort Hoofdattribuut A B C D E F Functionaliteit Betrouwbaarheid Bruikbaarheid + ++ Efficiency + ++ Onderhoudbaarheid + + Portabiliteit + + +

15 Organisatie SYSQA B.V. Pagina 15 van 27 De plusjes geven hierbij aan hoeveel dekking wordt verkregen van de risico s door het uitvoeren van die betreffende testsoort (dit is een indicatie). Wanneer de testmanager wat dieper op de materie in wil gaan kan de indicatie worden uitgebreid met andere symbolen: Voorbeeld: I S impliciet testen in deze testsoort statisch testen in deze testsoort (op basis van documentatie een oordeel vormen over het eindproduct) Als laatste wordt de teststrategie omschreven. Per testsoort dient hierbij te worden aangegeven: - Op welk deel van het informatiesysteem deze testsoort zich richt; - Welke doelstelling deze testsoort heeft in het gehele traject; - Op welke kwaliteitsattributen deze testsoort zich focust; - Welke risico s in welke testsoort wordt afgedekt Vaststellen definitieve teststrategie Elk project heeft te maken met de zogenaamde duivelsdriehoek. Hiermee wordt bedoeld de belangrijkste factoren van een project: tijd, geld en kwaliteit. Op basis van de factor kwaliteit heeft de testmanager de teststrategie vastgesteld. De andere twee factoren zijn niet meegenomen omdat eerst vastgesteld dient te worden wat exact de requirements en de risico s zijn. Hierbij gaat de testmanager uit van de veronderstelling dat alle risico s en requirements volledig worden getest. Dit is namelijk een absolute voorwaarde om het onderling vergelijken van risico s mogelijk te maken. Ook is er een waarde toegekend aan de risico s waardoor een classificering van de risico s mogelijk is. Vervolgens dient de testmanager nu de inschattingen te maken betreffende kosten en doorlooptijd van het testtraject gebaseerd op de dekking van alle risico s. Aangezien het meestal niet mogelijk is om alle requirements en risico s volledig te testen, worden de inschattingen afgezet tegen de randvoorwaarden die m.b.t. tijd en geld vanuit het programma of project worden gesteld. Hierbij wordt door de testmanager een advies opgesteld gebaseerd op de waarde van de risico s (de risicoklasse). De testmanager dient bij de gemaakte keus aan te geven wat de gevolgen zijn op de gebieden tijd, geld en kwaliteit. Daarnaast zijn ook de projectrisico s gedefinieerd (voorbeelden: 1) een tekort aan gekwalificeerde resources, 2) een gebrekkige testomgeving). Dit zijn belangrijke items voor het definitief vaststellen van de teststrategie (zie paragraaf 3.6.3). Deze dienen dan ook te worden meegewogen door de testmanager. De keuzes worden voorgelegd aan project- of programmamanagement of zelfs aan de stuurgroep of lijnmanagement. Hierbij heeft de testmanager een adviserende rol, en kan aangeven welke risico s naar zijn / haar inzicht het makkelijkst buiten beschouwing te laten zijn Opstellen master testplan De laatste stap is het opstellen van het master testplan. Hierin wordt beschreven wat de teststrategie is en wat de consequenties zijn voor tijd en geld. Tevens wordt hierin de testorganisatie beschreven, de wijze waarop de projectrisico s in het testtraject worden gemanaged, de wijze waarop het testtraject gemanaged wordt. Het geheel is vergelijkbaar met een projectplan.

16 Organisatie SYSQA B.V. Pagina 16 van 27 Belangrijke onderwerpen die zeker in een master testplan dienen terug te komen zijn: De kwaliteitsmaatregelen gedurende het testtraject. Door QA toe te passen als activiteit op het testproces wordt de efficiency en de effectiviteit van het testtraject verhoogd; Configuratie management. Zorg dat je goed bijhoudt wat de laatste versies zijn van de diverse documenten. Met name dient te worden voorkomen dat gedurende het project, de scope van het project geleidelijk wordt aangepast en bijgesteld op verzoek van diverse stakeholders(het begrip scope creep ). Hierdoor kan namelijk de teststrategie niet meer valide blijken te zijn; Het inplannen van de evaluatie van het testproces. Op deze wijze kan verbetering in het opzetten van de teststrategie worden bereikt; De entry- en exitcriteria per testsoort. Op deze wijze kan het testtraject gecontroleerd verlopen doordat de testobjecten ten tijde van de overhandiging een minimale kwaliteit nodig hebben. 3.7 Output Vanuit dit proces worden door de testmanager de volgende producten opgeleverd: Master testplan; Planningssheet (dit kan ook een onderdeel zijn van het master testplan); Budgetteringssheet (dit kan ook een onderdeel zijn van het master testplan); Risico management sheet (dit is deels onderdeel van het master testplan; dit betreffen de projectrisico s voor het testtraject); Rapportages naar betrokken management.

17 Organisatie SYSQA B.V. Pagina 17 van 27 4 Inrichting van het deel testtraject (de detail teststrategie) 4.1 Wie Dit onderdeel wordt onder verantwoordelijkheid van de testcoördinator/teamleider van de betreffende testsoort uitgevoerd. 4.2 Doelstelling Op basis van de specifieke productrisico s vaststellen welke testtechnieken gebruikt moeten worden om een zo goed mogelijke detectie van de mogelijke fouten te kunnen uitvoeren. 4.3 Overige input Master testplan met daarin de projectrisico s, de doelstelling van het project vertaald naar een testimpact en de globale productrisico s; Doelstelling van de specifieke testsoort; Planningsrestricties; Budgetrestricties; Ervaringen uit eerdere, soortgelijke projecten; Requirements, functioneel ontwerp of technisch ontwerp. 4.4 Samenvatting Op basis van de conclusies uit het proces Opstarten testtraject (beschreven in het master testplan) wordt gestart met de verfijning van de strategie op detailniveau. Per testsoort wordt een verdere invulling gegeven aan de strategische keuzes zoals eerder gemaakt. In deze fase worden de specifieke productrisico s ook duidelijker. Er is ook meer bekend over het uiteindelijk op te leveren product.

18 Organisatie SYSQA B.V. Pagina 18 van Processchema 1. Detailintake van de aanwezige documentatie 3. Vaststellen van specifieke productrisico s (eventueel) 2. Uitvoeren van een Joint Testware Development (JTD) sessie 4. Koppelen van risico s aan requirements van het informatiesysteem (clusters) 5. Opstellen van de detail teststrategie 6. Opstellen van detail testplan testsoort 7. Opstellen van testspecificaties + draaiboek 8. Uitvoeren van de testrun 10.Bijwerken/detailleren van de testspecificaties 9. Evaluatie van de testrun 10a. Uitvoeren van een JTD sessie (eventueel) 11. Opstellen van het testverslag Input test - managementverslag

19 Organisatie SYSQA B.V. Pagina 19 van Beschrijving activiteiten Detailintake van de aanwezige documentatie In deze stap wordt vastgesteld welke documentatie aanwezig is en wat de kwaliteit van de documentatie is. De kwaliteit en/of de diepgang van deze review op de testbaarheid van de documentatie is mede afhankelijk van de testers die deze stap uitvoeren. Wanneer deze zeer ervaren zijn en veel kennis hebben van het betreffende systeem, hebben zij veelal aan een half woord genoeg, hetgeen wel risico s kan opleveren aangezien zij wellicht teveel aannames doen op basis van hun systeemkennis. Om dit risico te verkleinen moet de detailintake worden uitgevoerd met als uitgangspunt dat de testers geen kennis van het onderliggende systeem hebben (voor het uitvoeren van een detailintake zijn checklists beschikbaar op de kennisbank). Het is handig om nu al te starten met het testplan en dit gedurende de komende stappen in te vullen Uitvoeren van een Joint Testware Development (JTD) sessie (dit is een optionele stap, afhankelijk van het feit of documentatie aanwezig is) In veel gevallen is er (nog) geen of onvoldoende documentatie aanwezig wanneer de voorbereiding en de specificatie van een test start. In plaats van afwachten tot alle benodigde documentatie is opgesteld, kan het testteam pro-actief aan de slag gaan door het beleggen van een JTD sessie. Het uitgangspunt van deze sessie is niet de documentatie maar de kennis en professionaliteit van de deelnemers aan deze sessie. Wel kan de informatie die door de testmanager is verzameld (globale productrisico s en requirements) als input dienen. De doelstelling is om te komen tot globale testcases/ testscenario s die dienen als documentatie tijdens het traject. Tijdens deze sessie wordt samen met de betrokkenen vastgesteld wat de eisen zijn die aan het systeem worden gesteld. Het is feitelijk een combinatie van een requirements engineering sessie en een risico analyse. Op deze wijze kan tot een gezamenlijke beschrijving worden gekomen op basis waarvan de test kan worden opgesteld. Een dergelijke sessie dient wel gestructureerd te verlopen. De stappen van een JTD sessie zijn: Vaststellen wat de op te leveren producten van de sessie zijn. Op deze wijze weet iedereen wat de uiteindelijk te bereiken situatie is. De omschrijvingen dienen dan ook zo specifiek mogelijk te zijn; Vaststellen wie de deelnemers zijn aan de sessie. Afhankelijk van de op te leveren producten en de testsoort waar deze betrekking op hebben nodig je deelnemers uit die toegevoegde waarde hebben; Uitnodigen van de deelnemers (vermeld vooraf wat de doelstelling van de sessie is). Voorbereiden door de deelnemers. De deelnemers dienen zich voor te bereiden op basis van hun kennis van het systeem, van de werkprocessen, van de organisatie, van de ontwikkeling tijdens het project, etc. Belangrijk is dat alle deelnemers zich hebben voorbereid. Controleer dit. Bij geen voorbereiding moet de sessie worden afgezegd; Uitvoeren van de JTD sessie. Verschillende technieken zijn mogelijk (groepsdiscussie, brown paper). Zorg voor een goede vastlegging; Opleveren van de vastgestelde producten. De afgesproken producten worden opgeleverd. Belangrijk is dat de gehele groep achter het uiteindelijke product staat. Voor meer info: zie het productmanagement van SYSQA.

20 Organisatie SYSQA B.V. Pagina 20 van Vaststellen van specifieke productrisico s Wanneer de contouren van het te ontwikkelen informatiesysteem duidelijker worden (ontwerpen worden opgesteld, requirements worden definitief, JTD sessie producten zijn akkoord), kunnen de productrisico s worden vastgesteld. Deze dienen zo specifiek mogelijk te worden omschreven. Hierbij dient gefocust te worden op de doelstelling van de betreffende testsoort en de daarbij behorende globale risico s. Voor een beschrijving hoe de risico s kunnen worden verzameld zie par Koppelen van risico s aan requirements van het informatiesysteem Vervolgens kunnen de requirements/systeemeisen worden gelinkt met de benoemde risico s. Op deze wijze worden er combinaties van risico s en requirements gevormd (RRC s). Requirements Productrisico s A X X B X C X X Het koppelen van risico s en requirements tot RRC s kan tot gevolg hebben dat er requirements en/of risico s overblijven, oftewel deze kunnen niet gekoppeld worden. In principe is een requirement zonder risico een overbodig requirement (als er niets gebeurt wanneer het er niet is of wanneer het foutief is, wat voegt dit requirement dan toe?) en is een risico zonder requirement een signaal dat het requirements development proces onvoldoende is uitgevoerd. Met deze overgebleven risico s en/of requirements dienen de betreffende stakeholders opnieuw aan de slag te gaan. Dit geheel is dus een iteratief proces. Om het testtraject beter te beheersen kunnen de de RRC s geclusterd worden in logische groepen (bijvoorbeeld: op basis van overeenkomstige Kwaliteitsattributen). Voorbeeld: Productrisico s Requirements A X X X B X C X X X D X E X F X G X X H X X I X X J X X De RRC s dienen vervolgens een classificatie te krijgen op basis van de factoren impact en faalkans (zie ook paragraaf 3.6.7). Dit kan per RRC worden uitgevoerd of per cluster indien er clusters worden gebruikt. Dit is afhankelijk van de projectfactoren (zoals bijv. tijd en geld) en van het antwoord op de vraag of dit toegevoegde waarde biedt.

21 Organisatie SYSQA B.V. Pagina 21 van Opstellen van de detail teststrategie Op basis van de informatie zoals hierboven vastgesteld kan de detail-teststrategie worden vastgesteld. De doelstelling voor dit specifieke traject is al vastgesteld in het master testplan. Bij het vaststellen van de strategie dient deze als kader. Ook zijn in het master testplan de randvoorwaarden neergelegd voor de betreffende testsoorten. Beide zaken vormen input voor de detail teststrategie. Op basis van de risicoclassificatie wordt vastgesteld welke testtechnieken worden gehanteerd. De testsoort en het betreffende aandachtsgebied bepalen op deze wijze de test specificatietechnieken die gebruikt kunnen worden (wanneer bijvoorbeeld de testsoort een performance test is voor het aandachtsgebied exploitatie, dan heeft een Elementaire Vergelijkingen Test (EVT) weinig zin). Door deze informatie uit te zetten in een tabel krijg je een overzicht van de RRC s, de eventuele clusters en de te gebruiken testtechnieken. Bijvoorbeeld: Risico/requirement combinaties 1.2; 4.4; 5.2; 5.3; 6.2; 7.9; 7.11 Cluster Risico classificatie Testtechnieken Invoeren en muteren B Semantische test Berekenen A EVT Databewerking en verzending Er kan worden gevarieerd met de zwaarte van de testen door: 1. te variëren in het aantal RRC s dat wordt afgedekt door een test; 2. te variëren in de diepgang en dekking van de betreffende testspecificatietechniek (het aantal testgevallen per RRC door bijvoorbeeld de testmaat te vergroten) Opstellen van detail testplan testsoort In het detail testplan voor de betreffende testsoort wordt door de testcoördinator de strategie vastgelegd. Tevens worden hierin de overige zaken aangegeven zoals organisatie, planning, infrastructuur en overige benodigde zaken. De testmanager dient vervolgens goedkeuring te verlenen aan dit plan nadat hij / zij heeft vastgesteld dat alles in lijn is met het master testplan voor het testtraject. Er is een sjabloon voor het testplan beschikbaar op de kennisbank. De volgende paragrafen hebben geen directe relatie met het opstellen van de detail teststrategie maar zijn toegevoegd om verduidelijking te bieden over hoe met de strategie om te gaan in het vervolg en omdat verantwoording afgelegd dient te worden over de teststrategie.

22 Organisatie SYSQA B.V. Pagina 22 van Opstellen van testspecificaties + draaiboek Op basis van de vastgestelde testspecificatietechnieken worden de testsituaties en de bijbehorende scripts vastgesteld. Voor iedere RRC wordt één of meerdere testcases opgesteld. Op basis van de clusters of de RRC s afzonderlijk wordt een testdraaiboek opgesteld. Bij het opstellen van het testdraaiboek dient de testcoördinator rekening te houden met de risicoclassificatie van de RRC s of de clusters. De RRC s/clusters met de hoogste classificatie dienen als eerste te worden ingepland. Vanzelfsprekend hebben projectafhankelijkheden en/of technische afhankelijkheden hier invloed op Uitvoeren van de testrun De gespecificeerde testcases worden conform het opgestelde draaiboek uitgevoerd. Het bewaken van de voortgang en de risico afdekking kan worden gedaan door het overzicht te gebruiken RRC s per cluster (als gemaakt in par ). Doordat aan iedere combinatie één of meer testcases zijn gekoppeld, kan gedurende het traject worden bijgestuurd. Er kunnen verantwoorde keuzes worden gemaakt en de testcoördinator kan aangeven dat door bepaalde testcases weg te laten, bepaalde risico s niet getest worden. Hierop kan een klant of een stuurgroep haar keuzes baseren Evaluatie van de testrun Op basis van de resultaten wordt de testuitvoering geëvalueerd. Hierbij worden minimaal de volgende zaken meegenomen: Het aantal uitgevoerde cases en de afgedekte risico s; Het aantal gevonden issues (koppeling aan de betreffende risico s kan in een testmanagement tool worden gemaakt); Geschat percentage van het cluster dat is afgedekt; Het aantal risico s dat nog openstaat. Over het evalueren van test uitvoering is bij product management meer informatie beschikbaar Bijwerken/detailleren van de testspecificaties Op basis van de evaluatie worden de testspecificaties verder aangescherpt en gedetailleerd. Wanneer de documentatie in eerste instantie oppervlakkig is, bevat de eerste testronde slechts een deel van de RRC s. In veel projecten wordt gedurende het project de rest van de documentatie opgesteld. Wanneer dit niet het geval is kan zelfs d.m.v. reversed engineering een JTD sessie worden opgezet zodat de specificaties van het systeem steeds duidelijker worden. Op basis van de JTD sessie worden een aantal testrondes doorlopen met de volgende doelstellingen: Scherper definiëren van de testspecificaties; Het vinden van meer risico s; Het koppelen van meer risico s aan de testspecificaties. Afhankelijk van de projectgrenzen in termen van tijd, geld en kwaliteit kunnen deze iteraties worden herhaald.

23 Organisatie SYSQA B.V. Pagina 23 van Opstellen van het testverslag Uiteindelijk wordt een eindverslag van de testsoort opgeleverd waarin staat vermeld of het object voldoet aan de eisen van de betreffende testsoort. Dit verslag vormt de input voor het totale testverslag van de testmanager, voor het gehele testtraject. De items die genoemd zijn in paragraaf dienen hier minimaal in terug te komen. 4.7 Output Vanuit dit proces worden door de testcoördinator/teamleider (of onder zijn verantwoording) de volgende producten opgeleverd: Het detail testplan inclusief de testtrategie voor de betreffende testsoort; Het testdraaiboek. Dit vormt de input voor het testmanagementverslag.

24 Organisatie SYSQA B.V. Pagina 24 van 27 5 Tips & valkuilen Handige tips: Maak gebruik van de SYSQA kennisbank wanneer er bij de opdrachtgever geen meetgegevens voorhanden zijn; Zorg er als testmanager voor dat je niet te veel op de stoel van de testcoördinator gaat zitten. In veel organisaties is de terminologie voor de functies van testmanager en testcoördinator niet altijd even duidelijk. Het is handig om zo snel mogelijk vast te leggen wat eenieders verantwoordelijkheden zijn binnen het project of de organisatie wanneer dit nog niet voorhanden is; Maak als je een inschatting afgeeft voor doorlooptijd of budget altijd duidelijk wat de uitgangspunten zijn van deze inschattingen én geef expliciet aan dat bij aanpassingen van deze uitgangspunten een nieuwe inschatting komt. In Prince 2 termen: dit soort aanpassingen vallen niet binnen de tolerantiegrenzen van het projectmanagement; Communiceer je activiteiten. In deze handleiding wordt een groot aantal stappen beschreven, staan heel veel tabellen en wordt gesproken over zaken waar een niet tester geen kaas van heeft gegeten. Zorg dat je de stakeholders (bijv. projectmanager, opdrachtgever) op de hoogte houdt van de stappen die je allemaal moet nemen om tot een goede teststrategie te komen. Tracht hierbij vakjargon te vermijden en het belang van die afzonderlijke stappen te benadrukken. Valkuilen: Voorkom een schijnzekerheid door een te grote mate van detaillering (bijvoorbeeld: risico nr 2 heeft een impact van 6,2 en een waarschijnlijkheid van 4,5. Uit het bovenstaande blijkt dat voor testsoort A 19,67% van de beschikbare tijd dient te worden ingepland ). Hierdoor ontstaat discussie over de randzaken en details die niets toevoegt aan de strategie; Vertrouw niet alles wat de business of opdrachtgever zeggen. Het bekende adagium luidt: vertrouwen is goed, controleren is beter. Veel business managers en/of gebruikers hebben een bepaald beeld van het project of het te ontwikkelen product dat niet geheel strookt met de werkelijkheid. De testmanager/testcoördinator dient altijd te verifiëren of de beelden die zijn geschetst in ieder geval in de buurt van de werkelijke situatie komen; Meegaan in de projectdoelen (ook wel genoemd: zorg dat je pragmatisch blijft). Meestal een argumentatie die vanuit de projectmanager komt. De goede daargelaten, heeft de gemiddelde projectmanager slechts twee van de drie pijlers in zijn hoofd zitten: tijd en geld. De factor kwaliteit is bijna altijd onderbelicht. Wanneer je als testmanager hier te veel in meegaat kun je je toegevoegde waarde niet bewijzen. Maak de factor kwaliteit tot jouw verantwoordelijkheid. Je kunt niet garanderen dat er kwaliteit gebouwd wordt, maar je kunt wel zorgen dat de risico s van een kwalitatief slecht systeem inzichtelijk zijn voor de stakeholders van het project; Dogmatisch vasthouden aan je strategie. Ondanks datgene dat in het vorige punt is vermeld moet de testmanager wél blijven nadenken! Vast blijven houden aan een strategie omdat die nu éénmaal is gekozen, is je eigen vertrek als testmanager bespoedigen. De theorie is een beschrijving die van toepassing is op de ideale situatie of ideale organisatie. Deze bestaat niet zoals we allemaal weten. Afhankelijk van de organisatie en de doelen van het project pas je de theorie toe. Als je te vasthoudend bent word je al snel drammerig, wat je functioneren in het team niet ten goede komt;

25 Organisatie SYSQA B.V. Pagina 25 van 27 Te positief/negatief toegepast verwachtingsmanagement. Door de klant een te rooskleurig beeld te schetsen kan de uiteindelijke oplevering tegenvallen. Soms zie je dat dit dan bij testmanagers de andere kant opslaat: men geeft een zeer negatief beeld. Op deze wijze denkt de testmanager dan de eigen rol op te blazen. Dit werkt ook contraproductief aangezien de klant achteraf zich wellicht af gaat vragen of al die testinspanning wel nodig was en neemt hij je bij een volgend traject niet meer serieus. Geef dus een reëel beeld van de te verwachten risico s; Zorg dat je objectiviteit gewaarborgd blijft. Met name omdat de testmanager degene is die een oordeel velt over de risico s bij implementatie is het van groot belang om de objectiviteit te waarborgen. Dit is niet alleen een procesaangelegenheid (aan wie rapporteert de testmanager) maar ook een werkwijze die de testmanager uitstraalt. Deze lijst is een levend document en kan door eenieder worden aangevuld en/of aangepast. Het productmanagement van SYSQA is de beheerder van deze lijst. De meest recente versie kan daar ook worden verkregen.

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

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

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

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

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

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

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

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

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

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

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

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

Sjabloon detailtestplan. <<Organisatie>>

Sjabloon detailtestplan. <<Organisatie>> Sjabloon detailtestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 18 Inhoudsopgave 1 Managementsamenvatting...

Nadere informatie

De brug tussen PRINCE2 en TMap

De brug tussen PRINCE2 en TMap De brug tussen PRINCE2 en TMap Rob Baarda Testnet, Nieuwegein 9 juni 2004 Sogeti Nederland B.V. Pagina 1 Agenda PRINCE2 kort TMap in PRINCE2 Tips Globale typering PRINCE2 Onder besturing van Board Op basis

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

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

Kwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V.

Kwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V. Kwaliteitskosten onderzoek Aanpak 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 KWALITEITSKOSTEN...

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

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

Anko Tijman Een agile teststrategie op basis van MoSCoW

Anko Tijman Een agile teststrategie op basis van MoSCoW Titel, samenvatting en biografie Anko Tijman Een agile teststrategie op basis van MoSCoW Samenvatting: Deze presentatie behandelt de toepassing van de teststrategie vanuit een agile perspectief: welke

Nadere informatie

Managing Quality and Business Risks in Programmes. Mario van Os

Managing Quality and Business Risks in Programmes. Mario van Os Managing Quality and Business Risks in Programmes Mario van Os Mario van Os Mario van Os Programma Kwaliteitsmanager Email: mario@mvanos.nl Afgestudeerd TUE Wiskunde & Informatica 1986 gestart bij Interprogram

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

Workshop verkrijgen requirements. Draaiboek requirementsontwikkeling sessie. SYSQA B.V. Almere

Workshop verkrijgen requirements. Draaiboek requirementsontwikkeling sessie. SYSQA B.V. Almere Workshop verkrijgen requirements Draaiboek requirementsontwikkeling SYSQA B.V. Almere Organisatie SYSQA B.V. Pagina 2 van 6 Titel Workshop verkrijgen requirements Versie 1.1 Onderwerp Datum 16-03-2011

Nadere 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

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

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

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

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

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

Business Case. <<Naam project>>

Business Case. <<Naam project>> Business Case SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Pagina 2 van 8 Inhoudsopgave 1 Inleiding... 1.1 Doel van dit document...

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

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

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

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

Nadere informatie

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

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

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

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

Interactieve Discussieavond. Testen en PRINCE2. www.testnet.org. 14-09-2004 TestNet interactieve discussieavond Testen en Prince2 1

Interactieve Discussieavond. Testen en PRINCE2. www.testnet.org. 14-09-2004 TestNet interactieve discussieavond Testen en Prince2 1 Interactieve Discussieavond Testen en PRINCE2 14-09-2004 TestNet interactieve discussieavond Testen en Prince2 1 Agenda Korte introductie PRINCE2 (Rik Marselis, LogicaCMG) Intro Hot Issues PRINCE2 (Rob

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

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

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

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International Succes = x Visie x Draagvlak 2 Case: Implementatie Requirements Lifecycle management bij Rabobank International dinsdag 3 oktober 2006 Spider Congres Agenda Inventarisatie SPI-knelpunten Implementatie

Nadere informatie

Examen TMPA Test Management Approach (TMap) Professional Advanced

Examen TMPA Test Management Approach (TMap) Professional Advanced Examen TMPA Test Management Approach (TMap) Professional Advanced Publicatiedatum Startdatum 6 juni 2003 1 mei 2003 Doelgroep De module is bestemd voor (beginnende) professionele testers met een ½ tot

Nadere 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

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

1Modelexamen 1. Modelexamen 1

1Modelexamen 1. Modelexamen 1 1Modelexamen 1 Het examen PRINCE2 Foundation wordt in Nederland afgenomen door Stichting EXIN. Om u voor te bereiden op het examen is er een representatief modelexamen bijgevoegd. Het examen bestaat uit

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

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

Digikoppeling adapter

Digikoppeling adapter Digikoppeling adapter Versie 1.0 Datum 02/06/2014 Status Definitief Van toepassing op Digikoppeling versies: 1.0, 1.1, 2.0, 3.0 Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555

Nadere informatie

Prince2 audit. Kwaliteitsmaatregel met rendement

Prince2 audit. Kwaliteitsmaatregel met rendement Prince2 audit Kwaliteitsmaatregel met rendement Niek Pluijmert Dga INQA (samen met Hans) Project- en kwaliteitmanagement Sedert 1979 in ICT Bestuurslid Spider Bestuurslid KvK Midden Nederland TU Delft

Nadere informatie

Testrisicoanalyse. Introductie

Testrisicoanalyse. Introductie 7 Testrisicoanalyse 7.1 Introductie Veel testtrajecten zijn tegenwoordig gebaseerd op risico s. Bij risicogebaseerd testen (RBT) bepaalt het risico dat de organisatie loopt als het systeem in gebruik wordt

Nadere informatie

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol. Datum: dd-mm-jj

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol. Datum: dd-mm-jj BUSINESS CASE: Versie Naam opdrachtgever Naam opsteller Datum: dd-mm-jj Voor akkoord: Datum: LET OP: De bedragen in deze business case zijn schattingen op grond van de nu beschikbare kennis en feiten.

Nadere informatie

EISEN AAN TESTPLANNEN

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

Nadere informatie

Projectmanagement De rol van een stuurgroep

Projectmanagement De rol van een stuurgroep Projectmanagement De rol van een stuurgroep Inleiding Projecten worden veelal gekenmerkt door een relatief standaard projectstructuur van een stuurgroep, projectgroep en enkele werkgroepen. De stuurgroep

Nadere informatie

Ontwikkelen & Beheren van testomgevingen is ook een vak!

Ontwikkelen & Beheren van testomgevingen is ook een vak! Patrick Scholte & Albert Dennis Janssen Anneveld Ontwikkelen & Beheren van testomgevingen is ook een vak! Agenda Even voorstellen De Rabobank Problemen met omgevingen Oorzaken Aanpak Verdere ontwikkelingen

Nadere informatie

PROJECT: ONTWIKKELOMGEVINGEN VIRTUELE TESTOMGEVINGEN

PROJECT: ONTWIKKELOMGEVINGEN VIRTUELE TESTOMGEVINGEN PROJECT: ONTWIKKELOMGEVINGEN VIRTUELE TESTOMGEVINGEN ( Project Initiation Document ) Datum voltooid: 20/03/2013 Auteur: Kevin Sanders Studentnummer: 2148839 Versie: 0.1 Status: Concept Documenthistorie

Nadere informatie

Test Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden

Test Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden Test Process Improvement Benchmark SPIder Conferentie 23 september Wim van Uden Agenda Korte inleiding TPI -model TPI benchmark overall Vergelijking branches DO s& DON Ts Test Process Improvement Optimaliseren

Nadere 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

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

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test

Nadere informatie

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Agile systeemontwikkeling Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Terminologie... 4 3. Uitgangspunten...

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

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

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 en BASEL II. Dennis Janssen. Agenda. Wat is BASEL II? Testen van BASEL II op hoofdlijnen

Testen en BASEL II. Dennis Janssen. Agenda. Wat is BASEL II? Testen van BASEL II op hoofdlijnen Testen en BASEL II Dennis Janssen Test Research Centre LogicaCMG 1 Agenda Wat is BASEL II? Testen van BASEL II op hoofdlijnen BASEL II als hulpmiddel om positie testen te versterken Samenvatting 2 1 Basel

Nadere informatie

Webtesten onder schaarste

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

Nadere informatie

Bekend zijn met de visie en inzet van procesmanagement in de eigen organisatie.

Bekend zijn met de visie en inzet van procesmanagement in de eigen organisatie. en werkwijze BPM awareness Inzicht in de toepassing van BPM op strategisch niveau in het algemeen en binnen de eigen organisatie. Kennismaken met BPM vanuit een strategisch perspectief Nut en toegevoegde

Nadere informatie

6. Project management

6. Project management 6. Project management Studentenversie Inleiding 1. Het proces van project management 2. Risico management "Project management gaat over het stellen van duidelijke doelen en het managen van tijd, materiaal,

Nadere informatie

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

Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Requirements en testen 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

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

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

ARE methodiek Het ontwikkelen van Informatie Elementen

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

Nadere informatie

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

Opdrachtgever in het testproces. Testnet Voorjaarsevenement 2011 Olaf Agterbosch

Opdrachtgever in het testproces. Testnet Voorjaarsevenement 2011 Olaf Agterbosch Opdrachtgever in het testproces Testnet Voorjaarsevenement 2011 Olaf Agterbosch Agenda Even voorstellen; De onderschatte rol van opdrachtgevers bij testen; Aansturen van testen in (out)sourcingsituaties;

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

ORGANISATORISCHE IMPLENTATIE BEST VALUE

ORGANISATORISCHE IMPLENTATIE BEST VALUE ORGANISATORISCHE IMPLENTATIE BEST VALUE EEN ONDERZOEK NAAR DE IMPLEMENTATIE VAN BEST VALUE BINNEN EEN SYSTEMS ENGINEERING OMGEVING STEPHANIE SAMSON BEST VALUE KENNIS SESSIE WESTRAVEN 17 JUNI 09.00 12.00

Nadere informatie

Opleidingsaanbod: testopleidingen.com

Opleidingsaanbod: testopleidingen.com (Business, (IT) Projectmanagement, Quality Management, etc.) TMap NEXT Test Engineer(NL/ENG) Examentraining TMap NEXT Test Engineer E-learning TMap NEXT Test Engineer Certificering TMap NEXT Test Engineer

Nadere informatie

Het BiSL-model. Een whitepaper van The Lifecycle Company

Het BiSL-model. Een whitepaper van The Lifecycle Company Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte

Nadere 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

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

Doen of laten? Een dag zonder risico s is een dag niet geleefd

Doen of laten? Een dag zonder risico s is een dag niet geleefd Doen of laten? Een dag zonder risico s is een dag niet geleefd Wie, wat en hoe Eric Lopes Cardozo & Rik Jan van Hulst sturen naar succes Doel Delen van inzichten voor praktisch operationeel risico management

Nadere informatie

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. ISO 9000:2000 en ISO 9001:2000 Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

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

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

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

Nadere informatie

Kwaliteit in Agile: een gegeven?

Kwaliteit in Agile: een gegeven? QA in Agile: waste? Kwaliteit in Agile: een gegeven? Een praktijkvoorbeeld Arno Balemans senior Quality Assurance consultant Bussum, 29 september 2015 Kwaliteit in Agile 2015 2 Werkzaamheden In mijn opdrachten:

Nadere informatie

Problematiek in projecten

Problematiek in projecten Problematiek in projecten Het project bouwt andere producten dan afgesproken Het project valt duurder uit dan begroot Het project loopt langer dan gepland Het product sluit niet aan bij de werksituatie

Nadere informatie

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

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

Nadere informatie

Product Risico Analyse

Product Risico Analyse Product Risico Analyse Jurian van de Laar TestNet Avond 9 oktober 2013 www.improveqs.nl (info@improveqs.nl) Versie 2.0 1 Herkenbaar? In ons testproces wordt product risico analyse toegepast Wij gebruiken

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

Bijlage A Governance

Bijlage A Governance Bijlage A Governance WFO-Suite en Diensten Opdrachtgever: Opdrachtgever/Centrum voor Facilitaire Dienstverlening (B/CFD) Inkoop Uitvoeringscentrum (IUC) Opdrachtnemer : Datum: Versie: publicatieversie

Nadere informatie

Test rapportage Waarom eigenlijk?

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

Nadere informatie

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

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

Risk Based Testing. TestNet Voorjaarsbijeenkomst. Johan Vink. A reality check

Risk Based Testing. TestNet Voorjaarsbijeenkomst. Johan Vink. A reality check Risk Based Testing A reality check TestNet Voorjaarsbijeenkomst Johan Vink Even voorstellen - Johan Vink - 42 jaar testervaring - 15 jaar betaald - Test competence leader Risk Based Testing, a reality

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

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

TMap NEXT Test Engineer

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

Nadere informatie

Review op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging

Review op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging Review op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging mr. drs. E.P.J. de Boer Rotterdam, Aanleiding en opzet van de review In opdracht van de GR Jeugdhulp Rijnmond is

Nadere informatie