DETAILTESTPLAN. Project Het Nieuwe Studielink. Fase Finale Ketentest. Versie 1.01

Transcriptie

1 DETAILTESTPLAN Project Het Nieuwe Studielink Fase Finale Ketentest Versie 1.01 Datum 23 juli 2018 Auteur Peter van Kan I

2 VERSIE INFORMATIE Versie Datum Bijzonderheden Auteur juni 2018 Eerste concept Peter van Kan juli2018 Na review Qdelft / Manon Blom / Walter Groen Peter van Kan juli 2018 Definitief Peter van Kan juli 2018 Aanpassing op testbaarheid & kleine typo s Peter van Kan VERZENDLIJST Naam Manon Blom Walter Groen Jorrit Miedema Stanley Latumeten Jasper Jordans Machiel Pronk Désirée Schipper Eric van Beek Alex van der Meijs Jos van Aalderen Peter van Kan Bedrijf/Functie Projectleider Implementatie & Communicatie, Stichting Studielink Projectmanager, Stichting Studielink Test coördinator Stichting Studielink Tester Stichting Studielink Tester Stichting Studielink IT-Manager Stichting Studielink Product Owner Stichting Studielink Projectleider HNS, QDelft Scrummaster Bouw, QDelft Test coördinator QDelft Testmanager Stichting Studielink II

3 1 Management samenvatting Testdoelstelling en opdracht Dit detailtestplan (DTP) volgt op het detailtestplan Detailtestplan tweede ketentest v1.03 en is een verfijning op het eerder opgestelde Master Testplan (MTP) versie1.0 ( ) gericht op de finale ketentest. Voor algemene onderwerpen welke niet specifiek zijn opgenomen in dit detailtestplan wordt naar deze twee documenten verwezen. De doelstelling van het detailtestplan(dtp) Finale Ketentest, verder aangeduid als FKT, is het geven van inzicht in de scope en aanpak van de ketentest activiteiten ten behoeve van het project Het Nieuwe Studielink, verder afgekort als HNS. Naast stuurinstrument is dit testplan ook een belangrijk middel in de communicatie en afstemming rondom de voorgenomen testactiviteiten. In het test plan wordt antwoord gegeven op vragen rondom waarom, wat, hoe, wanneer en wie. De opdracht aan het testproject behelst het coördineren van de FKT en de in de scope nader te benoemen onderdelen en functionaliteiten. Het systeem, HNS, dient zodanig worden getest dat er een solide en werkbare verwerkingsketen kan worden aangetoond op basis van de toegepaste bedrijfsprocessen. Doel is om aan de hand van de testresultaten te komen tot een gefundeerd advies omtrent het accepteren van de opgeleverde functionaliteit en daarmee groen licht te kunnen geven voor de volgende fase in het implementatie project (go/nogo). Korte beschrijving testaanpak De finale ketentest staat gepland in de periode 6 t/m 18 augustus. De bestaande processen binnen Het Nieuwe Studielink, welke een relatie hebben met of als trigger fungeren voor gekoppelde systemen, zijn het vertrekpunt van de ketentesten. Het doel van de ketentest is zekerheid te krijgen over de attributen functionaliteit, bruikbaarheid en betrouwbaarheid tussen Het Nieuwe Studielink, de aangesloten Student Informatie Systemen en de aangesloten ketenonderdelen. Deze laatste systemen worden getest via interfaces waarbij de reactie vanuit het gekoppelde systeem wordt benaderd als een blackboxtest. Dat wil zeggen dat er geen (functionele) toetsing plaats vindt op de gekoppelde systemen, maar er alleen gekeken wordt naar hun verwerking van invoer en uitvoer. De testscripts worden uitgevoerd met een diversiteit aan invoervariabelen waarbij wordt getoetst of het geheel volgens verwachting reageert, of alle componenten binnen de ketens goed samenwerken en of de bestaande bedrijfsprocessen uitvoerbaar zijn. De finale ketentest bevat essentiëel rework, essentiële userstories en opgeloste bevindingen uit ketentest 2. De voortgang (aantallen uitgevoerde testgevallen, de dekkingsgraad) wordt bijgehouden in een z.g. testmonitor. Bevindingen worden bijgehouden in Jira welke beheerd wordt door QDelft. Deze laatste vormt een belangrijk component in de regievoering van de testactiviteiten. 3

