Praktijkgerichte aanpak voor End to End (E2E) testen Gerard Numan
[email protected] © Polteq 2014
“E2E” wil zeggen: End to End, van het ene uiterste einde naar het andere einde. E2E-processen lopen over de complete technische infrastructuur (de systeemketen) heen. Dit kunnen werkprocessen zijn van gebruikersafdelingen of beheerders, maar ook processen die door klanten worden uitgevoerd of processen waarbij andere organisaties informatie verkrijgen. Een E2E-test richt zich op de samenhang tussen deze E2E-processen en de systeemketen. De E2E-processen en de systeemketen samen worden hier de E2E-keten genoemd.
Elektronisch groeiboek Deze PDF maakt onderdeel uit van een praktijkgerichte aanpak voor E2E (End to End) testen dat in de vorm van een elektronisch groeiboek gepubliceerd wordt op de website van Polteq. Als alle delen zijn gepubliceerd, komt dit e-boek in zijn geheel beschikbaar op www.polteq.com. In deel 1, 2, 3, 5, 6, 7 en 8 zijn de volgende onderwerpen aan bod gekomen:
Voorwoord ∞ Inleiding ∞ Samenvatting ∞ Belang van E2E-testen ∞ Glossary, Literatuurlijst en definities uit de literatuur ∞ E2E-inventarisatie (techniek om E2E-processen te onderzoeken ten behoeve van E2E-testen) ∞ E2E-teststrategie (techniek om E2E-risico’s vast te stellen) ∞ Lijst en checklist met veel voorkomende E2E-risico’s ∞ E2E-testplanning (techniek om E2E-testen te plannen) ∞ E2E-testontwerp ∞ E2E-testorganisatie ∞ E2E-testinfrastructuur ∞
U kunt op een van bovenstaande onderwerpen (gemarkeerd met een ∞) klikken om naar het betreffende hoofdstuk (in een aparte PDF) te gaan. Deze editie (deel 9) gaat over het onderwerp:
E2E-Faseringsmodel
Interactief Draag bij aan dit elektronisch groeiboek met aanvullingen en voorbeelden. Maar ook tegenvoorbeelden, debat en correcties zijn welkom. Bijdragen kan op de volgende manieren: 1. Door middel van reacties op de weblogs ∞ 2. Door middel van een mail naar Gerard Numan ∞ Uw bijdrage wordt dan meegenomen in het groeiboek (met vermelding van naam). Het volgende deel (deel 10) volgt nog:
Checklists en voorbeelden E2E-testen
De inhoud van het boek mag worden gebruikt mits voorzien van een duidelijke bronvermelding.
End to End testen
© 2014
2
Inhoudsopgave Elektronisch groeiboek2 1. Inleiding: E2E testen4 2. E2E-testen van begin tot einde5 3. Planning6 3.1 Plaatsbepaling in de organisatie
7
3.2 Definitie van de E2E-test in het project
8
3.4 Initiatie van de E2E-test
10
3.5 Bepalen testbasis
11
3.6 Bepalen teststrategie*
14
3.7 Planning
15
4. Beheer20 5. Analyse en Ontwerp23 5.1. Testbasis per E2E-proces detailleren **
23
5.2 Testaanpak per testcluster **
24
5.3 Testtypeplan ***
25
5.4 Logische testgevallen *
25
5.5 Omgevingen detailleren *
26
5.6 Testdata opzetten *
27
6. Implementatie en uitvoering
28
6.1 Fysieke testgevallen uitwerken *
28
6.2 Testomgevingen inrichten *
29
6.3 Bevindingenbeheer inrichten *
29
6.4 Draaiboek testomgeving creëren *
30
6.5 Testteam compleet maken *
31
6.6 Intake test uitvoeren *
31
6.7 Testronden uitvoeren *
32
6.8 Bevindingen beheren *
32
6.9 Omgevingen beheren *
33
7. Evalueren exitcriteria *34 8. Afronding35
Naar de index
End to End testen
© 2014
3
1. Inleiding: E2E testen Dit artikel maakt onderdeel uit van een praktijkgerichte aanpak voor End to End (E2E) testen. “E2E” wil zeggen: End to End, van het ene uiterste einde naar het andere einde. Dit zijn de processen die over de complete technische infrastructuur (de systeemketen) heen lopen. E2E-processen kunnen werkprocessen zijn van gebruikersafdelingen of beheerders, maar ook processen die door klanten worden uitgevoerd of processen waarbij andere organisaties informatie verkrijgen. Een E2E-test richt zich op de samenhang tussen deze E2E-processen en de systeemketen. De samenhang tussen E2E-processen en de systeemketen wordt hier de E2E-keten genoemd. In een E2E-test verschillen de activiteiten op beslissende punten van de wijze waarop ze in andere testsoorten worden uitgevoerd. Een E2E-inventarisatie is in feite het verzamelen van de testbasis. In een E2E-test zullen de testers deze zelf grotendeels moeten opstellen. De teststrategie is in het geval van een E2E-test gericht op specifieke E2E-risico’s. De testplanning van een E2E-test gaat uit van de testronden en de doorlooptijd van de testgevallen. Het testontwerp bestaat uit het slim combineren van de stappen uit de E2E-processen en de stromen door de systeemketen. Het nu volgende artikel behandelt het faseringsmodel van een E2E-test.
Naar de index
End to End testen
© 2014
4
2. E2E-testen van begin tot einde
Beheer
In de volgende artikelen wordt de E2E-test stapsgewijs van begin tot eind beschreven. De indeling in activiteiten (het faseringsmodel) is ontleend aan ISTQB. Detailbeschrijvingen van belangrijke technieken worden in de andere delen (zie boven) uitgewerkt. Niet elke activiteit hoeft altijd, in elke omstandigheid en met de grootste diepgang te worden uitgevoerd. Met sterretjes wordt per paragraaf aangegeven in welk geval een activiteit moet worden uitgevoerd. * = ** = *** =
altijd uitvoeren, ook kleine organisaties middelgrote organisaties, middelgrote projecten hoge risico’s, complex releasemanagement, grote organisatie, alleen in bepaalde context
Op hoofdlijnen komt het faseringsmodel van een E2E-test overeen met dat van andere testen. Er zijn echter activiteiten die bij andere testen niet of nauwelijks voorkomen, zoals de definitie van de E2Etest in het project. Voor andere activiteiten geldt dat deze in een E2E-test wezenlijk anders en uitgebreider zijn:
De testbasis moet zelf verzameld en opgesteld worden (de E2E-inventarisatie). Het testontwerp van een E2E-test is minder formeel dan dat van bijvoorbeeld een systeemtest, maar wel complexer. Testtechnieken moeten creatief en flexibel ingezet worden. Er moet meer worden afgestemd met andere testteams: over gedeelde testgevallen, testdata, testomgevingen en bemensing. Testomgevingen en testdata zijn complexer en groter. Elk deelsysteem heeft een eigen testom- geving die aangesloten moet zijn op andere testomgevingen. Voortgangsbeheer is complexer. De doorlooptijd van een E2E-testgeval kan meerdere dagen beslaan en handelingen binnen één testgeval moeten soms door meerdere groepen testers wor- den uitgevoerd (gebruikers, testers, beheerders). E2E-testers hebben een actieve rol in de analyse van bevindingen. Analyse van bevindingen uit een E2E-test vereisen namelijk inzicht in de samenhang van de E2E-keten.
Naar de index
End to End testen
© 2014
5
3. Planning De fase Planning is uitgebreider dan in andere testsoorten. Er moet worden afgestemd met andere partijen die betrokken zijn in de E2E-test. Een E2E-test moet zichzelf in een vroeg stadium vaak nog manifesteren: het belang van E2E-testen wordt bijvoorbeeld nog niet onderkend of er is nog geen organisatorische inbedding.
Beheer
Binnen de fase Planning worden de volgende deelactiviteiten onderkend: 1. 2. 3. 4. 5. 6.
Plaatsbepaling in de organisatie Definitie van de E2E-test in het project Initiatie van de E2E-test Bepalen testbasis Bepalen teststrategie Planning
De opdeling in deelactiviteiten is logisch en niet strikt volgordelijk. Het kan bijvoorbeeld voordelen hebben om een risicoanalyse (bepalen teststrategie) eerder uit te voeren dan hier wordt gesuggereerd. Hieronder wordt een overzicht gegeven van de deelactiviteiten binnen de fase Planning met de corresponderende technieken en de resultaten. Figuur: Fase Planning: activiteiten, technieken, resultaten
Naar de index
End to End testen
© 2014
6
3.1 Plaatsbepaling in de organisatie
Planning
Een E2E-test beperkt zich niet noodzakelijk tot één project of één organisatie. Samenhang met andere organisaties en andere projecten valt mogelijk binnen de scope van de E2E-test. Er moet eerst worden geanalyseerd hoe men organisatiebreed tegen E2E-testen en E2E-processen aankijkt en hoe bestaande testen zijn georganiseerd. Dit hangt samen met projectoverstijgende releaseplanningen en releasemanagement. Eventuele projectoverstijgende en organisatieoverstijgende testen moeten worden afgestemd met de betreffende projecten en organisaties. De volgende activiteiten worden onderscheiden binnen de plaatsbepaling binnen de organisatie:
1. Aanhaken bij organisatiebrede E2E-afdeling, omgeving of activiteiten. 2. Onderzoek integrale projectplanning en effecten van projecten op elkaar. 3. Afstemmen projectoverstijgende testen op hoofdlijnen. 1. Aanhaken bij organisatiebrede E2E-afdeling (E2E-testcentrum), testomgeving of acti- viteiten *** Het moment waarop een E2E-test in een project wordt geïnitieerd is afhankelijk van de plaats en het belang dat de E2E-test al in de organisatie heeft. In het gunstigste geval is er een apart organisatieonderdeel dat als een “E2E-testcentrum” functioneert. Projecten zijn in zo’n geval verplicht in een vroeg stadium deze afdeling te betrekken zodat de juiste activiteiten op het juiste moment worden gestart. Een E2E-testcentrum kan bijvoorbeeld een afdeling met E2E-testmanagers zijn die naast projectmanagers opereren. In sommige grote organisaties bestaat een aparte afdeling voor integrale, projectoverstijgende testen, met een eigen permanent operationele E2E-testomgeving en een E2E-testteam. Een E2E-testcentrum initieert de volgende activiteiten:
Toetsen vanuit E2E-perspectief. Inrichten van een E2E-testteam. Uitvoeren van risicoanalyses. Opzetten van testomgevingen. E2E-testen in de integrale E2E-testomgeving.
Het voordeel van een E2E-testcentrum is dat hier projectoverstijgend wordt gedacht en gewerkt. Indien er meerdere projecten en releases parallel in dezelfde keten wijzigingen aan het voorbereiden zijn, hebben deze impact op elkaar. Planning en afstemming van E2E-testen over projecten heen is dan van vitaal belang. Verantwoordelijkheden, mandaat en budget voor E2E-testen zullen vanuit het E2Etestcentrum al grotendeels ingevuld zijn. Of een E2E-testcentrum bestaat hangt af van de grootte van de organisatie, de complexiteit, omvang en kwantiteit van projecten en bovenal de volwassenheid van de organisatie. Voor de testmanager van een project is het zaak uit te zoeken wat er precies gebeurt vanuit het E2E-testcentrum en in hoeverre hiermee de E2E-testen vanuit het project afdoende zijn afgedekt. Indien het E2E-testcentrum ontbreekt moet binnen het project een E2E-test worden opgezet. Dit is het moment om een E2E-testmanager aan te stellen.
Naar de index
End to End testen
© 2014
7
2. Onderzoek integrale projectplanning en effecten van projecten op elkaar * Wanneer een E2E-testcentrum ontbreekt, moet de E2E-testmanager onderzoek doen naar de relaties van het project met andere projecten. Voor het testen is het namelijk belangrijk om te weten of er regressie optreedt ten gevolge van andere projecten en of er dus extra regressietesten moeten worden uitgevoerd. Een E2E-testset is een prima uitgangspunt voor een periodieke regressietest in geval van complex releasemanagement. De E2E-testmanager moet de betrokken testteams per project informeren over het eigen project en zich laten informeren over de andere projecten. De verschillende betrokken testmanagers moeten een aantal zaken afstemmen: het dekken van projectoverschrijdende risico’s maar wellicht ook het gedeeld gebruik van omgevingen, data, testgevallen en mensen. 3. Afstemmen projectoverstijgende testen op hoofdlijnen * In geval van projectoverstijgende testen kan het lastig zijn om steun, inzet, budget en tijd te krijgen bij de betrokken projectmanagers. Vooral het budget ligt in deze gevallen complex: hoe bepaal je namelijk de kosten die risico’s met zich mee brengen door aanpassingen uit een ander project? En hoe organiseer je vanuit meerdere projecten een gezamenlijke test? Wie draagt daar dan aan bij? Hier kunnen een risicoanalyse en een schalingsmodel van projecten uitkomst bieden. Hoge risico’s met effecten op de gemeenschappelijke infrastructuur en de grootte van het project bepalen de uit te voeren gezamenlijke E2E-test en bepalen ook hoe de projecten hierin moeten bijdragen. Indien de noodzaak voor projectoverschrijdende E2E-testen bestaat zal hierover zo spoedig mogelijk binnen of buiten het project afstemming moeten plaatsvinden over de invulling, verantwoordelijkheden, bemensing en de kosten. Zonder het juiste mandaat zal een E2E-test niet plaats kunnen vinden. Het mandaat, over tijd, kosten en bemensing, moet bij de betrokken projectmanagers worden verkregen of bij de hiërarchische laag boven projectmanagers (zoals programmamanagers, releasemanagers, IT-managers of domeinmanagers).
Planning
3.2 Definitie van de E2E-test in het project Nadat duidelijk is geworden hoe bekend men binnen de organisatie is met E2E-testen, wordt het raamwerk van de E2E-test binnen het project opgezet. Indien er al een E2E-testcentrum bestaat, zal deze hier al ondersteuning bieden. In andere gevallen zal de E2E-testmanager zelf deze grond moeten ontginnen.
Activiteiten in deze fase zijn: 1. Risico-inventarisatie op hoofdlijnen. 2. Onderzoek geplande testactiviteiten en dekking E2E-aspecten. 3. E2E-test als projectonderdeel binnen project afstemmen.
Naar de index
End to End testen
© 2014
8
1. Risico-inventarisatie op hoofdlijnen * Discussies over het belang, de planning en de inrichting van een E2E-test worden gevoerd op basis van risico’s. Het is aan de E2E-testmanager om aan te tonen of grote E2E-risico’s worden gelopen en of een E2E-test een noodzakelijke risicobeperkende maatregel is. Een middel om een eerste risicoanalyse op hoofdlijnen uit te voeren is het invullen van een E2E-checklist en het beschouwen, met een aantal vooraanstaande projectleden, van E2E-risico’s en hun relevantie voor het project. In deel 10 Checklists en voorbeelden van het Ebook staat een checklists met E2E-productrisico’s. De E2E-testmanager bespreekt deze risico’s en de maatregelen vervolgens op een projectvergadering. 2. Onderzoek geplande testactiviteiten en dekking E2E-aspecten * In de projectdocumenten (zoals het projectplan of een eventueel al aanwezig Testplan) onderzoekt de E2E-testmanager de testen die al zijn voorzien. De E2E-testmanager onderzoekt in hoeverre in deze testen E2E-risico’s zijn gedekt. Hij stelt op hoofdlijnen vast in hoeverre grote E2E-risico’s worden gemist en hoe de bestaande testactiviteiten kunnen bijdragen aan een E2E-test. 3. E2E-test als projectonderdeel binnen project afstemmen * Nu bepaalt de E2E-testmanager, met de projectmanager of de testmanager, wat de basisvorm van de E2E-test is: welke van de E2E-risico’s moeten in een aparte fase worden afgedekt (als testsoort) en welke risico’s kunnen bij bestaande testen worden ondergebracht (als testtype, zie kader)? Wordt een aparte E2E-test georganiseerd of kan worden volstaan met de Acceptatietest of de Systeemtest die de E2E-risico’s afdekken? Een E2E-test legt ook beslag op andere projectleden en op mensen uit andere afdelingen: ontwerpers, beheerders, gebruikers, e.d. Hier moet nu ook een eerste inschatting en planning voor worden afgegeven. Wie zijn wanneer nodig? De E2E-testmanager zal in deze fase de voordelen van een E2E-test moeten benadrukken om steun te krijgen. In een testsoort worden testen door één testteam uitgevoerd (bijvoorbeeld unittest, systeemtest of acceptatietest). Een testsoort kan meerdere aspecten dekken. Een testtype is een set activiteiten die gericht zijn op het testen van één aspect (bijvoorbeeld efficiencytest, securitytest). De activiteiten van een testtype zijn niet per definitie belegd in één testsoort. Voordelen voor een project van het uitvoeren van een E2E-test zijn:
Beperken van E2E- risico’s in productie: meer vertrouwen in de kwaliteit van de gehele systeem- keten en de stabiliteit van bedrijfsprocessen. Beperken van implementatieproblemen door het naspelen van productiegelijke scenario’s met be- heerders en gebruikers. Vroege acceptatie van onderdelen door betrokkenheid van gebruikers en beheerders. Gedeeltelijk inzetten van centrale medewerkers in de zogenaamde E2E-board, waardoor deze kennis van het nieuwe systeem en de E2E-processen opbouwen en tegelijk ook productiewerk kunnen blijven doen. Samenwerking met systeemtest, systeemintegratietest en acceptatietest levert besparingen in deze testsoorten op. In geval van complex releasemanagement kan de E2E-test gezien worden als een globale regres- sietest waarmee de allergrootste risico’s van alle betrokken projecten kunnen worden gedekt. Een reguliere, projectoverschrijdende, E2E-test levert een testset en expertise op die door meer- dere partijen is te gebruiken in toekomstige projecten.
Naar de index
End to End testen
© 2014
9
3.4 Initiatie van de E2E-test Zodra de E2E-test als noodzakelijk onderdeel is geaccepteerd door het project, moeten de activiteiten worden gepland, en kan de organisatie worden opgezet. Planning
Activiteiten: 1. 2. 3. 4.
Vaststellen opdracht. Planning op hoofdlijnen. E2E-Kernteam inrichten. E2E-board inrichten.
1. Vaststellen opdracht * De E2E-testmanager maakt een korte omschrijving van de opdracht. Hierin staan:
Het doel van de E2E-test. Acceptanten. Samenhang met andere testen. De belangrijkste activiteiten. Verantwoordelijkheden. Mijlpalen en producten.
De opdracht wordt kort afgestemd met de testmanager of de projectleider en andere testteams . De opdrachtomschrijving komt terug in het testplan. De acceptanten van een E2E-test zijn dezelfde acceptanten die in het project zitting hebben. Hier dient wel bij aangetekend te worden dat de acceptatie van de E2E-test breder kan uitvallen dan de scope van het project. Andere projecten en organisaties kunnen ook een belang hebben bij de inhoud en de resultaten. Dit kan betekenen dat testen moeten worden uitgevoerd die aanvankelijk door het project niet werden voorzien, zoals bijvoorbeeld regressie ten gevolge van een wijziging elders in de keten of regressie vanuit een ander project. 2. Planning op hoofdlijnen * De E2E-testmanager maakt een planning op hoofdlijnen. Deze bestaat uit een opsomming van de fasering (zoals hier beschreven) met de diverse activiteiten en een globale inschatting van doorlooptijd, inspanning en bemensing. Deze planning is nog voorlopig en afhankelijk van o.a. de detaillering van risico’s. Er worden in deze planning nog ruime marges aangehouden. 3. Kernteam inrichten * Een belangrijk onderdeel van de planning is de bemensing van het E2E-kernteam. Het E2E-kernteam is het kloppende hart van de E2E-test. Hier wordt de kennis verzameld en worden de belangrijkste activiteiten uitgevoerd en gecoördineerd. Het E2E-kernteam bestaat uit tenminste één professionele E2E-tester, eventueel aangevuld met experts op het gebied van de E2E-processen (bijvoorbeeld een senior gebruiker) en beheerders die ook in productie verantwoordelijk zijn voor de E2E-keten. Het zal in de praktijk niet altijd mogelijk zijn om de genoemde medewerkers voltijds te kunnen betrekken in het E2E-team. Op zich hoeft dit geen probleem te zijn: er moeten wel goede afspraken worden gemaakt over de minimale inzet en de continuïteit. Tijdens ontwerp en analyse maar ook voor de start van de testuitvoering zal het E2E-kernteam worden aangevuld met testers tot er een volledig E2Eteam operationeel is. Naar de index
End to End testen
© 2014
10
4. E2E-board inrichten * Naast het E2E-kernteam moeten diverse experts worden betrokken bij de E2E-testen. Het gaat dan om werknemers met kennis van E2E-processen en werknemers met kennis van de systeemketen. Dit kunnen zijn: representanten van gebruikersorganisaties, klanten, beheerders en ontwerpers. De omvang van de E2E-board is afhankelijk van de grootte en complexiteit van de E2E-ketens (d.w.z.: de processen, de systeemarchitectuur en hun onderlinge samenhang). In grote organisaties kan er sprake zijn van meerdere groepen en E2E-boards, bijvoorbeeld per grote E2E-keten. Idealiter bestaat de E2Eboard uit een handvol experts die gezamenlijk de benodigde kennis inbrengen. De leden van de E2Eboard kunnen niet continu en voltijds betrokken worden bij de E2E-test. De E2E-board komt periodiek samen (bijvoorbeeld wekelijks een uur en tijdens testuitvoering dagelijks een uur) en dient als klankbord voor het E2E-team. Typische onderwerpen die worden besproken met de E2E-board zijn: risico’s, te kiezen testdiepgang, mogelijke testscenario´s, bevindingen en acceptatiecriteria.
3.5 Bepalen testbasis Het E2E-team richt zich nu op het identificeren van de E2E-processen. Tijdens de Analyse en Ontwerpfase dient dit onderzoek vervolgens als basis voor het verder uitwerken van de testgevallen voor de E2E-test. Planning
Activiteiten: 1. 2. 3.
Verzamelen documentatie. Vaststellen E2E-processen. Systeemplaat opstellen per E2E-proces.
1. Verzamelen documentatie * Voor een E2E-test is de testbasis in de regel niet één document of een verzameling documenten maar een inventarisatie van de wisselwerking tussen E2E-processen en systemen. Deze inventarisatie geschiedt op basis van meerdere documenten en gesprekken met diverse medewerkers (zie: deel 2 E2Einventarisatie). De volgende documenten komen in aanmerking om te worden meegenomen in de inventarisatie:
Procesbeschrijvingen. Werkinstructies. Systeembeschrijvingen op hoofdlijnen. Globaal ontwerp. Systeemplaten. Requirements. Use Cases. Functionele ontwerpen. Technische ontwerpen. Interfacebeschrijvingen.
Het E2E-kernteam zal in het project en de organisatie op zoek moeten gaan naar deze documenten. Procesbeschrijvingen, globale ontwerpen en requirements vormen in de regel de kern van wat E2Etesters nodig hebben.
Naar de index
End to End testen
© 2014
11
2. Vaststellen E2E-processen * Uit de documenten, maar vooral ook uit gesprekken met de diverse gebruikersafdelingen, moeten de E2E-processen worden vastgesteld. Denk hierbij aan de belangrijkste diensten of producten die worden geleverd (zoals: “aanmaken offerte”) en hoofdgroepen van mutaties (zoals “wijzigen NAW-gegevens” of “overlijden klant”). 3. Systeemplaat opstellen per E2E-proces * Vervolgens moet per E2E-proces worden uitgezocht hoe deze over het systeemlandschap loopt. Dit resulteert in een E2E-keten: een systeemplaat per E2E-proces. Eerst wordt een systeemplaat gemaakt van het complete systeemlandschap. In de plaat hieronder behoren de Belastingdienst en de Banken tot de externe organisaties. Figuur: Voorbeeld: Systeemplaat complete systeemlandschap
Naar de index
End to End testen
© 2014
12
Elk E2E-proces moet in deze plaat worden getekend. Dit levert de systeemplaat van het specifieke E2E-proces op met daarin de processtappen. Als voorbeeld wordt hier het E2E-proces “offerte via tussenpersoon” van een verzekeringsmaatschappij gegeven: Figuur: E2E-keten: E2E-proces offerte met systeemplaat
In dit voorbeeld zijn de volgende stappen te onderscheiden: 1. De klant vraagt een offerte aan via de tussenpersoon. De tussenpersoon voert de klantgegevens en het product in op zijn systeem. 2. Via de polisadministratie worden de klantgegevens opgevraagd of ingevoerd in de klantenadministratie 3. Vervolgens worden door de polisadministratie productgegevens opgehaald in het productensysteem (looptijd, prijzen, voorwaarden, et cetera). 4. In de polisadministratie worden op basis van de klantgegevens en de productgegevens offertes teruggegeven aan het tussenpersoonsysteem. De klant c.q. de tussenpersoon kiest één van de opties. 5. In de polisadministratie wordt een offerte geregistreerd bij de klant. 6. De klant ontvangt een offerte vanuit het mailingsysteem. Deze moet vervolgens worden ondertekend en ingestuurd om een polis af te sluiten. Voor elk van de E2E-processen moet een dergelijke plaat worden opgesteld.
Naar de index
End to End testen
© 2014
13
3.6 Bepalen teststrategie*
Planning
De volgende stap betreft het vaststellen van de teststrategie. Hiervoor is allereerst een productrisicoanalyse (PRA) nodig. Vervolgens wordt bepaald welke E2E-processen en delen van de E2E-keten op welke manier getest moeten worden. Activiteiten: 1. 2. 3.
E2E Productrisicoanalyse. Testclusters vaststellen. Aanpak per testcluster.
1. E2E Productrisicoanalyse * In een groot project kan een PRA een complexe aangelegenheid worden. Het is moeilijk om een korte en efficiënt bemenste vergadering te organiseren waarin alle mogelijke risico’s kunnen worden geïdentificeerd. Als er binnen het project nog geen productrisicoanalyse heeft plaatsgevonden moet de PRA nog worden georganiseerd en kan het E2E-team hierbij aansluiten met als input de eerste globale risico-inschatting en de E2E-processen. In het geval er al een PRA (of wellicht meerdere per systeem of betrokken project) heeft plaatsgevonden moeten uit de reeds uitgevoerde PRA E2E-risico’s worden gehaald. Indien een eerder uitgevoerde PRA in het project niet de gewenste focus op E2E-risico’s heeft gehad, moet de E2E-testmanager eerst zelf de E2E-risico’s globaal analyseren. Vervolgens kunnen er gedetailleerde risicoanalyses plaatsvinden, in samenwerking met specialisten. Dit zijn dan meestal individuele gesprekken, om in meer detail, per E2E-proces, de risico’s en de te nemen maatregelen afdoende in kaart te brengen. De E2E productrisicoanalyse levert de volgende resultaten op: Definitieve lijst met te testen E2E-processen. Risico’s (impact, kans en type risico op basis van kwaliteitsattributen) per E2E-proces. Lokalisering van de hoogste risico’s in de werking van de E2E-ketens (bijvoorbeeld: wat is de bottleneck in de verwerking in het systeemlandschap als efficiency een groot risico is?). 2. Testclusters vaststellen * Op basis van de risicoanalyse worden nu de testclusters vastgesteld. Testclusters zijn samenhangende testactiviteiten voor wat betreft risico’s, uitvoering en planning. Een testcluster kan de functionele test zijn van het E2E-proces “offerte”. Een ander cluster kan de stresstest van hetzelfde E2E-proces zijn. De uitvoering, testgegevens, benodigde vaardigheden en tools zijn in dit geval zo verschillend dat dit twee apart uit te voeren verzamelingen testactiviteiten worden en dus twee verschillende testclusters. 3. Aanpak per testcluster * Per testcluster wordt vervolgens bepaald hoe getest moet worden. Dit komt overeen met het vaststellen van de testtechniek, de diepgang en testmaat. In geval van een E2E-test zijn deze begrippen echter niet zo eenduidig en formeel toe te passen als bijvoorbeeld in een systeemtest, waar de testbasis bestaat uit eenduidige beschrijvingen van condities, beslissingen en resultaten. Formele testtechnieken worden daarom in de E2E-test niet toegepast: dit zou er toe leiden dat de E2E-test de systeemtesten herhaalt. De testbasis van een E2E-test bestaat uiteindelijk uit gedetailleerde beschrijvingen van E2E-processen door een systeemketen heen (de E2E-ketens). De te testen condities en resultaten (de testitems) voor
Naar de index
End to End testen
© 2014
14
een E2E-testontwerp zijn de belangrijke stappen in de E2E-processen en de bijbehorende stappen in de systeemketen. Deze testitems zijn de handelingen van actoren, beslissende factoren, kritische factoren en resultaten zoals die uit een gedetailleerde E2E-inventarisatie komen. In de testaanpak worden per testcluster, op basis van de risico’s, gezond verstand en creativiteit, aanwijzingen gegeven over de mate waarin de verschillende testitems in combinatie worden geraakt.
3.7 Planning Op basis van de aanpak per testcluster maakt de E2E-testmanager nu een inschatting van benodigd tijd, geld, materieel en mensen. De informatie wordt vastgelegd in een testplan. Planning
Activiteiten: 1. 2. 3. 4. 5. 6. 7.
Acceptatiecriteria vaststellen. Entry- en exitcriteria vaststellen. Detailplanning uitwerken. Randvoorwaarden en uitgangspunten bepalen. Organisatie opzetten. Omgevingen bepalen. Testplan schrijven.
1. Acceptatiecriteria vaststellen * De risicoanalyse en de daaruit volgende aanpak per testcluster geeft een goede indruk van de uit te voeren activiteiten. De uit te voeren testgevallen zijn eerste acceptatiecriteria. De acceptatiecriteria moeten verder nog worden uitgewerkt. De volgende punten kunnen daarbij als checklist dienen.
Acceptanten: per E2E-proces en deel van de architectuur moet worden vastgesteld wie hier uitein- delijk een handtekening onder moeten zetten. Dit zijn in de regel de acceptanten zoals die tijdens de fase Initiatie al zijn vastgesteld. Tijdens de planningsfase moet met deze acceptanten worden vastgesteld onder welke voorwaarden zij tot acceptatie overgaan. In hoeverre is de uitvoering van de testgevallen voldoende? Wil men bijvoorbeeld ook nog de werking van achtergrondprogramma’s gedurende een bepaalde periode zien? Welke niet-functio- nele acceptatiecriteria zijn er verder nog (zoals gebruikersvriendelijkheid)? Hoe kunnen deze wor den gecontroleerd? Welke testgevallen moeten wel en welke hoeven niet te worden uitgevoerd? Van wie verlangen de acceptanten een aanvullend oordeel (bijvoorbeeld een audit of een bepaalde medewerker)? Van welke delen wil men expliciet en in detail de testgevallen en de resultaten zien? Hoe moeten resultaten worden vastgelegd en gepresenteerd? Hoe vaak moeten testgevallen zijn uitgevoerd? Zijn alle aspecten gedekt? Hoeveel fouttolerantie wordt bij in productiename geaccepteerd? Welk type fouten zijn wel en welke absoluut niet acceptabel? In hoeverre moet een complete hertest of regressietest worden uitgevoerd op de laatste versies van alle systemen in de E2E-keten?
2. Entry- en exitcriteria vaststellen * Vervolgens is het noodzakelijk vast te stellen welke criteria worden gehanteerd om te besluiten te starten met de testuitvoering. Dit kan verschillen per testcluster, zeker in een grote E2E-keten.
Naar de index
End to End testen
© 2014
15
De volgende zaken zijn van belang:
Vereiste status per systeemtest, interfacetest of zelfs systeemintegratietest, en hoe hiervan be- wijs wordt geleverd (testrapporten, testverslagen, output). Beschikbaarheid van de testomgeving. Status van een uit te voeren intake van de testomgeving. Oplevering van testdata door de E2E-keten heen. Beschikbaarheid van ondersteuning door beheerders van betreffende systemen.
Als wordt besloten tot de start van de test terwijl niet alle entrycriteria zijn gehaald, dan moeten de risico’s en de impact op de planning worden aangegeven. Typische testprojectrisico’s zijn dan: verminderde waarde van testresultaten, het later opnieuw moeten uitvoeren van testgevallen, het vastlopen van E2E-processen, uitloop, het niet meer beschikbaar hebben van testpersoneel, et cetera. Exitcriteria vallen voor een groot deel samen met de acceptatiecriteria, maar moeten worden aangevuld met producten die door het E2E-testteam moeten worden opgeleverd:
Regressietestset. Testgevallen en testresultaten. Testgegevensets. Testrapport. Overdracht aan beheerorganisatie.
3. Detailplanning uitwerken ** De planning van de E2E-test bestaat uit diverse onderdelen, waarbij de testuitvoering centraal staat. Er zijn veel afhankelijkheden zoals die tussen de testgevallen onderling en externe factoren zoals de voortgang van andere projectonderdelen. Alle afhankelijkheden, activiteiten en mijlpalen moeten in een tijdslijn worden uitgewerkt. Er zijn drie dimensies in de planning: doorlooptijd, bemensing en budget. De globale planning moet eerst in doorlooptijd worden uitgewerkt en vervolgens moet per activiteit worden bepaald wie verantwoordelijk wordt. Deze verantwoordelijkheid moet worden afgestemd met de betreffende medewerkers en leidinggevenden. Hieruit volgt dan een inschatting van belasting, uren per dag per medewerker en realiteitsgehalte van de planning. Ten slotte kunnen uren en beslag op andere middelen worden uitgewerkt in een budget. De stappen om te komen tot een detailplanning zijn: Planning op hoofdlijnen met de projectplanning combineren. Per testcluster belangrijke activiteiten en mijlpalen vaststellen. Hierin moet bijvoorbeeld ook het aantal testronden tot uitdrukking komen. Van de verkregen activiteiten inspanning, bemensing en duur vaststellen. Een totaaloverzicht van de activiteiten maken, met daarin de belangrijke mijlpalen. De detailplanning moet worden afgestemd met de betreffende afdelingen, projectgroepen, me- dewerkers en hun leidinggevenden. Consequenties voor de projectplanning moeten worden be- sproken met de projectleider. Plannen is geen natuurwetenschap: ook de verbeelding en de ervaring van de E2E-testmanager, in combinatie met ervaringen en gegevens uit andere testen binnen het project en de organisatie, spelen een belangrijke rol. De detailplanning zal nooit af zijn en moet steeds worden bijgewerkt gedurende het hele traject, op basis van nieuwe inzichten en de status van alle activiteiten waar men van afhankelijk is. De detailplanning maakt deel uit van het testplan, maar kan als los document worden beheerd (bv in een tool) als MS Excel of MS Project. Zie deel 5 Testplanning van het E2E-test Ebook voor gedetailleerde aanwijzingen om te komen tot een testplanning.
Naar de index
End to End testen
© 2014
16
4. Randvoorwaarden bepalen * Vanwege de complexiteit van E2E-testen moeten randvoorwaarden met alle betrokken teams (zoals beheerders van een systeem of gebruikers van een afdeling) vooraf worden afgestemd. Natuurlijk moeten alle randvoorwaarden in het testplan terechtkomen, maar in geval van een E2E-test is een testplan een overkoepelend uitgangspunt en niet meer dan dat. Af te stemmen generieke randvoorwaarden voor E2E-testen zijn: Omgevingenbeheer: voldoende beschikbaarheid van beheerders, betrokkenheid bij E2E-traject. Afgestemde opleverdatums van de testomgevingen van alle betrokken systemen. Configuratiebeheer: centrale versiecontroles over alle omgevingen, afgestemde criteria en beslis- singsbevoegdheden bij nieuwe installaties of data. Bemensing: voldoende beschikbaarheid van testers (bijvoorbeeld vanuit systeemtesten, gebrui- kersafdelingen en beheer), gebruikers en beheerders. Kwaliteit: exitcriteria van ontwerpfasen, systeemtesten en systeemintegratietesten bij oplevering aan E2E-test. Oplevering lijsten met openstaande bevindingen en uitgevoerde testgevallen. Bevindingenbeheer: communicatie, eenduidigheid van begrippen zoals prioriteit, impact en status, escalatiekanaal en beslissingsbevoegdheid bij onenigheden. Centrale bevindingenadministratie over de E2E-keten heen. Communicatie: directe communicatie met teamleden (dit kan nog wel eens een issue zijn in geval van uitbesteding) en beschikbaarheid van mensen voor vragen en uitvoering van randvoorwaar- delijke activiteiten. E2E-testteam is aangesloten op berichtgeving en rapportage over status van systemen. Goodwill van alle projectleden. Dit lijkt banaal maar kan een grote belemmering zijn. Zorg voor periodiek direct contact tussen de diverse teams.
5. Organisatie opzetten * Organisatiemodel Uit de voorgaande activiteiten valt het grootste deel van de benodigde organisatie af te leiden. De inzet van mensen moet worden gerechtvaardigd middels een organisatiemodel. In het organisatiemodel moeten onderlinge verhoudingen, communicatielijnen, beslissingslijnen, rollen, taken en verantwoordelijkheden worden getoond. In onderstaand schema worden de belangrijkste relaties tussen het E2Etestteam en andere teams weergegeven.
Naar de index
End to End testen
© 2014
17
Figuur: Basisstructuur organisatie E2E-test
Project management
Ontwerp per systeem
Systeem testteams
E2E testteam Ontwikkeling per systeem
Acceptanten
Beheer per systeem Figuur 13 Basisstructuur organisatie E2E-test
Het E2E-testteam Systeemtestteams bestaan voornamelijk uit professionele testers die voor een bepaalde duur volledig ingezet zijn op een systeemtest en worden aangestuurd vanuit de IT-organisatie. Dit model zal niet werken voor een E2E-test. De benodigde kennis is zo divers en zo moeilijk te verkrijgen dat het E2Etestteam een samenwerking moet zijn tussen diverse disciplines. Vertegenwoordigers uit alle benodigde disciplines zijn daarnaast niet volledig en voor lange tijd in te zetten op de E2E-test. De organisatie van de E2E-test heeft daarom de volgende lagen: De E2E-testmanager. Afhankelijk van de grootte en complexiteit van de E2E-test is dit de overall testmanager, een aparte E2E-testmanager of een coördinator. In grote organisaties en grote pro- jecten kan zelfs gedacht worden aan meerdere testcoördinatoren (per organisatie of per E2E-pro- ces). Het E2E-kernteam: dit bestaat uit de E2E-testmanager en ten minste één E2E-tester. Dit zijn rol‑ len en kunnen in geval van een klein project in één persoon verenigd worden. Dit team is al tij- dens de planningsfase operationeel en is voltijds ingezet op de E2E-test. Het E2E-kernteam is verantwoordelijk voor de E2E-inventarisatie en het testontwerp. Daarnaast functioneren de leden als vraagbaak en coördinatoren van de testuitvoering. De E2E-board: dit is een bredere verzameling specialisten en stakeholders uit de organisatie die periodiek samenkomen en als klankbord dienen voor de E2E-testers. Betrokkenheid is in deeltijd (op afroep of via een dagelijkse scrum, afhankelijk van de grootte van het project en de fase waarin men zich bevindt). Vanaf de fase Analyse en Ontwerp zal het E2E-testteam worden aangevuld met testers die, afhan- kelijk van kennis en kunde, testgevallen uitschrijven en testen uitvoeren. Dit zijn in de regel gebruikers, beheerders en testers. Gebruikers en beheerders worden ingezet op de testclusters die overeenkomen met hun specifieke kennis.
Naar de index
End to End testen
© 2014
18
6. Testomgevingen bepalen * De benodigde testomgevingen kunnen eerst worden afgeleid uit de aanpak per testcluster. Op het moment dat testgevallen zijn ontworpen (fase Analyse en Ontwerp en Implementatie en Uitvoering) kan met meer zekerheid en detail worden ingegaan op de benodigde testomgevingen. Er zal dan pas een definitief omgevingenontwerp kunnen worden opgesteld. In het testplan moet op hoofdlijnen zijn vastgelegd welke omgevingen men nodig heeft en wat de planning en de randvoorwaarden daarvoor zijn. Het ligt bijvoorbeeld voor de hand dat een zware stresstest niet op dezelfde omgeving wordt uitgevoerd als een functionele procestest. Verder kan het een afweging zijn om systeemtestomgevingen te hergebruiken in E2E-testomgevingen. Er bestaat dan wel een grotere afhankelijkheid van de planning en de status van systeemtesten. In de fase Planning moeten de volgende zaken voor de testomgevingen zijn vastgelegd:
Aantal benodigde E2E-omgevingen op basis van testclusters die niet samen op één en dezelfde omgeving kunnen worden uitgevoerd. Eigenschappen per omgeving vaststellen: in hoeverre of wanneer moet de omgeving productie gelijk zijn voor wat betreft beheer, draaien van programma’s, gegevens en compleetheid van de keten (mogen systemen of systeemdelen missen?). Planning van de omgevingen: vanaf wanneer moet welke omgeving beschikbaar zijn, wat is hier voor nodig? Beheer van de omgevingen: per omgeving en systeem binnen de omgeving moet worden vast gelegd wie verantwoordelijk is voor oplevering, instandhouding en het uitvoeren van zaken zoals het starten van achtergrondprogramma’s. Gevolgen van de E2E-omgevingen voor de deelsystemen en deelprojecten: testomgevingen moe- ten vaak worden gedeeld met andere projecten of andere testsoorten. Hier moeten goede afspra- ken over worden gemaakt en verwachtingen over en weer moeten worden vastgelegd.
In deel 8 Testinfrastructuur van het Ebook worden scenario’s voor wat betreft de invulling van testomgevingen uitgewerkt. 7. Testplan schrijven * De resultaten van de activiteiten binnen de fase Planning resulteren in een testplan. Voor afstemming en accorderen van de inhoud is het nodig dat de E2E-testmanager de inhoud van het plan aan betrokken teams en managers uitlegt, verdedigt en de consequenties voor een ieder verduidelijkt. De vorm en de stappen waarin dit gebeurt is afhankelijk van de cultuur in de organisatie, de grootte van het project en de fysieke afstand tussen medewerkers. In ieder geval moet worden uitgelegd aan leidinggevenden wat het doel en de noodzaak is van de gevraagde inspanning. Een E2E-testplan verschilt qua sjabloon niet van een ander testplan. De gebruikelijke onderwerpen horen onderdeel te zijn van het plan: opdracht, scope, teststrategie, aanpak per onderdeel, randvoorwaarden, risico’s, planning, et cetera. Aandachtspunten zijn de scope en de testitems. Een E2E-test richt zich op de E2E-processen en hun samenhang met de infrastructuur, deze staan centraal in de scopebepaling en moeten daarom duidelijk worden benoemd. Onderdelen van de E2E-keten, zoals interfaces of functionaliteit, worden niet expliciet getest maar worden wel geraakt. Het is belangrijk om deze wel te benoemen, met de bijbehorende testdekking, zodat de verwachtingen ten aanzien van de E2E-test duidelijk zijn. Omdat een E2E-test vaak een laatste test betekent, wordt de scope van testsoorten die hun doelen niet halen, nog wel eens bij de E2E-test neer gelegd. De E2E-test wordt dan zo het “afvalputje” van het project. Dit kan niet altijd worden vermeden maar het moet in ieder geval duidelijk gemaakt kunnen worden, als dit gebeurt, dat de oorspronkelijke scope wordt uitgebreid.
Naar de index
End to End testen
© 2014
19
4. Beheer
Beheer
Het beheer van E2E-testen is binnen het testvak de meest complexe en veeleisende taak voor de E2E-testmanager. De E2E-testmanager opereert hier als volwaardig projectmanager, zonder het testperspectief uit het oog te verliezen. De E2E-testmanager moet de vaardigheid hebben te kunnen laveren tussen verschillende partijen en belangen, op hoofdlijnen planning- en kwaliteitskwesties in te kunnen schatten, bij te sturen en ook inhoudelijke kennis van de E2E-keten op te doen en te hanteren. Activiteiten: 1. Monitoren voortgang. 2. Herplannen. 3. Communiceren. 4. Rapporteren. 5. Leidinggeven.
1. Monitoren voortgang * De voortgang bewaken is afhankelijk van korte communicatielijnen, periodieke effectieve voortgangsvergaderingen, eenduidige en begrijpelijke vastlegging van testvoortgang en discipline van het gehele team om in deze zaken deel te blijven nemen. Idealiter wordt informeel en direct over voortgang gecommuniceerd. De E2E-testmanager kan dan doorvragen en allerlei andere signalen opvangen. De E2E-testmanager is daarom iemand die een aanzienlijk deel van zijn tijd onderweg is: “ergens” op het “rondje langs de velden”. Bij voorkeur zit het gehele E2E-testteam in één ruimte waar de E2Etestmanager direct notie kan nemen van voortgang en belangrijke gebeurtenissen. Maar zelfs als dat het geval is, zijn er nog partijen die niet in de E2E-testruimte zitten maar waar de E2E-testen wel van afhankelijk zijn. Ook daarmee moet regelmatig informeel contact worden onderhouden. Voor de E2Etestmanager is het noodzakelijk dat hij een lijst heeft waarop alle betrokken partijen staan. Hij moet continu inzichtelijk hebben wie waar mee bezig is en wat de status is van de activiteiten die van belang zijn voor het testtraject. Om projectleden onderling op de hoogte te houden van de voortgang en direct met elkaar van gedachten te kunnen wisselen, zijn periodieke voortgangsvergaderingen een must. Zeker tijdens de hoogtijdagen van de testuitvoering moet een vorm gevonden worden waarin mensen, misschien zelfs dagelijks, kort elkaar kunnen informeren over voortgang en status. Dit kunnen dagelijkse scrums zijn waarin het E2E-testteam, andere projectleden en de E2E-board activiteiten, voortgang, risico’s en belangrijke bevindingen bespreken. Door bevindingen, testgevallen en testresultaten centraal, eenduidig en zakelijk vast te leggen, kan het bijhouden van voortgang worden vergemakkelijkt. Er wordt aangeraden een voor iedereen toegankelijke tool zoals Excel te gebruiken om testgevallen en resultaten in vast te leggen en één centrale bevindingentool te hanteren. Gratis clouddiensten zoals Google drive kunnen hier van pas komen: als iedereen die betrokken is in het project internet toegang heeft kunnen hier op betrouwbare wijze meerdere medewerkers tegelijk informatie rond testvoortgang en testbevindingen bijhouden. Het wordt sterk afgeraden dat betrokken organisaties gebruik maken van verschillende bevindingentools.
Naar de index
End to End testen
© 2014
20
2. Herplannen * Met de informatie over de voortgang moet de E2E-testmanager aan de slag, vooral als er gevolgen zijn voor de planning. Hier bewijst een heldere en volledige planning zijn waarde: als één van de vele onderdelen of activiteiten uitloopt of eerder klaar is dan gepland, moet worden geschat wat dit betekent voor andere activiteiten, bemensing en alle andere afhankelijkheden. In feite moet de activiteit detailplanning opnieuw worden doordacht en afgestemd met de partijen en medewerkers die gevolgen ondervinden. Het kan zelfs zo ver gaan dat de projectplanning en de datum van inproductiename moeten worden heroverwogen. Simpelweg schuiven met datums is echter meestal geen optie. De E2E-testmanager moet diverse scenario’s uitwerken en doorspreken met de projectmanager. Het zal dan gaan om het alsnog kunnen halen van gestelde doelen binnen de gestelde tijd, geld, kwaliteit en bemensing. Kan bij extra inzet of de inhuur van externe testers de deadline wel gehaald worden? Kunnen we de extra kosten afwegen tegen het bijstellen van acceptatiecriteria en risico’s en wie moet daarmee instemmen? 3. Communiceren * Communicatie is de smeerolie van een project en dat geldt zeker voor de E2E-test. Precair zijn wijzigingen in het traject: door uitloop van onderdelen in de planning, nieuwe risico’s, een andere aanpak of veranderingen in de projectorganisatie. Maar zelfs als alles conform verwachting loopt is het noodzakelijk om periodiek iedereen van de juiste informatie te voorzien, te weten wat er speelt en ook beducht te zijn op “zachtere” aspecten zoals motivatie, frustraties, beeldvorming over en weer en verwachtingen. Niet-testers die worden betrokken in een test zoals de E2E-test, medewerkers van gebruikersafdelingen of beheerders, hebben vaak meer moeite dan testers met het begrijpen en blijvend juist uitvoeren van testactiviteiten. Het gaat dan om het volgen van procedures bij het juist invullen van bevindingen en uitwerken van testgevallen en het analyseren van resultaten en begrijpen van allerlei technische afhankelijkheden in een testomgeving. Periodieke afstemming en verifiëren of eenieder nog op het “juiste spoor” zit is daarom een must. Een ander aandachtspunt is de communicatie door de diverse testteamleden aan andere organisatieonderdelen. Vergeet niet dat er met angstige ogen wordt gekeken en geluisterd naar de E2E-test. De E2E-testmanager zal er niet altijd bij zijn als een afdelingshoofd vraagt “hoe het gaat”. Als een tester dan vanuit zijn eigen vaak niet complete beeld en emotie daarover uitspraken doet, kan een onjuist vertrouwen worden gewekt. Voorbeeld. Een afdelingshoofd vraagt hoe het gaat en een tester antwoordt dat het “wel lekker gaat”. De tester bedoelt dan: “veel testen uitgevoerd, lekker veel bevindingen gedaan” maar het afdelingshoofd vat dit op als “we kunnen volgende week in productie gaan”. 4. Rapporteren * Er zijn twee vormen van rapportage: voortgangsrapporten en eindrapporten. Voortgangsrapportages verschillen van de rapportages van andere testsoorten, zoals die van de systeemtest, door de complexiteit van de E2E-test. De lezers van voortgangsrapportages willen vanuit verschillende perspectieven op de hoogte gehouden worden: vanuit de status per systeem, per E2Eproces, per functie of per risico. Elk van deze perspectieven kan dwars door de andere perspectieven lopen en dat maakt de rapportage (te) complex. De basis van de E2E-rapporten moeten daarom de E2E-processen zijn. Per E2E-proces wordt ingezoomd op waar problemen zitten (bijvoorbeeld systemen, functies, kwaliteitsattributen). Door de rapportages te baseren op de E2E-processen, en daarmee op de structuur van de planning en de testgevallen, zal het ook eenvoudiger zijn om rapportages te produceren. Bovendien zijn de E2E-processen de belangrijkste focus van de E2E-test.
Naar de index
End to End testen
© 2014
21
Eindrapporten worden onderverdeeld in rapporten over het resultaat van de E2E-test en rapporten over het testproces. Eindrapporten gericht op het resultaat van de E2E-test zijn het belangrijkste product van de E2E-test. Het uiteindelijke vrijgavebesluit wordt gebaseerd op het inzicht in de kwaliteit van het gehele systeemlandschap en de mate waarin de E2E-processen worden ondersteund. Het eindrapport van de E2E-test levert dit inzicht. Ook hier geldt dat vanuit de E2E-processen moet worden gerapporteerd. Per E2E-proces moet worden aangegeven in hoeverre de acceptatiecriteria zijn gehaald. Waar deze niet zijn gehaald moet worden aangegeven waar de discrepanties zitten (per systeem, functie, aspect) en welke risico’s bij inproductiename worden gelopen. Ten slotte zijn er nog eindrapporten die het testproces evalueren. Het gaat hierbij om een strategisch perspectief: waar moeten toekomstige trajecten op letten en lessen uit leren? Zijn er aanbevelingen voor specifieke organisatieonderdelen? Dit gaat dan om zowel het testen als om processen rond het testen, zoals het beheer van testomgevingen, bouw of testdata. Testprocesrapporten worden niet altijd geschreven. Projectleiders zien er vaak het belang niet van in of het volgende project is al weer gestart waardoor er geen capaciteit is om de rapporten uit te werken. Voor het schrijven van een testprocesrapport is het nodig om een brede evaluatie binnen het project uit te voeren en dan gelden de eerder genoemde belemmeringen, zoals de beschikbaarheid van de projectleden, nog meer. 5. Leidinggeven * Monitoren, herplannen, communiceren en rapporteren zijn managementactiviteiten die horen bij de rol van E2E-testmanager. Leidinggeven omvat nog meer dan deze concrete processen. Leidinggeven gaat ook over het omgaan met indirecte projectrisico’s zoals motivatie, ziekte, persoonlijke belangen en teamwork. Een E2E-testmanager, zeker in een groot, complex en langdurig traject, doet er goed aan activiteiten voor het gehele team te organiseren waar men even uit de dagelijkse rollen en tegenstellingen kan stappen en om periodiek met leden van het testteam het traject en het eigen functioneren te bespreken. Het is aan eenieder, maar met name aan de E2E-testmanager, om periodiek terug te gaan naar het doel en de missie van het E2E-testtraject en deze opnieuw vast te stellen en uit te spreken. Gedurende een lang en complex traject zijn medewerkers namelijk geneigd om zich terug te trekken in hun eigen onderdeel of taak en kunnen zo “tunnelvisie” ontwikkelen. Dit geldt ook voor de E2E-testmanager en andere projectleden. Men verliest zo het doel van het testtraject uit het oog en kan zich blindstaren op het wegwerken van openstaande bevindingen, het alleen maar uitvoeren van de vastgestelde testgevallen of zelfs in een vijandige verhouding met anderen terecht komen.
Naar de index
End to End testen
© 2014
22
Beheer
5. Analyse en Ontwerp In de Analyse- en Ontwerpfase worden de testbasis en de risico’s uitgewerkt. Op basis hiervan worden de aanpak en diepgang per testcluster vastgesteld en de logische testgevallen gemaakt. Hiermee kunnen de omgevingen en testdata worden geïdentificeerd en kan de testuitvoering worden gestart. In de Analyse- en Ontwerpfase wordt het E2E-kernteam volledig ingezet. De taken worden verdeeld. Elk lid van het E2E-kernteam krijgt bepaalde E2E-processen of systeemdelen onder haar hoede en wordt daar het centrale aanspreekpunt van in de rest van het traject. Dit leidt tot de volgende activiteiten: 1. 2. 3. 4. 5. 6.
Testbasis per E2E-proces detailleren. Testaanpak per testcluster uitwerken. Testtypeplan opstellen. Logische testgevallen uitschrijven. Omgevingen detailleren. Testdata opzetten.
Tijdens de fase Planning is de testbasis op hoofdlijnen vastgesteld. De producten hiervan waren een systeemplaat, de E2E-processen en de wijze waarop deze E2E-processen van de systeeminfrastructuur gebruik maken. Daarnaast zijn in de strategiebepaling de productrisico’s, de testclusters en de daarbij te hanteren testaanpak bepaald. Om te kunnen komen tot de uiteindelijke logische en fysieke testgevallen moeten eerst twee andere activiteiten worden uitgevoerd. Ten eerste wordt de samenhang van de E2E-processen met de systeemarchitectuur verder uitgewerkt zodat concrete E2E-testgevallen zijn af te leiden uit de testbasis. Ten tweede worden de risico’s per testcluster uitgewerkt tot een testaanpak per testcluster. De testmanager moet er voor zorgen dat al deze informatie (E2E-processen, systeemarchitectuur, testclusters en logische testgevallen) compact wordt geregistreerd en beheerd. Hij schrijft geen grote documenten per onderdeel maar zal alles zo veel mogelijk in één overzicht, in een spreadsheet, weergeven. Vervolgens kan, indien er sprake is van specifieke hoge risico’s die om een specialistische test vragen, een testtypeplan opgesteld. Logische testgevallen worden uitgeschreven en op basis hiervan kunnen de benodigde testomgevingen en testdata definitief worden vastgesteld.
5.1. Testbasis per E2E-proces detailleren **
Analyse en Ontwerp
De eerste stap is om de testbasis, de E2E-inventarisatie, verder uit te werken. Dit is in een eerdere fase (zie Bepalen testbasis tijdens de fase Planning) al op hoofdlijnen gebeurd. Hier wordt daar op voortgebouwd.
Naar de index
De E2E-inventarisatie vindt plaats door documenten te bestuderen die E2E-processen en de werking van de systeemketen beschrijven. Daarnaast wordt dit aangevuld met experts uit de organisatie op het gebied van de E2E-processen en de systeemketen. Het vroeg doorspreken van de E2E-processen is zeer nuttig. Dikwijls loopt men hier al tegen ontwerpfouten aan. In deel 2 E2E-inventarisatie van het Ebook wordt de E2Einventarisatie als techniek in detail uitgelegd. Hier beperken we ons tot de logische stappen en de organisatorische en planmatige consequenties.
End to End testen
© 2014
23
Deze E2E-inventarisatie levert de volgende kennis op: Inzicht in de actoren, triggers, opeenvolgende stappen en de gewenste resultaten per E2E-proces. Functies en condities binnen de deelsystemen die er voor zorgen dat de E2E-keten een volgende stap doorloopt. Dit zijn de z.g. beslissende factoren. In het voorbeeld van de offerte kunnen dat de achtergrondprogramma’s zijn binnen de polisadministratie. Deze zorgen dat informatie uit het klantsysteem en het productsysteem wordt gehaald en dat er mail wordt gestuurd naar de klant. De connecties tussen de deelsystemen. Zijn dit interfaces die online draaien en direct na een actie aan de voorkant werken of zijn het batchprogramma’s die op vaste momenten per dag draaien en vervolgens informatie versturen of opvragen? Het type informatie dat wordt verstuurd tussen systemen. Dit kunnen bestanden zijn in txt-for - maat, xml-berichten of anderszins. Van deze bestanden moet worden vastgesteld wat het formaat is, hoe ze heten, waar ze staan en hoe ze worden verstuurd of opgehaald door andere deelsyste- men. De volgorde en afhankelijkheden van acties door de hele keten heen. Vaststellen van de zogenaamde kritische factoren: de omstandigheden die de werking van de E2E-keten kunnen beïnvloeden. Dit zijn alle zaken die niet zelf een onderdeel van de keten zijn maar waar wel rekening mee moet worden gehouden. Denk hierbij aan speciale momenten in de tijd, zoals maand- of jaarovergangen.
Analyse en Ontwerp
5.2 Testaanpak per testcluster ** Na het detailleren van de E2E-processen kunnen nu de risico’s, zoals die eerder in de E2E-productrisicoanalyse zijn vastgesteld, nauwkeuriger worden gelokaliseerd. Het doel is om de testinspanning te kunnen richten op de grote risico’s en de bronnen daarvan. Een detailrisicoanalyse is geen volledig opgetuigde productrisicoanalyse met participatie van alle mogelijke betrokkenen in een langdurige vergadering. Deze heeft namelijk al eerder plaats gevonden. Hier kan de E2Eboard zijn voordeel bewijzen: via de board heeft men beschikking over inzicht in risico’s en de keten.
Werkwijze: Per testcluster de hoge risico’s verzamelen uit de eerder uitgevoerde productrisicoanalyse. Vaststellen wie ter zake kundig is en deze persoon aanhaken. In klein comité de risico’s per testcluster analyseren. Een oorzaak-gevolganalyse uitvoeren en vaststellen wat de bronnen en effecten van een risico zijn. De aanpak per testcluster uitwerken en definitief maken.
Naar de index
End to End testen
© 2014
24
Analyse en Ontwerp
5.3 Testtypeplan *** In geval van specifieke en moeilijk uitvoerbare testclusters (zoals een zware performancetest of beveiligingstest) kan het nodig zijn om een testtypeplan te schrijven. Een testtypeplan is een testplan dat zich richt op een bepaald aspect, zoals efficiency. Dit kan in het bijzonder nodig zijn als er een apart team van specialisten nodig is om het betreffende cluster te testen. Het testtypeplan functioneert dan ook als een contract. Niet elk testcluster zal dus een testtypeplan behoeven en het is ook aannemelijk dat voor een verzameling testclusters (bijvoorbeeld: alle performancetesten door het hele landschap van clusters heen) één testtypeplan wordt geschreven. Een testtypeplan bevat alle voor het uitvoeren, organiseren en beheersen van een test noodzakelijke informatie maar er kan ook worden verwezen naar het overkoepelende E2E-testplan of mastertestplan om redundante informatie te voorkomen.
Analyse en Ontwerp
5.4 Logische testgevallen * Op basis van de inventarisatie per E2E-proces en de aanpak per testcluster worden nu logische testgevallen uitgeschreven door het E2E-kernteam. Logische testgevallen moeten worden gereviewd door processpecialisten of ontwerpers.
Werkwijze per testcluster: Een lijst maken met alle actoren, beslissende factoren, kritische factoren en resultaten. Uitschrijven van de logische testgevallen waarbij per logisch testgeval moet worden aangegeven welke actoren, beslissende factoren, kritische factoren en resultaten in volgorde worden geraakt. Vaststellen van de uit te voeren controles en tussenresultaten (op logisch niveau). Vastleggen van precondities voor de testgevallen: benodigde data, uitgangssituatie van het sys- teem, uit te voeren acties door de keten heen, draaidatum, prioriteit en relaties met andere test gevallen. Beschrijven van de logische testgevallen in termen van daadwerkelijke situaties, bijvoorbeeld: “klant vraagt offerte aan op product A maar heeft betalingsachterstand op ander lopend product”. Doel van deze stap is het verlevendigen van testgevallen en ze daarmee tastbaar maken. Reviewen/ walkthrough van de logische testgevallen met processpecialisten (gebruiker, ontwerper en/of functioneel beheerder), waarbij de methodiek en de testgevallen worden uitgelegd. Zie deel 6 E2E-Testontwerp van het e-book ∞ voor een stapsgewijze en gedetailleerde beschrijving van de hier voorgestelde testontwerptechniek. In dat artikel worden de verschillende aanpakken per type test (efficiency, security, failover, stabiliteit en functionaliteit) ook uitgewerkt Logische testgevallen moeten zo worden vastgelegd dat ze als basis kunnen dienen voor fysieke testgevallen en onderhoudbaar en overdraagbaar zijn. Daarnaast moeten ze onderling uniform en leesbaar
Naar de index
End to End testen
© 2014
25
zijn zodat ze ook kunnen worden gebruikt voor monitoring en voortgangsrapportages. Om deze redenen wordt aangeraden een sjabloon te gebruiken in een tool als MS Excel en iedere betrokkene in het project hiervan gebruik te laten maken.
Analyse en Ontwerp
5.5 Omgevingen detailleren * De planning en voortgang van de activiteiten die nodig zijn voor het realiseren van testomgevingen moeten tijdig en nauwgezet worden afgestemd en gevolgd. Problemen met de beschikbaarheid van testomgevingen tijdens testuitvoering hebben gevolgen voor het kritieke pad van het project en kunnen grotendeels met een goede voorbereiding worden voorkomen. In de fase Planning zijn de benodigde omgevingen al op hoofdlijnen aangegeven. Nu moeten deze omgevingen gedetailleerd worden beschreven zodat ze voorafgaand aan testuitvoering ook kunnen worden gerealiseerd.
Vanuit de logische testgevallen moet de volgende zaken worden bepaald:
Benodigde E2E-omgevingen vaststellen: testclusters die niet samen op één en dezelfde omgeving kunnen worden uitgevoerd hebben een andere testomgeving nodig of moeten in onderlinge sa- menhang worden uitgevoerd zonder dat ze elkaar negatief beïnvloeden. Eigenschappen per omgeving vaststellen: in hoeverre of wanneer moet de omgeving productiege- lijk zijn voor wat betreft beheer, versies, draaien van programma’s, data en compleetheid van de keten (mogen systemen of systeemdelen missen?). Planning van de omgevingen: vanaf wanneer moet welke omgeving beschikbaar zijn, welke test- ronden worden er uitgevoerd, wanneer moeten nieuwe loads of andere activiteiten ten aanzien van omgevingenbeheer worden verricht en wie mag vanaf welk moment welke activiteiten op de omgevingen uitvoeren? Beheer van de omgevingen: per omgeving en systeem binnen de omgeving moet worden vastge- legd wie verantwoordelijk is voor oplevering, instandhouding en het uitvoeren van technische handelingen. Het gaat dan om het starten van achtergrondprogramma’s en onder welke voor waarden nieuwe versies mogen worden geïnstalleerd. Gevolgen van de E2E-omgevingen voor de deelsystemen en deelprojecten: testomgevingen moe- ten vaak worden gedeeld met andere projecten of andere testsoorten. Er moeten afspraken ge maakt worden over gebruik van omgevingen en gegevens. Toegang, rollen, accounts en wachtwoorden tot de diverse systemen in de omgeving. Het uit- gangspunt is een productiegelijke inrichting zodat autorisatiestructuren ook worden meegetest. Tools waarmee acties in systemen of controles kunnen worden uitgevoerd (bijvoorbeeld database tools of viewers om bestanden mee te controleren).
De inrichting van de omgevingen wordt nu in gang gezet. De E2E-testmanager moet binnen de betreffende beheerafdelingen de verwachtingen kenbaar maken en activiteiten tussen de beheerders van de diverse systemen moeten worden afgestemd. Hoewel de eindverantwoordelijkheid bij de beheerafdeling zelf ligt, moet de E2E-testmanager wel een vinger aan de pols houden. Dit kan een mini-project op zich worden en de E2E-testmanager moet de projectleiding op de hoogte houden van de voortgang en eventuele risico’s. In deel 8 E2E-Testinfrastructuur van het e-book ∞ wordt het opzetten van testomgevingen in meer detail beschreven.
Naar de index
End to End testen
© 2014
26
5.6 Testdata opzetten *
Analyse en Ontwerp
Uit de testgevallen worden de randvoorwaarden voor de benodigde testdata afgeleid. Data moet synchroon zijn door de systeemketen heen. E2E-testgevallen hebben bovendien vaak historie nodig als startpunt omdat complexe historie tijdens de testuitvoering niet meer aan te maken is. Er moet worden bepaald of productiedata kan worden gebruikt.
De volgende activiteiten moeten worden uitgevoerd:
Verzamelen of aanmaken van testdata. Ordenen en verzamelen van de testdata op basis van tijd en onderlinge afhankelijkheden. Activiteiten organiseren om testdata inzichtelijk te maken en er een tijdsframe voor opstellen. Partijen (zoals beheerders van productiedata en omgevingen) aansluiten en afstemmen van acti- viteiten (hier ligt een link met het plannen en initiëren van het opzetten van testomgevingen). Monitoren van de voortgang van de activiteiten.
Het plannen van deze activiteiten zal in de regel geïntegreerd worden met de activiteiten voor testomgevingen. Dezelfde partijen zijn hier veelal bij betrokken (zoals functioneel en technisch beheer per systeem). deel 8 E2E-Testinfrastructuur van het e-book ∞ , sectie Testdata, beschrijft de keuzes en overwegingen met betrekking tot testdata in detail en geeft onder meer checklists die dit ondersteunen.
Naar de index
End to End testen
© 2014
27
6. Implementatie en uitvoering In de fase Implementatie worden de testgevallen fysiek gemaakt, de testomgevingen gerealiseerd, de testdata geladen, bevindingenbeheer ingericht en detailplanningen opgezet en afgestemd. Tijdens de fase Uitvoering vinden eerst intakes van de testomgeving, de testdata en de software plaats. Daarna worden de testgevallen conform planning uitgevoerd.
Beheer
In het geval van een simpele keten zijn dit vrij eenvoudige exercities. Bij een E2E-test is de praktijk weerbarstiger: het ene systeem is bijvoorbeeld op het geplande startmoment wel gereed en het andere niet. Er kunnen nog zware functionele bevindingen openstaan. Daarnaast kan het voorkomen dat er testdata ontbreekt of dat interfaces niet werken. Wachten tot alles 100% gereed is, is dan vaak geen optie. Het komt dan aan op het testmanagement en de flexibiliteit van het E2E-testteam om datgene te doen wat mogelijk is en toch te starten met een deel van de E2E-processen of delen van E2E-processen. Het is dan zaak om niet het overzicht en het doel van de E2E-test uit het oog te verliezen. De volgende activiteiten worden uitgevoerd:
Fase Implementatie: 1. 2. 3. 4. 5.
Fysieke testgevallen uitwerken. Testomgevingen inrichten. Bevindingenbeheer inrichten. Draaiboek testomgeving creëren. Testteam compleet maken.
Fase Uitvoering: 6. 7. 8. 9.
Intake uitvoeren (testomgevingen, testdata, software). Testronden uitvoeren. Bevindingen beheren. Omgevingen beheren.
Implementatie
6.1 Fysieke testgevallen uitwerken *
Naar de index
Fysieke testgevallen bestaan uit de concrete acties en controles die moeten worden vastgelegd om een logisch testgeval uit te kunnen voeren. De mate waarin logische testgevallen fysiek moeten worden uitgeschreven hangt van de situatie af. Heeft de medewerker die de testgevallen gaat uitvoeren de informatie nodig? Is er genoeg informatie beschikbaar over de precieze werking van de deelsystemen, zodat fysieke acties kunnen worden uitgeschreven? Hoe belangrijk zijn automatiseerbaarheid of herhaalbaarheid van de testen?
End to End testen
© 2014
28
Bij E2E-testen moet een aantal zaken extra aandacht krijgen: De regels voor het gebruik van testdata moeten goed worden vastgelegd, omdat er een risico is dat hetzelfde gegeven door meerdere testgevallen zal worden gebruikt en daarmee de data on - bruikbaar wordt voor anderen. Stel in het fysieke testgeval vast welk gegeven je gebruikt (klant- nummer, BSN-nummer, andere sleutel) en zorg dat er centraal een administratie is waar testers gegevens reserveren zodat testdata niet over en weer onbruikbaar wordt gemaakt. Testomgevingen kunnen niet zo maar met nieuwe data worden geladen (in verband met synchro- niciteit door de keten). Er moet daarom voor worden gezorgd dat de testdata niet opgebruikt raakt. Dit kan worden ondervangen door reserve testdata aan te maken. Onderzoek de afhankelijkheden tussen testgevallen. Als de output van testgeval 1 de input is voor testgeval 2, dan moet dit in de betreffende testgevallen en de planning tot uitdrukking komen. Definiëren van acties en precondities in de systemen en het systeemlandschap, zoals het laden van data, het draaien van achtergrondprogramma’s of het uitvoeren van voorafgaande testgeval- len. Uitwerken van het tijdspad van het testgeval. Een E2E-testgeval beslaat dikwijls enkele dagen, omdat het vaak gaat om ketens van mutaties en draaien van programma’s. Sommige uitkomsten van testgevallen worden pas zichtbaar na een paar dagen. In de dagplanning staat welke testacties er moeten worden uitgevoerd, wanneer controles moeten worden gedaan en welke programma’s moeten worden gedraaid. In het draaiboek van de testom- geving komt een planning te staan, liefst productiegelijk, van wat er in de testomgeving gaat ge- beuren en wat de systeemdatum e.d. moet zijn. Een E2E-test zal een white-box benadering moeten aannemen ten aanzien van de ketenverwer- king. Dit betekent niet dat E2E-testers de programmeercode moeten kennen maar dat per stap in de E2E-keten moet worden uitgelegd wat wordt verwacht (bijvoorbeeld: klantgegevens staan in veld X in xml bestand Y tussen systeem A en B op moment Z).
Implementatie
6.2 Testomgevingen inrichten * De inrichting van testomgevingen geschiedt bij voorkeur door de technisch beheerders. In dit stadium moet met hen nauwgezet contact worden gehouden over de voortgang van de inrichting van de omgevingen. De E2E-testmanager is verantwoordelijk voor het monitoren en bijsturen van de activiteiten. indien er niet conform planning wordt opgeleverd bespreekt de testmanager dat met de projectleiding en het management van beheerafdelingen. Werkplekken worden nu ingericht.
Implementatie
6.3 Bevindingenbeheer inrichten *
Naar de index
Zoals in elk testtraject is het bevindingenbeheer in een E2E-test van groot belang. Er is echter wel een aantal specifieke E2E-omstandigheden die bevindingenbeheer kan frustreren en die daarom voorafgaand aan de testuitvoering moeten zijn geregeld:
End to End testen
© 2014
29
De bevindingen uit de E2E-test worden in een centrale bevindingenadministratie opgenomen. Alle betrokken partijen zorgen er voor dat alle voor de E2E-test relevante informatie er in wordt bij- gewerkt, ook als het systeem waar een bepaalde bevinding op is gevonden een ander bevindingensysteem gebruikt. Er is een aantal uitstekende en gratis tools voor dit doel op de markt. De bevindingenprocedure wordt vooraf centraal vastgelegd.
6.4 Draaiboek testomgeving creëren *
Implementatie
Er moet, in nauwe samenwerking met beheerders van de betreffende systemen, een draaiboek van de testomgevingen worden opgesteld om een zo productiegelijk mogelijke situatie en voortgang van de testen te kunnen waarborgen. In dit draaiboek moeten details staan over wanneer welke achtergrondprogramma’s moeten draaien, met welke instellingen, draaidatums e.d. Voor een voorbeeld van een draaiboek: zie deel 10 “Checklists en voorbeelden” van het e-book.
In het draaiboek moeten de volgende zaken staan:
Projectmijlpalen die voor het testtraject van belang zijn, zoals “Systeemtest A gereed”. Oplevering van testdata. Opleveringen van de diverse systemen. Beheerhandelingen die een systeem en de data gebruiksklaar maken. Laden van een database, eventueel draaien van bepaalde programma’s, vullen van referentietabellen, inlezen van bestan- den, draaien conversieprogrammatuur, draaien batches, et cetera. De dagelijks uit te voeren beheerhandelingen, zoals het draaien van programma’s waarmee out- put en input wordt gegenereerd of verwerkt. Deze zaken moeten zo productiegelijk (ook in volg- orde en moment!) worden opgezet. Indien er goede redenen zijn om hiervan af te wijken moet dit worden afgestemd met beheerders en acceptanten. De uit te voeren testactiviteiten, zoals invoer, mutaties, controles met verwijzing naar de betref- fende testgevallen of groepen testgevallen. Het is niet de bedoeling dat in het draaiboek complete fysieke testgevallen komen te staan maar wel informatie als: “controleren van output richting Be- lastingdienst voor wat betreft testgeval 1,5,7”. Opleveringen van bugfix-releases (voor zover die in te plannen zijn). Specifieke beheerhandelingen zoals het maken of het terugzetten van een bepaalde back-up. Per activiteit moeten de verantwoordelijken, de volgorde, de afhankelijkheden en de status (% gereed) inzichtelijk zijn. In het draaiboek moeten de verschillende testronden tot uitdrukking komen. Testronden hebben vaak verschillende lengten (ronde 1 is vaak een soort intake ronde, ronde 2 een volledige ronde en ronde 3 en 4 hertest rondes). Afsluitende activiteiten en mijlpalen, zoals de GO/No GO beslissing.
Het draaiboek is de gemeenschappelijke referentie voor alle activiteiten in de testomgeving en de basis voor dagelijks overleg en het bepalen van de uit te voeren activiteiten per dag.
Naar de index
End to End testen
© 2014
30
6.5 Testteam compleet maken *
Implementatie
Voorafgaand aan de testuitvoering moet het testteam op sterkte worden gebracht voor de testuitvoering. Dit betekent dat testers (testers uit systeemtesten, gebruikers en/ of beheerders) worden toegevoegd. De taken worden verdeeld.
Activiteiten:
De E2E-testmanager schrijft een testhandleiding met daarin de locatie van testgevallen, syste- men, users en wachtwoorden, de bevindingenprocedure, werkplekken en een telefoonlijst met relevante medewerkers. Aftrap van de E2E-test. Hierin geeft de E2E-testmanager een presentatie over het project, de doe- len en de status. Verder worden de teamleden ingelicht over de taken en de verantwoordelijkhe- den en wordt er een demo gegeven van een testgeval. Teamleden installeren zich op hun werkplek en controleren of ze toegang hebben tot testdocu menten en systemen.
6.6 Intake test uitvoeren *
Uitvoering
Zodra delen van de omgeving beschikbaar start de testuitvoering.
Als eerste moet er een intake test worden uitgevoerd. Het volgende wordt daarin vastgesteld: Of de juiste versies zijn geïnstalleerd. Of de juiste data is geïnstalleerd. Of de juiste stuurgegevens zijn ingericht (denk aan systeemdatum, vulling van referentietabel- len). Of de juiste configuratie van toepassing is (omgevingsfactoren waardoor het systeem kan worden gebruikt zoals gepland, denk aan juiste schaling, gebruik van applicatiesoftware door andere testomgevingen). Of alle accounts aanwezig zijn en of deze de juiste toegang geven tot de systemen. Een minimale controle van de kwaliteit van de opgeleverde systemen (dit wordt ook wel een smoketest genoemd). Of de E2E-processen kunnen worden doorlopen. Stappen 6 en 7 bestaan uit het uitvoeren van het meest simpele veilige testgeval (de happyflow) per E2E-proces. De overweging hierbij is dat als deze testgevallen niet kunnen worden doorlopen, het opstarten van andere testen geen zin heeft. Het is verstandig om ook enkele recent opgeleverde bugs uit de systeemtesten te hertesten.
Naar de index
End to End testen
© 2014
31
6.7 Testronden uitvoeren *
Uitvoering
Een testronde is een cyclus waarin testdata en systeemtijden weer op een beginstand worden gezet, zodat ketens weer kunnen worden gestart.
Er zijn in de regel 4 testronden nodig: 1. Initiële ronde. Hit and run. Basisscenario’s zo snel mogelijk testen en daarmee de zwaarste fouten zo vroeg mogelijk vinden. 2. Doortestronde: blokkerende fouten moeten zijn opgelost. Het gaat in deze ronde om het dekken van het merendeel van de testgevallen in een volledige keten. Doel is om na deze ronde alle zware en belangrijke fouten te hebben gevonden. 3. Hertesten en exoten: hierin wordt de rest van de testgevallen uitgevoerd die in ronde 2 niet uitgevoerd kunnen worden en dienen de meeste en belangrijkste fouten te zijn opgelost en te worden gehergetest. 4. Regressietest: resterende bugfixes worden gehertest en een selectie van alle testgevallen wordt nogmaals uitgevoerd om regressie door wijzigingen en bugfixes te dekken. Het daadwerkelijke aantal testronden hangt af van:
Het aantal testgevallen dat tegelijkertijd in één testronde kan worden uitgevoerd. Of testen door de beschikbare tijd raken (de systeemdatum van testomgeving komt te ver in de toekomst te liggen door dagelijkse batches). Of de testdata opgebruikt is. Hoeveel opleveringen van de software nodig zijn. In hoeverre alle systemen in de infrastructuur zijn opgeleverd en klaar om te worden getest. De beschikbaarheid en kwaliteit van eventuele conversiedata. Het oplossen van belangrijke bugs. Wijzigingen in E2E-processen of systemen.
Zie deel 3 E2E-teststrategie van het e-book ∞, sectie ‘Structurering van de testuitvoering in testronden’, voor een meer gedetailleerde beschrijving van de procedure rond testronden.
6.8 Bevindingen beheren *
Uitvoering
In een E2E-test kunnen bevindingen net zo complex zijn als de infrastructuur, de E2E-processen of de wisselwerking tussen beide. Het is vaak niet eenvoudig om aan te wijzen waar de fout zit en hoe iets opgelost moet worden. Bevindingen kunnen aanleiding geven tot discussie over verantwoordelijkheid, oplossingen of zelfs noodzaak om iets op te lossen. Van een E2E-tester mag worden verwacht dat zij informatie verschaft over mogelijke oorzaken van een fout en dat zij meedenkt met de analyse en de oplossing.
De volgende uitgangspunten worden gehanteerd:
Stel een E2E-bevindingenbeheerder aan. Dit kan de E2E-testmanager zelf zijn, of een ander teamlid wanneer de werkzaamheden een dagtaak worden. De bevindingenbeheerder houdt de
Naar de index
End to End testen
© 2014
32
uitvoering van het bevindingenproces in de gaten en waakt over de betrouwbaarheid van de ge- gevens. Bevindingenbeheer begint met het volledig en duidelijk opschrijven van bevindingen. Bevindingen horen de volgende zaken eenduidig en uniform te beschrijven: a. Omschrijving: korte logische omschrijving. Bijvoorbeeld: “na overlijden tijdens lopende muta tie wordt de mutatie gewoon uitgevoerd”. b. Uitgangssituatie: gebruikte data, testomgeving, dag, testgeval, stap in het testgeval waar vanuit de bevinding zich voor deed (bijvoorbeeld: “polis heeft een mutatie op looptijd met terugwerkende kracht gekregen, dagwerk is gedraaid”). c. Logische omschrijving van de test: het doel van het testgeval (bijvoorbeeld: “overlijden klant met lopende mutaties”). d. Handeling: in welk systeem wordt welke actie uitgevoerd (bijvoorbeeld: “in het klantsysteem voer ik bij datum overlijden dag vandaag in”). e. Verwachting: het verwachte resultaat. (bijvoorbeeld: “ik verwacht na dagwerk dat vanuit het klantsysteem, de polis in het polissysteem is geannuleerd en de mutatie ook niet is ver- werkt”). f. Resultaat: de afwijking van het verwachte resultaat (bijvoorbeeld: “de mutatie staat nog open en wordt alsnog verwerkt. Resultaat: er vinden correctiebetalingen plaats”). g. Omgeving en systemen, eventueel aangevuld met loggingsbestanden, tussenrapporten e.d. Voortgang in het oplossen: in een E2E-test vallen bevindingen gemakkelijk tussen wal en schip. De verantwoordelijkheid voor de bevindingen wijzigt omdat vaak niet meteen duidelijk is wat de oorzaak is en wie de bevinding moet oplossen. De bevindingenbeheerder bewaakt bevindingen en signaleert stagnaties aan de E2E-testmanager. De bevindingenadministratie is een administratie en niet primair een communicatiemiddel. Indien dit laatste het geval is, is de kans groot dat de voortgang stagneert: medewerkers communiceren dan namelijk niet meer direct met elkaar. De E2E-testmanager organiseert periodiek een bevindingenoverleg. De E2E-board fungeert als klankbord en stuurgroep functioneren. Niet elke bevinding wordt met de E2E-board besproken worden, maar de leden kunnen een belangrijke rol spelen in de analyse, prioriteren en besluitvorming rond bevindingen.
Uitvoering
6.9 Omgevingen beheren * Uitgangspunt bij het beheren van de omgevingen is het draaiboek voor de testomgeving. De E2E-testmanager heeft dagelijks contact met de systeembeheerders om de status van activiteiten, zoals het draaien van programma’s of het laden van data, nauwlettend in de gaten te houden. Het draaiboek wordt aangepast aan de praktijk en teruggekoppeld aan de betrokken partijen. Consequenties voor de testplanning en de voortgang worden door de E2E-testmanager uitgewerkt en vertaald in maatregelen en rapportages.
De E2E-testmanager houdt een logboek bij van de testomgeving. Hierin wordt informatie rond verstoringen genoteerd: over de aard, tijdstip, duur, impact en oplossing van verstoringen. Het logboek kan belangrijke informatie bevatten voor latere testronden of projecten.
Naar de index
End to End testen
© 2014
33
7. Evalueren exitcriteria *
Beheer
Evalueren van exitcriteria is een activiteit die periodiek, in nauwe betrokkenheid met het gehele testteam, moet worden uitgevoerd. Doel is om vast te stellen in hoeverre de exitcriteria gehaald worden, binnen de limieten van tijd, geld, scope en kwaliteit. Evaluatie van exitcriteria vindt al vanaf het begin plaats: de E2E-testmanager houdt de ontwikkelingen en resultaten bij die van invloed zijn het halen van de einddoelen. Gaandeweg het traject wordt het evalueren steeds concreter uitgevoerd. De E2E-testmanager verzamelt de resultaten en vertaalt deze in voortgangsrapportages. E2E-testen geeft inzicht in de kwaliteit van E2E-processen en de mate waarin deze worden ondersteund door de systeeminfrastructuur. Als het gaat om exitcriteria van de E2E-testen spelen beheerprocessen een speciale rol. Testers zijn namelijk niet gewoon om hier een oordeel over te vormen. Beheerprocessen zijn echter, vaak niet onbelangrijke, E2E-processen. Exitcriteria met betrekking tot beheerprocessen betreffen de mate waarin beheeractiviteiten volgens planning kunnen worden uitgevoerd. Het gaat dan om technisch beheer en functioneel beheer en in hoeverre hier zaken spelen die de voortgang en het vertrouwen rond inproductiename kunnen beïnvloeden. Denk hierbij aan een onduidelijk proces rond het draaien van achtergrondprogramma’s, slechte communicatie of een grote werklast bij medewerkers.
Activiteiten in de fase Evalueren exitcriteria: Metrieken analyseren. Het evalueren van de exitcriteria bestaat uit de analyse van ten minste de volgende gegevens: a. Aantal testgevallen per testcluster, onderscheiden in aantal uitgevoerd, aantal akkoord en aan- tal nog uit te voeren. b. Tijd: uren en doorlooptijd tot nu toe besteed vergeleken met de planning. c. Bevindingen: aantallen per testcluster en per prioriteit: aantallen ingediend en opgelost. Ont- wikkelingen door de tijd (aantallen per week ingediend en opgelost). Voortgangsoverleg met het testteam. In het periodieke voortgangsoverleg geven de testers per testcluster tekst en uitleg over de voortgang en knelpunten. De E2E-testmanager verzamelt deze informatie. Evalueren met E2E-board. De E2E-board is een belangrijke sparringpartner bij het beoordelen van de status van de exitcriteria. Voortgangsrapportage. In voortgangsrapportages vat de E2E-testmanager de resultaten van de evaluatie samen en geeft de status per productrisico. Daarnaast worden eventuele maatregelen benoemd. Projectoverleg. In het projectoverleg geeft de E2E-testmanager uitleg over de status van de exit criteria. Afstemmen met acceptanten. Indien duidelijk wordt dat voor een bepaald E2E-proces de exitcrite- ria niet worden gehaald, moeten keuzes worden gemaakt voor de einddatum, scope of kwaliteit. In het projectoverleg of de E2E-board kunnen al beslissingen worden genomen, eventueel moeten deze nog voorgelegd worden aan de betreffende acceptanten. Evalueren. De activiteiten herhalen zich tot de exitcriteria zijn gehaald.
Naar de index
End to End testen
© 2014
34
8. Afronding Zodra de fase Uitvoering is beëindigd moeten er nog een aantal activiteiten worden uitgevoerd.
Beheer
Activiteiten: 1. Verzamelen productie-ervaringen. 2. Evalueren. 3. Eindrapportage. 4. Bijwerken E2E-testware. 5. Overdragen aan E2E-organisatie. 6. Ceremonieel afsluiten.
1. Verzamelen productie-ervaringen. ** Het succes van het project en het testtraject blijkt pas in productie. Dan pas weten we zeker of de E2E-processen goed worden ondersteund door het systeemlandschap en of de gekozen testaanpak tot het gewenste resultaat heeft geleid. Het is daarom van belang op de hoogte te zijn van eventuele productieproblemen. Zijn er fouten gemist? Hebben we de juiste risico’s onderkend en goed afgedekt? Ook hier kan de E2E-board zijn waarde bewijzen: de leden hebben namelijk nauwe banden met de werkvloer. Ervaringen moeten worden meegenomen in de evaluatie. 2. Evalueren van het testtraject. ** Een evaluatie van het testtraject moet gebeuren in samenwerking met het E2E-testteam, de E2E-board maar ook met de belangrijkste belanghebbenden rond het testtraject, zoals acceptanten en beheerders. Een evaluatie vindt idealiter plaats in een samenkomst waar alle belanghebbenden aanwezig zijn. Dit zal niet altijd kunnen. In die gevallen kan de samenkomst worden opgedeeld naar E2E-proces, aangevuld met interviews of een vragenlijst. De evaluatie van het E2E-testproject kan worden aangepast aan de specifieke context: een kleine organisatie, een klein project of een regulier onderhoudsproject behoeven geen uitvoerige evaluatie. Hier kan de E2E-testmanager volstaan met het schrijven van een rapport op basis van een aantal gesprekken en een presentatie hiervan aan belanghebbenden. 3. Eindrapportage.** De volgende rapportages kunnen worden onderscheiden:
Vrijgaverapport: in eerste instantie wil de organisatie inzicht in wat in productie gaat. Dit is het klassieke testrapport, waarin inzicht wordt gegeven in de systeemkwaliteit en de mate waarin E2E-processen worden ondersteund. Dit rapport geeft de grondstof voor anderen om te besluiten tot inproductiename. Rapporten voor een specifiek publiek: bij een grote E2E-keten wordt onderscheid gemaakt tussen verschillende groepen subprocessen zoals commercie, backoffice en infrastructuur. Deze hebben elk eigen acceptatiecriteria. Daarnaast heeft de organisatie belang bij inzicht in hoe er is gewerkt en wat toekomstige projec- ten kunnen leren uit het huidige project. Belangrijke resultaten en conclusies uit de evaluatie moeten worden verwerkt in het testprocesrapport. Zie ook de fase Beheer over rapporteren voor meer uitleg.
Naar de index
End to End testen
© 2014
35
4. Bijwerken E2E-testware ** De testproducten moeten worden bijgewerkt zodat er een bibliotheek ontstaat voor later gebruik. Men moet (later) kunnen traceren hoe en wanneer welk aspect is getest. Dit kan van belang zijn voor het E2E-testteam (om discussies te beslissen over verantwoordelijkheid en aansprakelijkheid in geval van productieproblemen) of ten aanzien van controles en audits. 5. Overdragen aan E2E-organisatie ** De testware moet nu worden overgedragen aan de beheerorganisatie. Dit kan de centrale testafdeling zijn, de beheerafdeling, het E2E-testcentrum indien aanwezig of wellicht het huidige E2E-kernteam. In ieder geval moet worden aangesloten bij eventuele procedures voor aanlevering van testware. 6. Ceremonieel afsluiten ** Ten slotte, en dit kan goodwill kweken, moet het testtraject feestelijk worden afgesloten. Het is van belang dat na een druk en intensief traject een moment wordt gekozen om het einde en de successen te vieren, om de periode af te sluiten en te zorgen voor een goede laatste herinnering.
Wordt vervolgd... met het onderwerp: Checklists en voorbeelden De checklists kunnen worden gebruikt door testmanagers en testcoördinatoren. Het gaat o.a. om checklists voor kwaliteitsattributen, product- en projectrisico’s en randvoorwaarden voor het testtraject. De checklists kunnen ook door ieder andere belanghebbende worden gebruikt. Daarnaast wordt een aantal praktijkvoorbeelden gegeven van een draaiboek, een testplan en een voortgangsrapport.
Naar de index
End to End testen
© 2014
36
