Ketentest 2 Het Nieuwe Studielink Zachte landing!! Nu hard gewerkt om iets te bouwen wat voor jullie is. Tipje van sluier voor zachte landing. Fundamenten zijn altijd minder spannend om te tonen aan de nieuwe bewoners van een huis. Komende maanden zal het steeds meer vorm krijgen en zullen we jullie stap voor stap meenemen in het proces voor de ‘zachte landing’. Stichting Studielink - QDelft Jorrit Miedema

Programma Welkom Waarom is de ketentest verplaatst Ketentestgevallen + Documentatie Welke functionaliteiten kunnen er getest worden DUO is aangesloten Monitoring Jira Melding aanmaken Toelichting aanleveren bevinding

Waarom is de ketentest verplaatst Op 18 juni start de ketentest in plaats van 12 juni Redenen van verplaatsing: Het testen van opgeleverde functionaliteiten kost de nodige tijd. Het gereed maken van de testomgeving kost meer tijd dan initieel gedacht. Gegevens vanuit KT1 worden meegenomen naar KT2, waardoor een andere wijze van omgevingsopbouw benodigd is. Dit kost meer tijd dan geschat.

Ketentestgevallen en Documentatie Instructieboek opgesteld Ketentestgevallen Ketentestgevallen worden uiterlijk morgen eind van de middag gemaild. Heb je niks ontvangen stuur dan een mailtje naar HNStestteam@studielink.nl Alle testdocumentatie is ook terug te vinden op de projectwebsite (https://projectwebsite.studielink.nl/)

Welke functionaliteiten kunnen er getest worden Er worden met jullie ketentestgevallen (scenario’s) gedeeld Scenario’s dienen minimaal één keer per instelling getest te worden De volgende scenario's zijn in ieder geval opgesteld: Een student doet een VTI en wordt hierna als overleden geregistreerd vanuit het SIS Student schrijft zich uit tijdens het schooljaar en SIS medewerker doet herstel inschrijving Afmelden voor bevestiging opleiding + afmelden na bevestiging opleiding (voor het begin van het schooljaar) Student wijzigt adresgegevens + persoonsgegevens + aanpassing vooropleiding Een student krijgt na een Verzoek Tot Inschrijving, de mogelijkheid om zijn collegegeld via DIM te betalen. Nieuwe/gewijzigde identificerende nummers van een student + doorgeven inschrijfvolgnummer Exploratory testen is gewenst!!!

DUO aangesloten QDelft is de verbinding met DUO aan het testen Per instelling worden 12 geldige BSN uitgeleverd

Waarom een testmonitor Regie op testen Eerder kunnen voorsorteren op bevindingen Eerder inzicht in impact van fouten (hoe vaak gaat een bepaald proces mis) Inzicht in de dekkingsgraad van het testen

Uitleg testmonitor Iedere tester krijgt een testset toegestuurd Verdeeld in hoofdprocessen Hierop graag bijhouden wat je hebt afgerond. Het verzoek is om minimaal 1x per week, of liever na afloop van elk testmoment/testdag, het formulier (steeds aangevuld) retour te sturen aan hnstestteam@studielink.nl Het testteam van Studielink verwerkt vervolgens centraal de voortgang van de gehele Ketentest.

Uitleg testmonitor Zodra het testen van een hoofdproces gereed is, geef je dit aan met een OK als de test succesvol was en NOK als je een bevinding hebt gedaan.

Uitleg testmonitor Heb je een bevinding gedaan (NOK), geef dan in kolom JIRA het corresponderende Jira registratienummer.

Jira Melding aanmaken Jira als bevindingregistratie systeem Aangemaakte bevindingen voor iedere instelling zichtbaar, evenals actuele status en afhandeling Iedere instelling krijgt organisatie-account in Jira, gedurende project Emailadres voor account nog niet doorgegeven -> mail naar studielink@qdelft.nl Proces van rapporteren bevinding wordt in handleiding per mail verstuurd Openstaande bevindingen worden door Jorrit Miedema gemonitord. Nog geen antwoord op eerder gemelde bevinding? Opnieuw bevinding aanmaken in Jira, vervolgens is bevinding (status en afhandeling) zichtbaar in systeem. De opgevoerde issue dan graag wel linken aan de nog openstaande bevinding.

Toelichting aanleveren bevindingen Verbetering 1: Duplicaten Verbetering 2: De bevinding: hoe duidelijker, hoe beter Uitleg: Het levenspad van de bevinding Bevindingen worden, zoals bekend, door ingegeven in Jira. Vanaf dat moment worden op reguliere basis de nieuwe bevindingen geanalyseerd en waar nodig aan de juiste oplosgroep/persoon toegekend. Voor een goede afhandeling is het noodzakelijk dat alle geboden informatie zo volledig en duidelijk mogelijk is. Op deze wijze wordt is er zo min mogelijk tijd nodig om de bevinding te analyseren en af te (laten) handelen. Daarnaast willen we zoveel mogelijk voorkomen dat er (analyse)tijd wordt gestoken in bevindingen die al bekend zijn of zelfs al worden opgelost. Om dit bevindingenproces nog efficiënter te laten verlopen volgen hierover nog wat tips die ons allemaal gaan helpen. Tevens wil ik jullie nog even kort meenemen in de levensloop van een bevinding; van status nieuw tot afgesloten.

Verbetering 1: Duplicaten Duplicaten zijn al eerder gemelde bevindingen Duplicaten kosten onnodig veel tijd Oplossing: Zoek eerst of je bevinding al bekend is in Jira Zo ja, vul de bestaande bevinding dan aan. Dit helpt bij de foutanalyse Alle zelfde meldingen bij elkaar geven ook inzicht in omvang. Maar hoe zoek je dan naar duplicaten?? Vaak is het al vrij snel duidelijk dat er sprake is van een issue welke door meerdere testers wordt geconstateerd. We zien dan ook vaak dat er meerdere dezelfde meldingen binnen komen. Omdat dit er vaak meer dan één is kan er veel tijd verloren gaan met het onnodig verwerken van de dubbele meldingen of dat letterlijk door de dubbele issuebomen het bos niet meer kan worden gezien. We weten dat velen van jullie al goed opletten of een melding reeds eerder is gedaan, getuige de vaak zeer interessante ‘gesprekken’ die plaats vinden binnen een Jira ticket (“Wij hebben dan ook geconstateerd”, “Hoe hebben jullie dat opgelost”, “Wij sluiten ons aan bij de constatering van ….”. Toch willen we jullie nog een keer vragen om eerst goed te kijken of een melding niet al eerder is gedaan, alvorens de bevinding aan te maken. Mocht de bevinding al bestaan, vul deze dan eventueel aan met je eigen constateringen. Ook kan dit ons nog beter helpen met de foutanalyse omdat niet iedere instelling het probleem niet altijd ondervind onder dezelfde omstandigheden of juist wel ! De situatie is duidelijker als alle identieke meldingen in 1 ticket staan.

Verbetering 2: Maak van een melding geen zoekplaatje Meer info = beter Maak reproduceerbaarheid zo nauwkeurig mogelijk Maak screendump’s Plaatjes zeggen vaak meer dan woorden. Duidelijke omschrijving is goud waard Wees uitvoerig Hoe meer informatie een bevinding bevat des te beter. Voor de oplosgroep of persoon die een bevinding moet analyseren is het van groot belang zoveel mogelijk informatie te hebben. Vergaat daarbij de schermafbeeldingen niet; het is bekend dat een plaatje vaak meer zegt dan woorden. Dus voeg zoveel mogelijk screendumps/afbeeldingen toe. Velen van jullie doen dit gelukkig al ! Het blijft natuurlijk dan nog wel steeds van belang dat goed omschreven wordt wat er PRECIES gebeurd. Wees hierin zo uitvoerig mogelijk. “De applicatie crasht” kan bijvoorbeeld nog beter omschreven worden als “ik krijg een foutmelding met dit nummer” of “als ik daar op klik sluit mijn browser zich direct af en moet ik opnieuw beginnen”.

Verbetering 2: Maak van een melding geen zoekplaatje Uitgangssituatie (waar kwam je vandaan/welk scherm ) Testdata (student, vak, collegejaar, opleiding etc) De stappen die je gedaan hebt (ik klikte dit aan, vulde dat in, en scrolde zus en koos toen zo) Systeeminstellingen (schermresolutie, welke browser, welk OS etc;) Foutresultaat (code, zwart scherm, onverwachte terugkeer naar ander scherm, vreemd gedrag) Zeker zo belangrijk naast duidelijkheid is de reproduceerbaarheid. Reproduceerbaarheid is het steeds opnieuw kunnen bereiken van een vergelijkbaar resultaat wanneer een beschreven testcasus wordt uitgevoerd. Simpeler gezegd: een testcasus is reproduceerbaar wanneer iemand anders hetzelfde resultaat krijgt wanneer deze de casus herhaalt.  Dit geeft de oplosser de mogelijkheid om de stappen na te spelen die leiden tot de door jou geconstateerde bevinding. Wanneer een bevinding niet te reproduceren is, wordt het voor de oplosser van de bevinding erg lastig om een analyse uit te voeren en de bevinding te verhelpen. Dit gaat de behandelaar extra tijd kosten of de bevinding gaat terug naar jou als tester met verzoek om meer informatie. In het laatste geval is het dan de vraag of de tester zelf nog wel de exacte stappen kan terughalen om de fout na te bootsen. Duidelijke weergave van reproduceerbaarheid geeft dus een nog beter beeld over de omstandigheden en de triggers welke resulteren in de bevinding. Die omstandigheden of triggers zijn niet zelden juist de oorzaak van de fout. En een nog betere analyse leidt weer tot een betere en soms snellere oplossing. Als je een bevinding bij herhaling constateert geeft dan in de bevinding zo exact mogelijk weer: - De uitgangssituatie (waar kwam je vandaan/welk scherm/ wat voor soort student ben je bezig) - De gebruikte testdata (student, vak, collegejaar, opleiding etc) - De stappen die je gedaan hebt (ik klikte dit, vulde dat in, en scrollde zus en koos toe dat) - Systeeminstellingen (schermresolutie, welke browser, welk OS etc) - Foutresultaat (code, zwart scherm, onverwachte terugkeer naar ander scherm, vreemd gedrag)

Uitleg: Het levenspad van de bevinding Elke melding krijgt in eerste instantie het label ‘nieuw’. Deze nieuwe meldingen worden vervolgens in eerst bekeken door studielink. In deze eerste analyse wordt een eerste schifting gedaan of het een dubbele melding betreft of deze door een medewerker van studielink kan/moet worden opgelost of dat het een issue betreft welke Qdelft moet oplossen. Overigens kan een dubbele melding ook pas later worden opgemerkt. Als Qdelft de oplosgroep is dan wordt deze als dusdanig aangeboden voor analyse. Als na analyse blijkt dat het inderdaad een fout betreft dan wordt deze bij Qdelft in behandeling genomen (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.

Het levenspad van de bevinding Afsluiten / afwijzen redenen Dubbele melding (SLSD) Bekend probleem (known error(SL)) Opgelost (of buiten scope) Let op! Als een TICKET wordt afgesloten wil dat niet altijd zeggen dat er niets meer wordt gedaan met het probleem zelf. Deze wordt bv verder opgepakt in de originele melding De drie belangrijkste redenen om een ticket te sluiten zijn een dubbele melding, een bekend probleem of dat iets is opgelost (of niet wordt opgelost). LET OP! Het afsluiten van bijvoorbeeld een duplicaatmelding houdt in dat het TICKET wordt afgesloten. Dus het probleem wordt zelf nog wel opgepakt in de andere (vaak eerste) melding van het duplicaat. 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.

Known Issues Known issue Is een reeds bekend probleem welke onderkend is en wordt of reeds is opgepakt Dit issue kan intern al eerder zijn geconstateerd. Er hoeft hier dus niet altijd sprake te zijn van een duplicaat-ticket in Jira. Betreft ook functionaliteiten die nog ontwikkeld moeten worden. Overigens zijn duplicaten er in 2 smaken.

Tenslotte Vermeld altijd maar 1 bevinding per ticket Instellingen kunnen de backlog niet inzien. Known-issues daarom niet altijd herkenbaar of terug te vinden. Oplossing: Zoeken naar known issues in de zoekbalk Tenslotte willen we verzoeken om per Jira-ticket maar 1 bevinding op te geven. Bij meerdere bevindingen per ticket is het lastig om het ticket te categoriseren of toe te kennen aan de juiste oplosgroep. Hierdoor ontstaat het risico dat een deel van het ticket, en dus de andere bevinding, over het hoofd wordt gezien. Klein probleem is dat je als instelling geen inzage hebt in bijvoorbeeld de backlog en dus ook de knows-issues. Dit heeft een technische (Jira) reden en is niet op te lossen. Met Qdelft wordt gekeken om de known-issues toch beschikbaar te krijgen voor jullie in bijvoorbeeld een op te roepen overzicht of lijst. Op confluence pagina maken

Vragen?