4 Te realiseren resultaten Resultaat Detail testplan Opgestelde testscenario s Ingerichte testmonitor FKT uitgevoerde en afgeronde FKT Document DTP Testscenario s FKT Monitor FKT Eindrapportage Opleverdatum 1 juli juli aug aug 2018 Kwalitatieve doelstellingen Elk testgeval dient minimaal door 10 instellingen (met verschillende SISsen) te worden afgerond en van ieder geval zal duidelijk moeten zijn of het geteste proces de dagelijkse procesgang voldoende ondersteund. Momenten van go/no-go beslissingen De testcoördinator of zijn vervanger zorgt er periodiek voor dat er een testrapportage wordt opgesteld. Dit rapport wordt primair aangeboden aan de projectleider maar verzonden aan het gehele project. Aan het eind van het hier genoemde ketentesttraject wordt een eindrapport opgesteld, met daarin opgenomen een gefundeerd vrijgave advies. 4

5 Inhoudsopgave 1 MANAGEMENT SAMENVATTING ACHTERGROND EN DOELSTELLING DOELSTELLING VAN DIT PLAN OPDRACHTGEVER OPDRACHT RELATIES MET ANDERE TESTTRAJECTEN VRIJGAVE ADVIES DELIVERABLES SCOPE TESTACTIVITEITEN FUNCTIONELE SCOPE BUITEN SCOPE REGRESSIEPUNTEN ORGANIEKE SCOPE TESTVOORBEREIDING STARTVOORWAARDEN Entrycriteria Testuitvoering OPBOUWEN TESTLANDSCHAP TESTSCENARIO S BIJ DE KETENTESTEN RESOURCES INSTELLINGEN, SIS-LEVERANCIERS EN DUO (INDICATIEF) STUDIELINK (INDICATIEF) QDELFT ROLLEN EN VERANTWOORDELIJKHEDEN TESTSTRATEGIE PROCESTEST GLOBALE TESTAANPAK OMGEVING FREEZE BEVINDINGEN PROCEDURE PLANNING BIJLAGE A: CONTACTGEGEVENS CONTACTPERSONEN BESCHIKBAARHEID

6 2 Achtergrond en doelstelling 2.1 Doelstelling van dit plan De doelstelling van het detailtestplan (DTP) Finale Ketentest (FKT) is het geven van inzicht in de scope en aanpak van de ketentest activiteiten die uitgevoerd worden tijdens de FKT in de periode van 4 augustus 18 augustus 2018 ten behoeve van het project Het Nieuwe Studielink, verder afgekort als HNS. Naast stuurinstrument is het testplan ook een belangrijk middel in de communicatie en afstemming rondom de voorgenomen testactiviteiten. In het test plan wordt antwoord gegeven op vragen rondom waarom, wat, hoe, wanneer en wie. 2.2 Opdrachtgever De opdrachtgever is de Stichting Studielink, in dit project vertegenwoordigd door Manon Blom(projectleider) en Walter Groen(projectmanager). 2.3 Opdracht De opdracht aan het testproject behelst het coördineren van de finale ketentest van de in de scope nader te benoemen onderdelen en processen. Het systeem, HNS, dient zodanig te worden getest dat er vanuit businessperspectief een solide en werkbare verwerkingsketen kan worden aangetoond. Doel is om aan de hand van de testresultaten te komen tot een gefundeerd advies omtrent het accepteren van de opgeleverde functionaliteit en daarmee groen licht te kunnen geven voor de volgende fase (go/nogo). 2.4 Relaties met andere testtrajecten 1 Gebruikers Acceptatietest Q Entrycriterium. Dient afgerond te zijn. 2 Ketentest Q Entrycriterium. Dient afgerond te zijn. 3 Pre-testen koppelingen op Ketentest 2 Entrycriterium. Dient afgerond te zijn. 4 GAT/Ketentest Entrycriterium. Dient afgerond te zijn. Om de kwaliteit van de communicatie tussen de systemen in de keten te kunnen beoordelen, vinden er drie ketentesten plaats. Dit houdt verband met de gehanteerde ontwikkelmethode waarbij de totale functionaliteit iteratief wordt opgeleverd. Onderstaande figuur geeft deze ketentesten weer. De eerste ketentest heeft plaats gevonden in de periode van 19 april 2018 tot en met 18 mei De tweede ketentest heeft plaats gevonden in de periode 18 juni 6 juli Op basis van de in dit plan benoemde finale test wordt de definitieve go-live beslissing genomen. De finale ketentest staat gepland in de periode van 6 t/m 18 augustus

