Handleiding. Teststrategie

Handleiding Teststrategie

SYSQA B.V.

Datum Status Opgesteld door

: 12-01-2009 : Definitief : Nico van Mourik

Organisatie Titel 1Onderwerp

SYSQA B.V. Teststrategie Handleiding

Pagina Versie Datum

2 van 27 1.03 12-01-2009

Inhoudsopgave 1

INLEIDING................................................................................................................................. 4 1.1 1.2

2

TESTEN EN DE REST VAN DE WERELD ............................................................................... 5 2.1 2.2 2.3

3

ALGEMEEN.......................................................................................................................... 4 VERSIEBEHEER ................................................................................................................... 4 TESTEN IN DE ORGANISATIE ................................................................................................. 5 RELATIE TOT PROJECTMODELLEN ........................................................................................ 6 GEBRUIK VAN DEZE HANDLEIDING ........................................................................................ 7

OPSTARTEN VAN HET TESTTRAJECT (DE STRATEGIE OP HOOFDLIJNEN) .................. 8 3.1 WIE .................................................................................................................................... 8 3.2 DOELSTELLING.................................................................................................................... 8 3.3 INPUT ................................................................................................................................. 8 3.4 SAMENVATTING ................................................................................................................... 8 3.5 PROCESSCHEMA ................................................................................................................. 9 3.6 BESCHRIJVING ACTIVITEITEN ............................................................................................. 10 3.6.1 Intake (vastleggen van de testopdracht) ..................................................................... 10 3.6.2 Vastleggen randvoorwaarden en omgevingsfactoren ................................................. 10 3.6.3 Bepalen van de projectrisico’s..................................................................................... 11 3.6.4 Inrichten risicomanagement ........................................................................................ 11 3.6.5 Vaststellen van de stakeholders.................................................................................. 11 3.6.6 Vastleggen van de gewenste oplossingsrichting......................................................... 11 3.6.7 Product risico analyse m.b.v. de stakeholders ............................................................ 11 3.6.8 Risico´s koppelen aan een kwaliteitsattribuut. ............................................................ 13 3.6.9 De totale teststrategie ................................................................................................. 13 3.6.10 Definitieve teststrategie ............................................................................................... 15 3.6.11 Opstellen master testplan............................................................................................ 15 3.7 OUTPUT ............................................................................................................................ 16

4

INRICHTING VAN HET DEEL TESTTRAJECT (DE DETAIL TESTSTRATEGIE)................. 17 4.1 WIE .................................................................................................................................. 17 4.2 DOELSTELLING.................................................................................................................. 17 4.3 OVERIGE INPUT ................................................................................................................. 17 4.4 SAMENVATTING ................................................................................................................. 17 4.5 PROCESSCHEMA ............................................................................................................... 18 4.6 BESCHRIJVING ACTIVITEITEN ............................................................................................. 19 4.6.1 Detailintake aanwezige documentatie......................................................................... 19 4.6.2 Uitvoeren van een Joint Testware Development (JTD) sessie ................................... 19 4.6.3 Vaststellen specifieke productrisico’s.......................................................................... 20 4.6.4 Koppelen van risico’s en requirements ....................................................................... 20 4.6.5 Het opstellen van de detail teststrategie ..................................................................... 21 4.6.6 Het opstellen van het detail testplan testsoort............................................................. 21 4.6.7 Het opstellen van de testspecificaties en het testdraaiboek........................................ 22 4.6.8 Uitvoeren van testrun .................................................................................................. 22 4.6.9 Evaluatie van de testrun.............................................................................................. 22 4.6.10 Bijwerken/detailleren van de testspecificaties ............................................................. 22 4.6.11 Opstellen van een testverslag ..................................................................................... 23 4.7 OUTPUT ............................................................................................................................ 23

Almere © 2006/2007

Test, beheerst en verbetert ICT



Pagina Versie Datum

3 van 27 1.03 12-01-2009

5

TIPS & VALKUILEN................................................................................................................ 24

6

LITERATUURVERWIJZINGEN .............................................................................................. 26

7

BIJLAGEN............................................................................................................................... 27 7.1 7.2 7.3

SJABLONEN. ..................................................................................................................... 27 CHECKLISTS. .................................................................................................................... 27 OVERIGE INFORMATIE ....................................................................................................... 27

Almere © 2006/2007




Pagina Versie Datum

4 van 27 1.03 12-01-2009

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

Status Concept Concept

Datum 04-07-2006 07-09-2006

Auteur Expertisegroep Expertisegroep

0.3

Concept

10-10-2006

Expertisegroep

0.4 0.5 0.6 0.9 0.91 0.92 0.93 0.94 0.95 1.0 1.01 1.02 1.03

Concept Concept Concept Concept Concept Concept Concept Concept Concept Definitief Definitief Concept Definitief

