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.