7 2.5 Vrijgave advies Aan het einde van de ketentestperiode wordt een vrijgave advies opgesteld. Naast dit advies voor vrijgave bevat dit document ook aanduidingen qua restpunten (al dan niet opgenomen in Jira). De acceptatiecriteria vormen de basis van het vrijgave-advies. Deze criteria vormen de meetlat op basis waarvan het uiteindelijke advies/testrapport kan worden opgemaakt. Het volgende aantal bevindingen is bij acceptatie voor vrijgave nog toegestaan: Type Omschrijving Toegestaan Blokkerend Groot Midden Klein Blokkerend voor procesgang. Veroorzaakt een algehele uitval (crash) van het systeem c.q. functioneel onderdeel. Er is geen work-around beschikbaar. Frustreert het geteste (werk)proces. Moet opgelost worden, maar tijdelijke workaround is beschikbaar Functionele onvolkomenheid. Het uitvoeren van de productieprocessen is eventueel mogelijk met een goede work around en/of een aanvullende handleiding Schoonheidsfout. Het uitvoeren van de productieprocessen is mogelijk 0 (acc criteria op nazien) 2(acc criteria op nazien) 15(acc criteria op nazien) 40(acc criteria op nazien) 7

8 2.6 Deliverables Aan het einde van de testperiode zijn onderstaande producten beschikbaar: Deliverable Detail testplan Draaiboek finale ketentest Testgevallen finale ketentest Bevindingen administratie in Jira Testrapportage met vrijgaveadvies welke dusdanig van opzet zal zijn dat deze als basis kan dienen voor besluitvorming met betrekking tot de formele goedkeuring over overgang naar de volgende fase. Door Testmanager Project en testteam Testteam Allen Testmanager / testteam 8

9 3 Scope testactiviteiten De testinspanningen in het kader van de FKT hebben met nadruk een functionele scope primair benaderd vanuit businessperspectief. Dat wil zeggen dat niet alleen de infrastructurele keten wordt gevalideerd, maar ook of de onderliggende procesketen in zijn geheel zonder problemen kan worden doorlopen. Voor deze FKT zijn de laatste berichten toegevoegd die minimaal benodigd zijn om in oktober 2018 live te kunnen gaan met Het Nieuwe Studielink. De berichten die als geheel beschikbaar zijn staan hieronder weergegeven. 3.1 Functionele scope BRON-HO broker, DUO - generiek doorsturen - aanpassingen ten behoeve van de Open Universiteit. Digitale Machtiging (DIM) Gebruik van DigiD (stub) De finale ketentest volgt de complete procesketen. Daarmee zijn de processen welke in ketentest 1 en 2 zijn gevolgd nog steeds de startvoorwaarde voor de totale keten(s). Onderstaande processen komen ook in de finale ketentest voorbij: Inschrijving Ned student Bevestiging inschrijving Uitschrijven Bevestiging identiteit Betaalwijze Bevestiging vooropleiding Collegegeld betaald Digitale machtiging De finale ketentest volgt qua scope het releaseplan Q3 (Releaseplan Q Release Studielink v0.2), zodanig dat instellingen het berichtenverkeer tussen Het Nieuwe Studielink, DUO en het SIS, banken (DIM) en DigiD kan testen in de keten. Daarbij dient te worden vermeld dat voor DigiD nog gebruik gemaakt wordt van een stub. Het testen van de IND/DVS zal post-livegang worden getest en valt daarmee hier dus buiten de scope van de finale ketentest. Er wordt naar gestreefd om het testen van het DIM proces tegen de testomgeving van banken uit te voeren. Dat betekent dat niet altijd meer de DIM-stub gebruikt hoeft te worden. Vooralsnog bieden alleen ING en ABN-Amro deze mogelijkheid. Omdat het koppelvlak met de banken per instelling kan worden geschakeld kunnen de testomgeving en stub onafhankelijk van elkaar gebruikt worden. Secundaire doel is de gebruikersinterface die relevant is voor de berichten uit de ketentest beschikbaar te hebben. 9