06-11-2006 07-11-2006 16-11-2006 01-12-2006 26-01-2007 27-02-2007 04-03-2007 08-03-2007 06-04-2007 05-10-2007 27-12-2007 12-12-2008 12-01-2009

Expertisegroep Expertisegroep Expertisegroep Expertisegroep Expertisegroep Expertisegroep Expertisegroep Expertisegroep Expertisegroep Expertisegroep Expertisegroep SYSQA SYSQA

Almere © 2006/2007

Opmerkingen Eerste concepten Aanpassingen n.a.v. samenvoegen diverse stukken van leden van de expertisegroep Teststrategie. Aanpassingen n.a.v. review en opmerkingen van leden expertisegroep, inpassen in template SYSQA Aanpassingen na review Toegevoegd hoofdstuk 2. Document voor interne review door de expertisegroep leden. Document aangeboden aan de Review Board van SYSQA BV Eerste verwerking van de review punten Verdere verwerking review punten Verdere verwerking review punten Verwerking review punten na bespreking expertise groep Aanpassingen na review gesprek met JJ Cannegieter Finale aanpassingen obv discussie over reviewpunten Enkele spellingsfouten verwijderd Verwijzingen van TMap veranderd naar TMap Next Aanpassingen gemaakt na de review.




Pagina Versie Datum

5 van 27 1.03 12-01-2009

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

testcoördinator GAT

project manager business

IT - ontwikkeling

test manager IT project manager

Teamleider Bouw

IT - beheer testcoördinator PAT

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?

Almere © 2006/2007




Pagina Versie Datum

6 van 27 1.03 12-01-2009

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

Prince2

Starting Up a project

Initiating a project

project brief

Executing a project

PID

Closing a project

Stage plans

Opstarten testproces

PROQA

MTP

Coördineren test uitvoering

Inrichten deel test traject

Specificeren test

uitvoeren testcycli

Rapportage

evaluatie testproces

Decharge

Intake

Testproces

Testmanagement

DTP

kwaliteitsborging kwaliteit definitie

kwaliteitsverbetering

Afronding

testen

Almere © 2006/2007




Pagina Versie Datum

7 van 27 1.03 12-01-2009

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.

Almere © 2006/2007




Pagina Versie Datum

8 van 27 1.03 12-01-2009

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

Almere © 2006/2007




3.5

Pagina Versie Datum

9 van 27 1.03 12-01-2009

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

4. Risicomanagement inrichten

7. Productrisico analyse m.b.v. stakeholders

8. Koppelen globale risico’s aan kwaliteitsattributen

9. Bepalen van de totale teststrategie

10. Vaststellen definitieve strategie

11. Opstellen master testplan

Almere © 2006/2007




3.6

Pagina Versie Datum

10 van 27 1.03 12-01-2009

Beschrijving activiteiten

3.6.1 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. 3.6.2 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.

Almere © 2006/2007




Pagina Versie Datum

11 van 27 1.03 12-01-2009

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. 3.6.3 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. 3.6.4 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. 3.6.5 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. 3.6.6 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. 3.6.7 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.

Almere © 2006/2007




Pagina Versie Datum

12 van 27 1.03 12-01-2009

1. 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 projecten 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 Faalkans

Impact

Omschrijving De kans dat deze fout zich voor zal doen indien dit niet in de test wordt ondervangen

Het effect dat de mogelijke fout heeft op de bedrijfsvoering of de bedrijfszekerheid

Classificatie Hoog Dit zal zich zeer zeker (herhaaldelijk) voor gaan doen in productie Medium Dit zal waarschijnlijk plaatsvinden in productie situatie Laag Zeer kleine kans dat de fout zich voor zal doen Hoog De bedrijfszekerheid komt in gevaar, een blokkade van de bedrijfsvoering zal plaatsvinden, er wordt grote schade ondervonden Medium Er zal een korte blokkade zijn met schade, het systeem blijft operationeel maar met duidelijke performance problemen, er is aanzienlijke herstelschade Laag Geen of nauwelijks waarneembare schade en/of hinder

Waarde 7 – 10 4–6 1–3 7 – 10

3–6

1–2

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:

Impact

Faalkans Hoog

Medium

Laag

Hoog

A

A

B

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. Almere © 2006/2007




Risicoklasse B:

Risicoklasse C:

Pagina Versie Datum

13 van 27 1.03 12-01-2009

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.

3.6.8 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

Batch met betalingsopdrachten is te groot waardoor deze blijft hangen en de betalingen niet tijdig bij Interpay zijn

A

Kwaliteitsattribuut

Hoofdattribuut

Middelenbeslag

Efficiëntie

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

Almere © 2006/2007




Pagina Versie Datum

14 van 27 1.03 12-01-2009

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

software

data processen 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):