10 Daarnaast bevat de FKT de navolgende berichten: Berichttype Msg03 Msg04 msg05 Msg06 Msg07 Msg08 Msg10 Msg19 Msg20 Msg22 Msg30 Msg31 Msg34 Msg35 Msg37 Omschrijving Inschrijving Uitgaand - Gegevens Nederlands adres (address) ; bevestiging identiteit Uitgaand - Gegevens Buitenlands adres (address) Onderhouden persoonsgegevens Wijzigen correspondentiegegevens student Wijzigen vooropleidingsgegevens Onderhouden betaalwijze. Wordt aangepast naar aanleiding van hergebruik DIM in sprint 3 van Q Verificatie vooropleiding. Status Collegegeld Bevestiging collegegeld Mededeling Wijzigen Student ID. Bevestiging van verzoek tot inschrijven. Bevestigen uitschrijving. Status (verzoek tot) Inschrijving versturen in KVA en status over waarde N voor status aanvullende eisen en voor status te verrichten werkzaamheden. Indienen verzoek tot inschrijving door Onderwijsinstelling Verzoek wijzigen inschrijving. Overlijden student Msg47 Digitale Machtiging (stub). Aangepast naar aanleiding van hergebruik DIM in sprint 3 van Q Msg48 Msg50 BRON- HO:DUO DUO- Identificeren Persoon DUO-wijzigen Persoonsgegevens DUO Vooropleiding Herstelbericht van foutief ingetrokken, geannuleerd of uitgeschreven verzoek óf datum van uitschrijving Wijzigen inschrijfvolgnummer Indicatie Soort Collegegeld, Onderwijsdeelname, Onderwijsresultaat Identificeren Persoon Terugkoppelen wijziging person Verstrekken vooropleiding gegevens 10

11 Herinschrijven (msg25) wordt naar verwachting eind 2018 jaar opgeleverd en kan begin volgend jaar worden getest. 11

12 3.2 Buiten scope De volgende onderwerpen vallen buiten de scope van de finale ketentest: - Testen die noodzakelijk zijn als gevolg van de technische consequenties van de migratie naar HNS (conversie en performancetesten). Deze tests worden als onderdeel van het mastertestplan apart getest en benoemd in separate planvorming. - Het toetsen van het proces voor de digitale verblijfsaanvragen studie(dvs). Deze wordt in een later stadium getest (post-livegang). - Selectie en Plaatsing. Deze functionaliteit wordt als S&P test post-livegang getest en staat nu gepland voor 13 november Alle functionaliteiten welke vallen onder de inrichting en gebruik van de dashboard functionaliteit. (deze zijn reeds in productie genomen). 3.3 Regressiepunten Het Nieuwe Studielink wordt iteratief gebouwd. Dat betekent dat functionaliteiten in delen worden opgeleverd en getest. Gezien het hier een finale ketentest betreft zullen alle eerder opgeleverde (keten afhankelijke) functionaliteiten ook in deze finale test nog een keer aan bod komen (regressietesten) teneinde de volledige procesketens af te dekken. Daarnaast zijn veel van de eerder opgeleverde functies vaak het begin voor de nieuw opgeleverde processen of onderdelen. 3.4 Organieke scope Voor de finale ketentest geldt dat deze wordt uitgevoerd door alle instellingen tenzij. Daarmee is deelname dus zeer gewenst tenzij er een goede reden is voor een instelling dit niet te doen. Instellingen die niet deelnemen aan de FKT geven daarmee aan zonder uitzondering akkoord te gaan met de resultaten en acceptatieuitspraken van de wel deelnemende instellingen. 12

13 4 Testvoorbereiding 4.1 Startvoorwaarden Onderstaande bevat de voorwaarden om te kunnen starten met de finale ketentest: Entrycriteria Het totaal benodigde testlandschap is werkend. De testomgevingen bij zowel QDelft (omgeving K) als bij de instellingen zijn volledig beschikbaar en de benodigde componenten zijn dusdanig geconfigureerd dat al het gewenste berichtenverkeer doorgelaten wordt. Binnen de K-omgeving van Qdelft moet een werkende technische koppeling zijn met het SIS van deelnemende instellingen, DUO, banken en een stub voor DiGiD. De koppelingen moeten dusdanig zijn getest dat het gewenste berichtenverkeer voor de FKT wordt verwerkt. Werkende en in de ketenomgeving opgenomen testomgeving van DUO ten behoeve van het testen van de Verzoeken tot Inschrijving (VtI) van Nederlandse studenten. Positief resultaat op de controle van berichten binnen de verschillende SIS-sen. Als bepaalde berichten niet werken voor bepaalde SIS-sen, dan dient de software hierop te worden aangepast. Omdat in dat geval oplevering van de bijgestelde software later beschikbaar komt is het eventueel aanpassen van de testscope hierop de enige mogelijk oplossing. Een positieve vrijgave van de Functionele Acceptatietest op de 1 ste en 2 de sprint van Q3, uitgevoerd door het Testteam van Studielink voorafgaand aan de ketentest. Autorisatieprofielen voor beheer en testgebruikers zijn ingeregeld (blijven gehandhaafd vanuit ketentest 1 en 2). Geactualiseerde en bruikbare testscenario s en testgevallen zoals reeds gebruikt in ketentest 1 en 2. Alle betrokkenen (testers, oplossers) hebben gedurende de testperiode toegang tot de Jira bevindingenadministratie Testuitvoering Testcoördinatoren en testers (van de instellingen, SIS-leveranciers, QDelft en Studielink) dienen beschikbaar te zijn gedurende de gehele ketentestperiode. Contactpersonen ketenpartners zijn deskundig en beschikbaar. QDelft heeft een deskundig beheerteam beschikbaar om incidenten (waar nodig direct) op te pakken. SIS-leveranciers: Alle deelnemende SIS-en hebben een dedicated testomgeving beschikbaar die gebruikt kan worden voor de ketentest. Elke deelnemende instelling heeft een dedicated testomgeving beschikbaar welke is aangesloten op het ontkoppelpunt (OKP) van de ketenomgeving. Alle omgevingen in de keten moeten een bevroren status hebben, in die zin dat er gedurende de ketentest periode geen functionele of technische mutaties mogen plaatsvinden, anders dan die noodzakelijk zijn voor het (voortzetten van het) testen zelf. Dit alleen na accordering van het testmanagement. 4.2 Opbouwen testlandschap Om te kunnen testen op de ketentestomgeving is het SIS en de instelling al eerder ten behoeve van ketentest 1 en 2 aangesloten op het ontkoppelpunt van de ketentestomgeving (omgeving K), die is ingericht is door QDelft. De finale ketentest wordt uitgevoerd op dezelfde omgeving als waar de eerdere ketentesten hebben plaatsgevonden, zijnde een speciaal daarvoor ingerichte HNS omgeving algemeen aangeduid als Omgeving K. 13

14 Het totale landschap ziet er schematisch als volgt uit: 4.3 Testscenario s bij de ketentesten De testuitvoering vindt plaats aan de hand van testscenario s conform de procescyclus methodiek. Daarbij wordt HNS getoetst waarbij de van toepassing zijnde werkprocessen worden gevolgd. Kwaliteitsattributen die hierbij van toepassing zijn, zijn functionaliteit, bruikbaarheid, juistheid en betrouwbaarheid (ISO9126/25010). Waar mogelijk wordt daarbij gebruik gemaakt van uitvoervoorspelling. De testscenario s worden door Studielink samengesteld als vervolg op het testen van de separate userstories (de FAT) conform de in de scope beschreven functionele dekking. Voorafgaande aan de start van de testen worden deze scenario s beschikbaar gesteld aan de deelnemende instellingen. Zij zullen vervolgens de volledige procesketens gaan testen benaderd vanuit de procesgedachte waarbij alle van toepassing zijnde user-stories achter elkaar worden gezet (de procesketen). Dat is wat mij betreft nog de vraag (zoals ook gisteren aangegeven bij het projectteamoverleg). Daarnaast zal vanuit Studielink worden gecommuniceerd welke functionaliteit in deze finale ketentest getest kan worden, zodat men zelf, voor de eigen instelling, testscenario's/situaties kan bedenken en uitvoeren. In de ketentestomgeving worden geen werkelijke studentgegevens gebruikt. Er zal gebruik gemaakt worden van het DUO-adresboek om teststudenten in te zetten tijdens de ketentest. Deze data is geanonimiseerd zodat de gegevens niet herleidbaar zijn naar natuurlijke personen. 14

15 5 Resources De voor de ketentest benodigde resources zijn onderverdeeld op instellingen, SIS-leveranciers en DUO alsmede de resources vanuit de testondersteuning. De ketentest is bij uitstek een test om aan de kant van de instelling te laten uitvoeren door iemand in de rol van functioneel beheerder Studielink of het inschrijfproces binnen het van toepassing zijnde student informatie systeem (SIS). 5.1 Instellingen, SIS-leveranciers en DUO (indicatief) Betrokken medewerkers dienen tijd te reserveren om de ketentest te kunnen uitvoeren. Deze testcapaciteit is een inschatting van benodigde inzet voor de FKT. Onderstaande tabel bevat de verwachte benodigde tijd in uren per SIS-leverancier en per deelnemende instelling. Vooralsnog verwachten we dat ook voor de FKT de inzet beperkt zal zijn tot de functioneel beheerder met inhoudelijke kennis van zowel het SIS als Studielink. Wie Functie Ketentest voorbereiding Ketentest uitvoering Ketentest afronding SIS-leverancier Beheerder Studielink Instelling Functioneel beheerder Technisch beheerder 4 1 (standby) 0 Finance afdeling 0 pm 1 0 DUO DUO-medewerker 8 8 (incidenten) Studielink (indicatief) Wie Functie Ketentest voorbereiding Ketentest uitvoering Ketentest afronding Projectmanagement Projectmanagement Testteam Testcoördinator Tester Beheer ICT-manager Kenniscentrum Dit is afhankelijk hoe diep de instelling wil testen. Bijvoorbeeld stoppen bij het DIM-bericht in het SIS of deze laten beoordelen door de financiële administratie. 15