Hoofdattribuut Functionaliteit Betrouwbaarheid Bruikbaarheid Efficiency Onderhoudbaarheid Portabiliteit

Almere © 2006/2007

Testsoort A B C + ++ + + +

D

E +

+

++ ++

+ +

+ +

F

+

++ +




Pagina Versie Datum

15 van 27 1.03 12-01-2009

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 impliciet testen in deze testsoort S 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. 3.6.10 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. 3.6.11 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.

Almere © 2006/2007




Pagina Versie Datum

16 van 27 1.03 12-01-2009

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.

Almere © 2006/2007




Pagina Versie Datum

17 van 27 1.03 12-01-2009

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.

Almere © 2006/2007




4.5

Pagina Versie Datum

18 van 27 1.03 12-01-2009

Processchema 1. Detailintake van de aanwezige documentatie

(eventueel) 2. Uitvoeren van een Joint Testware Development (JTD) sessie

3. Vaststellen van specifieke productrisico’s

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

(eventueel)

10a. Uitvoeren van een JTD sessie

11. Opstellen van het testverslag

Input test managementverslag

Almere © 2006/2007




4.6

Pagina Versie Datum

19 van 27 1.03 12-01-2009

Beschrijving activiteiten

4.6.1 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. 4.6.2 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. Almere © 2006/2007




Pagina Versie Datum

20 van 27 1.03 12-01-2009

4.6.3 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. 3.6.7. 4.6.4 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). Productrisico’s 1

2

X X

X

3

4

X

X

Requirements A B C

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

1

2

A B C D E F G H I J

X X

X

3

4

5

6

7

8

9

10

11

12

13

X X

X

X X X

X X

X X

X X

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

Almere © 2006/2007




Pagina Versie Datum

21 van 27 1.03 12-01-2009

4.6.5 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 Cluster combinaties 1.2; 4.4; 5.2; 5.3; 6.2; Invoeren en muteren 7.9; 7.11 Berekenen Databewerking en verzending

Risico classificatie B

Testtechnieken

A

EVT

Semantische test

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). 4.6.6 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.

Almere © 2006/2007




Pagina Versie Datum

22 van 27 1.03 12-01-2009

4.6.7 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. 4.6.8 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. 4.6.4). 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. 4.6.9 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. 4.6.10 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.

Almere © 2006/2007




Pagina Versie Datum

23 van 27 1.03 12-01-2009

4.6.11 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 4.6.9 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.

Almere © 2006/2007




Pagina Versie Datum

24 van 27 1.03 12-01-2009

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;

Almere © 2006/2007



•

•


Pagina Versie Datum

25 van 27 1.03 12-01-2009

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.

Almere © 2006/2007




Pagina Versie Datum

26 van 27 1.03 12-01-2009

6 Literatuurverwijzingen TMap Next voor resultaat gericht testen; T.Koomen, L. vd Aalst, B. Broekman, M. Vroon; Uitgeverij Tutein Nolthenius, © 2006, Sogeti Nederland ISBN: (10) 90-72194-79-4 (13) 9789072194799 Succesvol testmanagement: een integrale aanpak; Ir. Bob van der Burgt & drs. Iris Pinkster, uitgeverij tenHagenStam; 2003;ISBN 90-440-05554-5 James Bach on Risk based testing; James Bach; STQE magazine, editie November/December 1999 Risk based testing; presentatie door Hans Schaefer; 2004 Practical Risk Based testing, Product Risk Management: the PRISMA method; E.P.W.M van Veenendaal; whitepaper Improve Quality Services; june 2006 Kwaliteitszorg in ICT-projecten – de PROQA methode; Jan Jaap Cannegieter; uitgeverij tenHagenStam; ISBN 9044003690 Prince2; 3rd edition Crown copyright 2002; Office of Government Commerce (OGC); ISBN 0-11-330891-4 PROQA, Kwaliteitszorg in ICT-projecten, Jan Jaap Cannegieter, ISBN 9044003690

Almere © 2006/2007




Pagina Versie Datum

27 van 27 1.03 12-01-2009

7 Bijlagen 7.1 1. 2. 3. 4. 5.

Sjabloon master testplan; Sjabloon detail testplan; Sjabloon uitnodiging risico analyse sessie; Sjabloon uitnodiging + agenda JTD sessie; Sjabloon risico management bewaking.

7.2 1. 2. 3. 4. 5. 6. 7. 8.

Sjablonen.

Checklists.

Checklist product risico’s; Checklist project risico’s; Checklist review testbaarheid; Checklist JTD sessie; Checklist kwaliteitsattributen; Checklist stakeholders; Checklist intake project; Checklist testomgeving.

7.3

Overige informatie

1. Toelichting JTD sessie; 2. TMap test specificatietechnieken; 3. Toelichting ISO 9126.

Almere © 2006/2007


Handleiding. Teststrategie

Recommend Documents