16 5.3 QDelft Doen wat nodig is om de test te laten slagen. Onderstaande inzet is indicatief. Wie Functie Ketentest voorbereiding Ketentest uitvoering Ketentest afronding Projectmanagement Projectmanagement Testteam Testcoördinator Beheer Beheerder Bouwteam Analyse bevindingen Rollen en verantwoordelijkheden Binnen de hiervoor benoemde inzet zijn verschillende rollen vertegenwoordigd. De taken van de vijf belangrijkste zijn: Rol QDelft Taken De maker(s) van de te testen objecten: Leveren van het product tbv FKT, dat aan de specificaties en andere kwaliteitsafspraken voldoet Herstel van geconstateerde fouten Adequaat oplossend acteren in geval van calamiteiten Opleveren en beheren van de ketentestomgeving Algemeen beheer over de bevindingenadministratie (Jira) Projectleider De eindverantwoordelijke voor het bereiken van de projectresultaten: Sturing op de randvoorwaarden / startvoorwaarden Bewaken van tijdige levering van te testen objecten Goedkeuren van plannen en rapportages Voorbereiden en voorzitten van het projectteamoverleg Oplossen van knelpunten Testmanager De verantwoordelijke voor een deugdelijke testvoorbereiding, -uitvoering en rapportage: Opstellen van het testplan (dit plan) Aanleveren van templates/documentatie met betrekking tot het testen Opstellen en bijhouden van testdraaiboeken 16

17 Inplannen van testactiviteiten Bewaken van de testvoorbereiding en uitvoering Rapporteren over de testvoortgang en resultaten Monitoren op het laten opvolgen van gevonden issues Waar mogelijk dichtlopen van gevallen gaten Tester Studielink De specialist in één of meer Studielink processen en functionaliteiten: Leveren inhoudelijke bijdrage aan testplannen en aanpak Voorbereiden en opstellen van testscenario s en -cases Rapporteren over de eigen testuitvoering Bijwonen van de bijeenkomsten van het testteam Tester Instelling / SIS-leverancier De specialist in één of meer Studielink processen en functionaliteiten: Uitvoeren van testscenario s en -cases Registeren van testvoortgang (testmonitor) en gevonden fouten (Jira) Rapporteren over de eigen testuitvoering Aanleveren adviesrapportages 17

18 6 Teststrategie De teststrategie legt vast wat er met welke zwaarte wanneer getest gaat worden en is erop gericht om zo vroeg mogelijk de belangrijkste fouten te vinden tegen de minste kosten, dus met optimaal gebruik van de beschikbare capaciteit en tijd. De teststrategie komt tot uitdrukking in de opgestelde testscenario s. 6.1 Procestest De Studielink processen vormen de basis voor de te gebruiken testscenario s en worden uitgevoerd als procescyclustest. Deze richt zich op de integratie van de administratieve organisaties binnen de instellingen en de totale keten van het Studielink informatiesysteem. Getest wordt of alle "procespaden" daadwerkelijk uitvoerbaar zijn en door het gehele keten op juiste wijze wordt afgehandeld. Daarbij wordt tevens getest of de berichten op de juiste manier worden uitgevoerd. De planmatige uitvoering van de ketentest aan de hand van voorbereide scenario s geeft een behoorlijke indruk van de kwaliteit van de totale keten. De praktijk heeft echter geleerd dat deze tests het beeld niet compleet maken. Het staat instellingen daarom vrij aanvullend aan de afgestemde scenario s ook uit vrije hand tests uit te voeren. Hiertoe zal te voren inzicht worden gegeven in welke functionaliteiten testbaar zijn in deze ketentest. In de testtechniek staat dit type test bekend als exploratorytesting. Onderwerpen voor exploratorytesting ontstaan tijdens de uitvoer van het testen ( als dit kan, kan dat dan ook? ). Testgevallen welke op deze wijze ontstaan, kunnen eventueel worden uitgewerkt tot een formeel testgeval en zo opgenomen worden in het testarchief t.b.v. hergebruik. Daarnaast wordt gevraagd om, bij een bevinding, een detailleerde beschrijving te geven van de gevolgde stappen, gebruikte gegevens en het resultaat. Deze gegevens leveren noodzakelijke input voor het eventueel reproduceren van bevindingen door de oplosgroep waardoor de foutanalyse zo efficiënt mogelijk kan worden uitgevoerd. Indien deze gegevens onvoldoende zijn aangeleverd zorgen de testers van Studielink en/of de instellingen voor een bruikbare aanvulling hierop. Een belangrijk uitgangspunt voor de teststrategie is dat het Nieuwe Studielink zodanig wordt gebouwd dat er zo min mogelijk koppelvlak wijzigingen moeten worden doorgevoerd: het berichtenverkeer blijft nagenoeg gelijk en voldoet aan de specificaties en ketenpartners hoeven in specifieke gevallen slechts kleine aanpassingen in hun systemen aan te brengen zolang deze specificaties ook in de huidige situatie worden gevolgd. Uitzondering hierop vormt een aanpassing op Msg47 (per november 2018) en Msg20 (altijd start betaalproces). Daarnaast vormt ook de koppeling met Progress een uitzondering. Hier is voor het HNS namelijk sprake van een transformatie component welke tussen het ontkoppelpunt en hun SIS wordt geplaatst. Op de voorgenomen go-live datum gaan we dus met een identiek koppelvlak live. Voor een uitgebreidere beschrijving van de teststrategie wordt verwezen naar het Mastertestplan. 6.2 Globale testaanpak - De ketentestuitvoering door de instellingen wordt verricht aan de hand van voorbereide testcasussen welke minimaal de in de scope genoemde processen afdekken. Deze testcasussen worden tevoren aan de diverse instellingen toegezonden zodat ook zij zich kunnen voorbereiden en inlezen. De testers kunnen vervolgens naar eigen inzicht en tijdsindeling gedurende de genoemde testperiode de testuitvoering doen. - De testers melden op reguliere basis hun voortgang aan het testteam van Studielink aan de hand van het meegezonden Testmonitor formulier. Deze informatie wordt door het testmanagement verwerkt en geeft inzicht in de totale voortgang en de behaalde dekkingsgraad van de ketentest. Showstoppers dienen per direct te worden gemeld, zodat de voortgang van het testproces geen onnodige vertraging ondervind. 18

19 - Bevindingen worden door de testers zelf opgevoerd in Jira. Studielink voert vervolgens een eerste analyse uit op de bevindingen en zet deze door naar de juiste oplosgroep. - Studielink zorgt ervoor dat er voldoende informatie beschikbaar is voor testers om te bepalen of een bevinding een known-issue is ofwel een bevinding die al is opgenomen in een geplande release. 19

20 6.3 Omgeving freeze Gedurende de testperiode zal de ketenomgeving in een Freeze status moeten worden gebracht. Daarmee wordt bedoeld dat er gedurende deze periode geen enkele mutatie op configuratie, inrichting en technisch niveau mag plaatsvinden, zonder de nadrukkelijke toestemming van het testmanagement. Hiermee wordt voorkomen dat ingevoerde testdata per abuis worden aangetast en dat er bevindingen worden gedaan welke worden veroorzaakt door onverwachte systeemwijzigingen. 6.4 Bevindingen procedure Een bevinding is een reactie van het systeem welke niet voldoet aan de voorspelde of eigen verwachting. De bevinding dient door de tester te worden opgevoerd in Jira. Alvorens dit te doen controleert de tester zoveel mogelijk of er niet reeds een bestaande melding is van hetzelfde issue (duplicaat). Binnen de FKT krijgt de melding krijgt automatisch het label finale ketentest zodat deze later eenvoudig op deze categorie te analyseren zijn. Elke melding krijgt in eerste instantie het label nieuw. Deze nieuwe meldingen worden eerst geanalyseerd door Studielink. In deze eerste analyse wordt een eerste schifting gedaan of het (alsnog) een dubbele melding betreft, of deze door een medewerker van Studielink kan/moet worden opgelost of dat het een issue betreft welke QDelft verder moet analyseren. Als QDelft de oplosgroep is dan wordt deze als dusdanig aan QDelft aangeboden voor verder onderzoek (status=analysis). Als na deze analyse blijkt dat het inderdaad een onvolkomendheid betreft dan wordt het issue verder bij QDelft in behandeling genomen (Status = Selected for Development). Als Studielink de aangewezen partij is om een Jira-ticket op te lossen wordt de melding toegekend aan de betreffende oplosser. Deze zal dan er voor zorgdragen dat het ticket wordt opgelost. Zodra een issue is opgelost en gerealiseerd wordt deze opnieuw aangeboden voor hertest. Dit kan een separate test zijn, maar het issue kan ook meegenomen worden in een volgende (keten)test. Zodra de bevinding niet meer wordt geconstateerd wordt het ticket gesloten. De belangrijkste redenen om een ticket te sluiten zijn: - Een dubbele melding; De betreffende bevinding is reeds door een andere tester geconstateerd en aangemeld in Jira. In dit geval wordt de nieuwe melding afgesloten met als reden duplicaat. De melding wordt bij afsluiten voorzien van de duplicaat opmerking en het bijbehorende SLSD nummer van de eerste melding. - Een bekend probleem; Het kan zijn dat een bevinding een reeds bekend probleem is bij de ontwikkelaars of dat het onderliggende functiepunt nog moet worden gebouwd. In dit geval worden de bevinding afgesloten met als reden known issue. De melding wordt bij afsluiten voorzien van de knownissue opmerking en het bijbehorende SL(SD) nummer van de eerste melding. - Iets is opgelost; Het probleem is opgelost en succesvol gehertest. De bevinding wordt afgesloten met als reden Gedaan. - Wordt niet opgelost; In dit geval wordt het issue afgesloten omdat de functionaliteit niet valt binnen de opdracht van het project. In dit geval wordt de melding afgesloten met als reden declined. - Niet relevant; Meldingen welke niet relevant zijn worden afgesloten met als reden discarded. 20

21 Het afsluiten van een melding houdt in dat het TICKET wordt afgesloten. Dit betekent dus niet altijd dat het onderliggende probleem zelf al is opgelost. Bijvoorbeeld bij duplicaat meldingen wordt de eerste melding pas afgesloten als het issue is opgelost terwijl alle duplicaat melding al eerder zijn gesloten. Ditzelfde geldt voor een known-issue. Een ticket kan worden afgesloten omdat het een bekend probleem betreft. Het probleem zelf wordt dus nog wel opgelost en bijgehouden in de eerste melding in Jira. 21

22 4-jun 11-jun 18-jun 25-jun 2-jul 9-jul 16-jul 23-jul 30-jul 6-aug 13-aug 20-aug 7 Planning Testactiviteit: Vanaf T/m Voorbereiden testfase Bepalen test opzet 6 juni 28 juni 2018 Bepalen doel en scope test Vaststellen te testen objecten Bepalen risico s en beheersingsmaatregelen Schrijven en definitief maken detail testplan Voorbereiden test 10 juni 30 juni Bepalen benodigde scenario s Bepalen doorlooptijd test uitvoering Voorbereiden test uitvoering 8 juni 23 juli Uitwerken test scenario s Opstellen testmonitor Uitwerken checklists Aanleveren testgevallen instellingen Ketentestomgeving beschikbaar 6 aug ---- Uitvoeren testfases Ketentest 6 aug 18 aug Testopzet Opstellen scenario's Voorbereiden testen Smoke test Testomgeving beschikbaar Uitvoering Finale Keten Test Rapportage 22

23 8 BIJLAGE A: CONTACTGEGEVENS In onderstaand overzicht staan de contactpersonen voor de ketentest. 8.1 Contactpersonen Naam Functie Vervanger bij afwezigheid Organisatie adres Telefoon Jos van Aalderen Testcoördinator Chris Herselman QDelft Chris Herselman Tester Jos van Aalderen QDelft Raymond Verhoef Peter van Kan Jorrit Miedema Servicemanager QDelft Testcoördinator Studielink Testcoördinator Studielink QDelft Jorrit Miedema Studielink Peter van Kan Studielink Stanley Latumeten Tester Jasper Jordans Studielink Jasper Jordans Tester Stanley Latumeten Studielink Beschikbaarheid Naam Organisatie Dagen Jos van Aalderen QDelft maandag, dinsdag, donderdag en vrijdag Jorrit Miedema Studielink maandag, dinsdag, woensdag, donderdag en vrijdag Stanley Latumeten Studielink maandag, dinsdag, woensdag, donderdag en vrijdag Jasper Jordans Studielink maandag, dinsdag, woensdag, donderdag en vrijdag Peter van Kan Studielink Maandag, dinsdag, woensdag, donderdag Chris Herselman QDelft (in deze rol met name op woensdag) maandag, dinsdag, woensdag, vrijdag Raymond Verhoef QDelft Maandag t/m donderdag 23