GDPR og hvorfor vi ikke kan bruke skarpe testdata

Forfatter: Richard Rostad, Promis Qualify

Bilder hentet fra: https://unsplash.com/photos/

NAV lagrer og vedlikeholder sensitiv personinformasjon om nesten alle mennesker i Norge. Å bevege seg bort fra å bruke skarpe date i utviklingsmiljø handler litt om verktøy, metoder og teknologi, men aller mest om organisasjonsstruktur og finansiering. NAV beveger seg bort fra den gamle fossefall-tankegangen (med kontrakter på anbud), til å bli å bruke smidig utvikling med egne utviklere og syntetiske data. Denne artikkelen handler derfor om to (litt ulike) sider av samme sak: Hvordan skal man organisere seg for å lykkes i en smidig verden, og hvordan kom vi fram til brukbare syntetiske testdata for utviklingsteamene våre?

Syntetiske testdata har flere potensielle fordeler: Bedre kontroll over uvanlige datakombinasjoner, hurtig generering av testsett for ytelsestest, samt spesifikke testsett som bestilles av andre konsumenter, og på toppen av det hele har du innbakt samsvar med GDPR. Selv om disse fordelene slår et godt slag for syntetiske testdata, er det ingen som har påstått at det var lett å få til. For å få til dette må man ta hensyn til kjente problemstillinger, ukjente problemstillinger, samt problemstillinger som viste seg å ikke være problemstillinger en gang, i dette nye regimet. Første delen av artikkelen tar for seg de administrative delene, del to ser på de tekniske løsningene vi fant, samt utfordringene vi fant underveis. Flesteparten av de tekniske problemstillingene finnes fordi NAV IT er skrudd sammen av over 200 forskjellige IT-systemer fra de siste fem tiår.

Tekniske grunner til ikke å bruke skarpe data

Forbruk av testdata

Testing med skarpe data representerer flere tekniske problemer. Først og fremst forbruk av testdata, i NAVs tilfelle betyr det forbruk av personinformasjon. En gitt person når pensjonsalder kun én gang, og når denne hendelsen er saksbehandlet i et testmiljø er det vanskelig å tilbakestille personen til en tilstand før pensjonsalder. Ytelsestester forbruker eksepsjonelt store mengder skarpe data, dette begrenser mengden testing som kan foretas.

Videre vil det brukes store mengder tid til å søke opp spesialtilfeller og disse grensetilfellene blir enda raskere brukt opp enn normale testdata. Ved å kunne produsere persondata til spesielle behov blir det betydelig enklere å finne en person med påkrevde kriterier for testing av grenser og kompliserte saksbehandlingstilfeller.

Testautomatisering

Testautomatisering med skarpe data blir fort avhengig av systemets tilstand i produksjon slik at man ikke får adskilt test og testdata. Det betyr som over at automatiserte tester ofte kan kjøres kun én gang mellom hver gang det lastes nye data fra produksjon over de eksisterende, noe som gjør gevinsten av automatisering betydelig mindre. Videre får man problemer når data i produksjon endrer seg og alenemoren plutselig er gift. Hvis man kan generere data som passer til testen ved behov forsvinner alle disse problemene.

Mange testmiljøer som må være synkronisert

NAV har over 200 forskjellige systemer som i særs stor grad forholder seg til det samme datasettet, som er Norges befolkning. Saksbehandling / endringer av personer i ett miljø kan forårsake at testdata for et annet system blir invalidert slik at tester feiler. Dette forårsaker unødvendig mye tid brukt på feilsøking. Igjen forsvinner problemet ved muligheten for å generere data som passer testen ved behov, istedenfor å basere seg på eksisterende produksjonsdata.

Test Doubles blir avhengig av produksjonsdata

Man har også problemer ved forsøk på mocking og stubs av perifere systemer der stub'en også må speile eksisterende produksjonsdata. Dette gjør testgrensesnittene betydelig mindre fleksible og vanskeliggjør isolering av problemer og feilsøking.

Totalt i NAV ser man at omkring to tredjedeler av innsatsen som kunne blitt benyttet til faktisk testing blir benyttet til søking, flytting og annen preparering av produksjonsdata. En enkel og lett tlgjengelig metode for ad-hoc generering av relevante data ville ha enormt potensiale for innsparinger eller heving av kvaliteten på NAVs systemer.

Motforestillinger

Den største motforestillingen mot syntetiske data er at de ikke er "levende", i den forstand at det ikke blir født nye barn, personer blir ikke eldre etc. Dette er enkelt å komme rundt ved å ha skedulerte jobber som genererer hendelser og om ikke det minste problemet med syntetisering, så ihverfall blant de enkleste.

 

Behov

Syntetiseringsprosjektet hos NAV har identifisert fire distinkte behov som må stilles til et godt syntetisert testmiljø.

                   1: Data for basis testing og ad-hoc exploratory testing

Så produksjonslike data som mulig for testformål

Dette betyr en statistisk representativ basisbefolkning som på alle måter speiler de signifikante aspektene av en reell befolkning. Siden de fleste av testene blir basert på behovene nedenfor, trenger denne befolkningen ikke å være i fullskala, noe som også reduserer ressursbehovet i form av CPU, stormaskintid, disk, minne etc. NAV baserer seg på en basisbefolkning på 100 000 som vil vokse i tilnærmelsesvis samme rate som den reelle befolkningen.

                   2: Grensetilfeller for spesifikk testing

Dette behovet dekker det meste av den spesifikke testingen av grensetilfeller og vanskelige saker. Eksempelvis en funksjonshemmet person som er adoptert av sin yngre søster og derfor har en mor som er yngre enn seg. Disse personene vil opprettes umiddelbart før testen og så saksbehandles gjennom systemene til en gitt endetilstand. Vi ønsker ikke å slette / resette personer til utgangstilstanden, så ved neste kjøring av testen vil man opprette en ny person med utgangstilstanden. Siden dette gjøres på den samme databasen som inneholder basisbefolkningen vil denne over tid langsomt endre seg fra den statistisk representative speilingen av virkeligheten som var utgangspunktet. Dette er akseptabelt fordi:

a)    Det er ønskelig at mest mulig av disse testene gjøres gjennom test-doubles av ytelse og reproduserbarhetshensyn slik at den statistiske effekten blir relativt liten.

b)    Basistesting vil i alle tilfelle gjøre endringer på testbefolkningen slik at vi uansett vil ha en glidning vekk fra realiteten. Dette må enten løses ved resetting av befolkningen til utgangspunktet eller ganske enkelt aksepteres. Kun utstrakt bruk av syntetdataene over tid vil vise hvilken løsning som er ønskelig.

                   3: Store datasett for ytelsestesting

Det vil fra tid til annen være behov for store datasett med et begrenset utvalg av signifikante variable for ytelsestesting. Eksempelvis en morgen med 15000 ferske mødre for test av automatisk saksbehandling av engangsstønad.

                   4: En levende testbefolkning

Det vil være et kontinuerlig behov for hendelser som skjer "av seg selv" for test av automatiske innslag i systemene ved passering av aldersgrenser, fødsler, dødsfall etc. Disse hendelsene må foregå kontinuerlig og i en frekvens som både gjenspeiler en statistisk virkelighet og er av tilstrekkelig omfang til å kunne forårsake nødvendig testing.

 

Hindringer

Enorm kompleksitet

Det største problemet med syntetisering av et helt land er den enorme kompleksiteten, både i virkeligheten og NAVs systempark. Siden den statistiske analysejobben vil vokse eksponensielt med antall analyserte variable er det ekstremt viktig å foreta et fornuftig utvalg av parametere som er relevante for syntetiseringen. Eksempelvis har vi ved generering av innvandringsmeldinger identifisert at både statsborgerskap og opprinnelsesland er relevante, men at kombinasjonen ikke er relevant. Det betyr at en svensk statsborger som er innvandret fra Azerbaijan er OK og analysen ser derfor på de to landene uavhengig slik at vi har et "riktig" antall svensker og et tilsvarende riktig antall innvandringer fra Azerbaijan, men kombinasjonen er ignorert.

Mange platformer og 6 tiår med løsninger

Det eldste systemet på NAV er skrevet i 1968 og er optimalisert for batch prosessering av hullkort. Det nyeste systemet er fra 2018 og bygget på Apache Kafka og json events. I mellom disse to ytterpunktene har vi alle tenkelige varianter av UNIX RPC kall, Java, Javascript, Visual Basic og Oracle Forms. Syntetisering av data for alle disse systemene er en utfordring

Avhengigheter til forretningslogikk som ligger i andre systemer

Problemet over blir forsterket av at systemene er avhengig av at dataene har blitt gjenstand for transformering gjennom eksisterende forretningslogikk gjennom andre systemer slik at en Oracle forms applikasjon forutsetter at en batchprosess har sendt data over UNIX RPC til et COBOL program før dataene kan benyttes til saksbehandling.

 

Løsning

1: Syntetisering av basispopulasjon

Syntetiseringsprosessen består av fire distinkte ledd; Ekstrahering av produksjonsdata, maskering, analyse og generering av syntetiske data på grunnlag av analysen. Nøkkelen til suksess er å ikke basere seg på innholdet i databasene, men fokusere analysen på flyten av data mellom systemer og dermed generere data gjennom eksisterende forretningslogikk.

Ekstrahere

I NAV er vi så heldige at vi har meldingshistorikk både på eksterne og interne data. Det er flere grunner til at vi har slik historikk, deriblant hensyn til sporing og validering av historiske hendelser som har dannet grunnlaget for saksbehandling og vedtak. Ekstraktet blir dermed bare en "dump" av meldingshistorikken for en gitt tidsperiode. Dette er fremdeles skarpe data og er således gjenstand for de samme sikkerhetsregler som online produksjonsdata.

Maskere

Neste skritt er en maskering og anonymisering av datagrunnlaget. Dette skrittet er overflødig dersom personellet som arbeider med syntetiseringen fra før har tilgang til produksjonsdata, men koster lite og har den fordelen at man kan redusere sikkerhetskravene til tilgangen til datagrunnlaget. Maskeringen i dette tilfellet fjerner også all informasjon som ikke er statistisk relevant, slik som navn og adresse, noe som gjør maskeringen sterkere enn en ukritisk maskering av hele produksjonsdatasettet hadde blitt.

Analysere

Deretter foretas en statistisk analyse av det maskerte datasettet. Denne analysen er skrevet i R og baserer seg på teknikker fra SDV - Synthetic Data Vault og Synthpop, begge utviklet for lignende formål ved MIT. Det er viktig å merke seg at det beregnes statistikk for sammensatte variable slik at man ikke bare får riktig antall 42-åringer, men også riktig antall skilte 42-åringer med 3 barn hvorav to er gutter, etc. Denne analysen er ressurskrevende og bør fortrinnsvis kjøres på dedikert hardware med tilstrekkelige ressurser. I forkant av den statistiske analysen har det blitt gjort en analyse av hvilke variable som er relevante å se i sammenheng. Eksempelvis er det relevant for systemene i NAV hvilket statsborgerskap en utlending har og også hvilket land han har innvandret fra. Imidlertid er kombinasjonen av opprinnelsesland og statsborgerskap ikke viktig, så systemet tar ikke hensyn til det, slik at vi har svenske statsborgere som innvandrer fra Azerbaijan. Siden tidsbruken for analysering stiger eksponensielt med antallet variable er en slik analyse viktig.

Generere

Det siste skrittet i prosessen er å generere "realistiske" hendelser og legge dem i et mellomlager. En systemprosess plukker så meldinger fra lageret og distribuerer til de forskjellige systemene. Vi genererer opp et langt større antall hendelser enn det vi initielt trenger, slik at systemet kan plukke meldinger over tid. Dette både av hensyn til belastning på systemer under genereringen og slik at vi kan simulere hendelser og endringer i befolkningen over tid. En interessant detalj er at vi har begynt med å simulere innvandringer siden systemet ikke har noen andre måter å skape personer ex nihilio; en fødsel forutsetter en mor etc. Dette er i praksis en simulering av folkevandringen etter istiden bare med andre datoer.

2: Randtilfeller og spesifikke testdata

Som testere har vi til stadighet behov for ekstreme, urealistiske eller på andre måter vanskelige data for testing av grensetilfeller og negativ testing. Eksempelvis barn som er eldre enn sine mødre. Genereringen av slike data vil ikke bli ivaretatt av basispopulasjonen. Både fordi vi har valgt å kjøre syntet-Norge med en lavere befolkning enn det virkelige og fordi sannsynligheten for slike tilfeller er statistisk lik null.

Selv om vi hadde generert nok personer til å få alle mulige slike varianter hadde vi allikevel endt opp med samme problemet vi tidligere hadde ved bruk av reelle data, nemlig problemet med å finne frem til slike personer. Det ville også være en mangel på umulige tilfeller.

Slike problemer løses best av et system der man kan spesifisere nøyaktig hva slags personer man ønsker testet og så genererer et lite antall slike spesifikt for sine tester. Ulempen med en slik løsning er at disse sære personene over tid vil forskyve den statistiske balansen i basispopulasjonen. Dette er delvis løst ved å legge mye randtilfeller i dedikerte testgrensesnitt som ikke er koblet mot de sentrale systemene, såkalte test-doubles. Dette er ikke en fullgod løsning og der det kreves en flyt gjennom mange systemer vil den statistiske representasjonen til basispopulasjonen endres vekk fra virkeligheten over tid. Dette problemet er ikke fullgodt løst ennå.

3:  Store antall "like" personer for ytelsestesting.

Systemene må fra tid til annen ytelsestestes. I slike tilfelle trenger vi mange personer som har et sett med parametre, men der øvrige egenskaper ikke er viktige for testen. Eksempelvis 15 000 nybakte mødre samme tirsdag for stresstesting av systemet for utbetaling av engangsstønad. Dette har vi løst ved at systemene i pkt. 2 også kan generere mange personer relativt enkelt. Løsningen er at man bare spesifiserer de relevante verdiene og så genererer systemet opp tilfeldige verdier for resten av de påkrevde parametrene. I eksempelet over spesifiserer man kvinne over 16 og under 50 og lar systemet håndtere resten. Vi har valgt å legge systemene opp slik at blanke felt gir en tilfeldig gyldig verdi, mens et spenn gir en tilfeldig verdi innenfor maks / min verdier.

Slike personer har en enda større innvirkning på basispopulasjonen enn randtilfellene og det er derfor ønskelig å ha mest mulig slik testing i test-doubles. Eventuelt drepe syntet-personene etter at man er ferdig med testen, noe som også gir en "gratis" ytelsestest av systemene for gravferdsstønad.

4:  En levende populasjon

I virkeligheten skjer det hendelser med befolkningen jevnlig. Folk blir født, dør, giftes og skilles. For at dette skal foregå også i syntet-Norge har vi laget en prosess som kontinuerlig plukker syntetiske hendelser fra lageret av genererte hendelser og propagerer dem ut i systemene gjennom eksisterende forretningslogikk. Teknisk er det ikke noen forskjell på denne og engangsgenereringen over.

App-releaser er ikke som andre releaser

Apper er ikke bare apper.

Denne artikkelen tar kun for seg native apper. Release av web apper og hybrid apper behandles ikke her.

 

Det som er spesielt når man skal ha apper ut til folket, er at det ikke bare er ên release. 
Som oftest så er det flere, da de fleste apper har både iOS-versjoner (iPhone) og Android-versjoner (Samsung, LG, Sony og alle de andre). Noen har sågar også en WindowsPhone-versjon. Appene spiller sammen med baksystemene, altså de delene av funksjonaliteten som ligger på servere.

Man kan dermed få alle mulige kombinasjonene av koordinerte releaser av alt fra én til alle av disse:

Android iOS Baksystemer

 

Det varierer hvor tett baksystemutviklerne jobber med app-utviklerne. Og hvor tett app-utviklerne på ên plattform jobber med app-utviklerne på de andre app-plattformene. I noen tilfeller kan f.eks. Android-appen "stikke avgårde" og få inn ny funksjonalitet lenge før iPhone-appen. Eller omvendt.

Det betyr, at selv om avhengigheten mellom app-plattformene ikke er stor, så vil det som regel være avgjørende at release av apper og baksystemer koordineres.

Ved koordinerte releaser av både apper og baksystemer er det mest hensiktsmessig at baksystemene rulles ut før nyeste app-versjon fordi:

  • De nye appene kan ha avhengigheter til endringer eller ny funksjonalitet i baksystemene.
  • Det oppdaterte baksystemet skal fungere med de app-versjonene som allerede er i omløp. Skulle det dukke opp alvorlige problemer under eller rett etter prod-releasen av baksystemet, så kan man utsette app-releasene til baksystemene har nådd ønsket tilstand. Dette kan være problemer med baksystemet som sådan eller kompabilitetsproblemer mot en eller flere av de eldre versjonene av appene.
  • Appene testes mot den relevante versjonen av baksystemene. Det er avgjørende at den versjonen av baksystemet som appene er testet mot, ligger i prod når appene slippes. Man må derfor allerede når man planlegger testingen av appene, vite hvilke versjoner av baksystemene man skal forholde seg til.
  • Man får litt tid til å teste ut de nye versjonene av app'ene i prod mot det nyeste baksystemet før app'ene gjøres tilgjengelige i app-butikkene. Heri inkludert oppgraderingstester. Man kan bl.a. involvere betagrupper. Betagrupper er et antall frivillige brukere som får prodversjon av appene litt før planlagt release.

Native apper rulles ut gjennom Google Play Store og Apple's App Store. Dette kan gjøres gradvis:

  • For Android ved at man først f.eks. tilgjengeliggjør den nye appen for 10% av brukerne, deretter de neste 40% dagen etter osv. Man har dermed mulighet til å stoppe utrullingen før alle har tilgang, hvis det skulle vise seg å være nødvendig.
  • For iOS kan man ha gradvis utrulling i faser (phased release) til de som har på automatisk oppdatering. Det skjer etter et fast mønster, som starter på 1% første dag og via en tilnærmet dobling pr dag (1%-2%-5%-10%-20%-50%-100%) ender opp på 100% automatisk oppdatering i løpet av 7 dager. Den manuelle oppdateringen påvirkes ikke av dette, så alle vil kunne se den nye versjonen i App Store og kunne laste ned denne fra dag 1. Man kan sette den gradvise utrullingen på pause, men fortsatt vil manuell oppdatering være tilgjengelig.

For apper er det aldri snakk om tilbakerulling. Man kan i krisesituasjoner kun ta appen ut av app-butikken, og så fort som mulig komme med en ny og bedre versjon.

Når man planlegger releasedato så må man også ta høyde for at appen skal godkjennes av "butikksjefen" før den legges i Google Play Store og Apple's App Store. Apple er noe mer rigide og deres godkjenningsprosess tar lenger tid, i verste fall opp mot en uke. Mens det for Google vanligvis tar 2 minutter.

Retrospektiv på under timen

Retrospektiv i løpet av 1 time, er det mulig?


Jeg skulle fasilitere et retrospektivmøte for en prosjektfase hos en kunde.
Retrospektivet skulle omhandle et tidsrom på 3 uker, og vi skulle være 7 deltagere.
Etter at jeg hadde sendt ut innkallingene oppdaget jeg at jeg hadde booket bare 1 time. Min første reaksjon var å forlenge møtet, men hvorfor ikke ta det som en utfordring? Tross alt så har vi vel alle vært med på retrospektivmøter som drar ut i det lange og breie uten at resultatet blir så mye bedre av den grunn.
Målet med retrospektiv er som kjent å gi innspill til kontinuerlig forbedring. Det var viktig å ikke miste det av syne i iveren etter å presse møtet inn på 1 time.

Jeg skjønte raskt at for at dette skulle lykkes måtte forberedelsene være gode.

Forberedelser:

I innkallingen hadde jeg lagt ved en veldig kort tekstlig versjon av tidslinjen for å få i gang tankeprosessene allerede før møtet.
Jeg googlet litt for å finne inspirasjon, men fant ingen som promoterte én-times retrospektiver. De fleste oppskriftene var relativt tidskrevende. Dog så fant jeg en oppskrift som Johannes Brodwall hadde prøvd ut på Smidig 2010. Og da spesielt noe han kalte "Tenke og svare", "3x3 spørsmål", "Snakke og lytte". Jeg så jo fort at dette ville ta altfor lang tid, men hva om vi tok ut deler av disse og gjorde alt på en gang?
 
Ofte har jeg opplevd at man har gruppert i "Hva var bra?" og "Hva var ikke så bra?" og "Forberdinger". Jeg ønsket et annet fokus enn dette, så der valgte jeg "Høydepunkter" og "Overraskelser", som skulle gi observasjoner fra deltagerne uten at de trengte å sette pluss eller minus foran. Jeg ønsket også at deltagerne skulle se framover, og da ble "Erfaringer" en fin kategori.

Så da puttet jeg alt dette i gryta og gjorde det kokkene kaller for reduksjon, og det hele kokte ned til en tabell med disse overskriftene:

 

Med Høydepunkter/Overraskelser/Erfaringer blir tankeprosessen litt annerledes og ikke nødvendigvis så polarisert.
 
For ytterligere å hjelpe tankeprosessene i gang forberedte jeg en ikke utfyllende stikkordliste som inneholdt temaer som:

  • Ressurssituasjon
  • Rapportering
  • Kommunikasjon
  • Avhengigheter
  • Samarbeid
  • Oppstart
  • Avslutning
  • Arbeidsbelastning
  • Arbeidsfordeling
  • Utstyr/verktøy
  • Oppfølging
  • Trivsel

I tillegg listet jeg opp noen stikkord som var spesifikke for dette retrospektivet.
 
Jeg plukket med meg skrivesaker og gule lapper og møtte opp på møterommet 10 minutter før start. (Jeg hadde passet på å booke rommet fra 15 minutter før selve møtet).

Whiteboard:
Jeg tegnet opp en tidslinje og skrev på start og stoppdatoer.
Jeg skrev opp de 3 kategoriene i et "skjema" der man kunne henge lappene.
 
Flipover:
Skrev opp stikkordeksemplene på et ark.

 

Gjennomføring

Da deltagerne var på plass ønsket jeg velkommen, og siden ikke alle hadde vært med på retrospektivmøter før, så forklarte jeg hensikten med møtet. Vi hadde en liten dialog rundt dette, slik at alle forstod og var enige om opplegget.
Så forklarte jeg konseptet med tidslinjen og fikk med alle på den. Tidslinjen er ei rett linje, som tegnes opp på tavla/flipoveren, for å illustrere den tidsperioden som retrospektivmøtet behandler. En kalender der viktige hendelser plottes inn. Hensikten er å få opp et visuelt bilde av forløpet, til hjelp i tankeprosessene med å hente fram innspill.

Når så tidslinjen var på plass og vi alle var enige om innholdet, forklarte jeg opplegget med å bruke lapper for å komme med innspill. Jeg forklarte så de tre kategoriene og gikk fort gjennom stikkordlista på flipover.
Så fikk alle 10 minutter til å komme med lapper. Når alle var ferdige med å skrive lapper etter en 7-8 minutter, så var det tid for få disse opp på tavla. Det ble gjort slik at man gikk opp etter tur, plasserte én og én lapp i en av de tre kategoriene, og framførte en kort forklaring og begrunnelse.

Det ble produsert 35 lapper fordelt på

  • 17 høydepunkter
  • 8 overraskelser
  • 9 erfaringer.

Det ble så gjennomført en kort diskusjon som munnet ut i forslag til tiltak. Forslagene ble gruppert i 6 temaer. Det var viktig å komme fram til temaer alle var enige om.

Eksempel: Gruppering i temaer:

Tema

Beskrivelse

Kravsporbarhet

Kravene ligger for det meste i Excel-filer. Har man kravene på plass i Jira kan man koble de sammen med testcaser og feilrapporter og med det få full spobarhet mellom disse, og en oversikt/indikasjon på hvordan testene dekker kravene.

Testdekning

Det er trolig noe redundans i testomfanget. Det vil trolig være nyttig å gå gjennom testene for å luke ut "duplikater".

Organisering av testcaser, testsykluser og prosjekter i Jira/Zephyr

Prisendringer bør trolig være egne prosjekter, med egne testsykluser. Testcasene bør i utgangspunktet være prosjektløse (og også egentlig produktløse), men knyttes mot kravene de tester, og legges i testsykluser for eksekvering.

Det trengs en utredning av dette.

Involvering av kundestøtte

Kundestøtte syntes det var veldig nyttig å være med, de bidro med ekstra kompetanse på flere områder, og de var en viktig suksessfaktor for å komme i mål med testingen. Bør gjentas.

Testmiljøer

Vi opplevde lite problemer med testmiljøene, men det var på håret at fluxkondensatoren hadde blitt en show stopper. Man bør etterstrebe at utstyret på lab'en til en hver tid er i orden. Pr i dag er det betalingsterminalen på fluxkondensatoren som ikke fungerer for test.

Testdata

Billettene ble organisert vha "skruebokser". Man bør ta en vurdering av hvilke billetter man ønsker å beholde for testing i andre sammenhenger. Man trenger isåfall en hylle eller plass i et skap for disse.

 

Jeg avsluttet møtet ved å gi alle sjansen til å komme med en sluttkommentar for å kvalitetssikre at vi var kommet i mål.
 
Det hele klokket inn på 55 minutter.

Photo by Gerome Viavant on Unsplash

Etterarbeid

Referatet ble gjort så enkelt som mulig med data om deltagere, tidspunkt og kort beskrivelse av gjennomføringen. Innholdet på lappene ble ført inn i "Høydepunkter/Overraskelser/Erfaringer"-tabellen.
Forbedringsforslagene (inkludert ting som var bra og som burde bevares) ble skrevet inn i en tabell med Tema og Beskrivelse.
Alt dette ble dokumentert i en wiki-side på intranettet. Alle deltagerne fikk så anledning til å kommentere på denne.
Så ble e-mail med link til wiki-siden sendt ut til alle interessentene.

Så, hva er det som er bra med dette?

Vi klarte å gjennomføre selve møtet på under én time, det er flere årsaker til det:

  1. Formen på møtet var klart definert på forhånd
  2. Forberedt og aktiv møteleder
  3. Gruppas sammensetning. Gruppa var jo ikke satt sammen for å fungere på retrospektivmøtet, men dette var en gruppe som jobbet effektivt gjennom hele prosjektperioden og uten de store fakter. Det ble lagt vekt på effektiv kommunikasjon og det preget også retrospektivmøtet.
  4. Prosjektet i seg selv var en suksess, noe som i seg selv bidro til å redusere omfanget på retrospektivet.

Punkt 3 og 4 er man ikke herre over, men jeg tror det først fremst er punkt 1 og 2 som danner grunnlaget for å lykkes med denne type retrospektiv.

Retrospektivmøtet resulterte  i forslag til tiltak gruppert innenfor områder som man ble enige om i løpet av møtet. Disse dannet i neste omgang et bra grunnlag for å definere og tildele konkrete forbedringsoppgaver.

Så hva er det med formen som gjør dette effektivt?

Jeg tror at "Høydepunkter/Overraskelser/Erfaringer"-kategoriene løser opp og gir retrospektivet et mer positivt preg. Legg merke til at ingen av kategoriene er negativt ladet i utgangspunktet:

  • Høydepunkter er den mest positive kategorien, her kom det innspill på ting som fungerte etter forventningene fordi noen hadde gjort en bra innsats.
  • Overraskelser: Her kom det både negative og positive overraskelser. Det mest tydelige skillet på overraskelser og erfaringer er at overraskelsene er hendelser som vil kunne overraske også neste gang de skjer. Det vil si at man kanskje ikke helt skjønner hva som er årsaken.
  • Erfaringer er hendelser som man har mer innsikt i. Både at ting fungerte fordi man gjorde det på en spesiell måte, eller at noe ikke fungerte fordi man hadde gjort slik og slik, eller fordi at man ikke hadde gjort noe for at det skulle fungere i det hele tatt.

 

Her snakker vi altså om nyanser, noe som dette eksempelet illustrerer:

Høydepunkter Overraskelser Erfaringer

"Godt planlagt med ressurser og nødvendig utstyr."

(Her synes en tester at det er gjort gode forberedelser.)

"Lite problemer med testmiljøene."

(Her er testleder overrasket over hvor lite trøbbel man hadde med miljøene.)

"Sikre at testmiljøer er 100% oppe før testing."

(Her ønsker en tester å videreføre og ytterligere forbedre forberedelsesaktivitetene.)

 Testmiljøer pekte seg ut som ett av temaene og munnet ut i følgende forslag til tiltak:
 "Vi opplevde lite problemer med testmiljøene, men det var på håret at fluxkondesatoren hadde blitt en showstopper. Man bør etterstrebe at utstyret på lab'en til en hver tid er i orden. Pr i dag er det fluxkondesatoren som ikke fungerer for test."

Møteledelse: Kontekst:
Sparte totaltid ved å ha møterommet og tavlene klare når møtedeltagerne møtte opp. I en setting der prosjektgjennomføringen har mange utfordringer, eller en setting der det er flere motstridende interesser, vil det være mer utfordrende og heller ikke hensiktsmessig å gjennomføre et retrospektivmøte på tider ned mot en time.
Hadde klar og konsis sesjon med innledende informasjon. Ved å forberede seg godt kan man i en velfungerende organisasjon  kunne gjennomføre retrospektivmøtet i et litt høyere tempo, noe som vil  kunne heve kvaliteten. Høyere tempo fører til mer engasjement, som igjen kan føre til ærligere tilbakemeldinger.
Satte av 10 minutter til å skrive lapper og overholdt tiden.  
Passet på at tempoet ikke dabbet av  under plasseringen av lappene på tavla.  
Hadde ingen lappeflytting på tavla under diskusjonen og seansen med å komme opp med temaer for tiltak.  
Lot deltagerne få diskutere fritt, men hjalp til med å komme opp med navn på temaer som materialiserte seg, og var med på å formulere tiltak.     
Hadde ingen egen agenda som måtte landes i løpet av møtet, men brukte litt spissformuleringer for å provosere på en forsiktig måte.  

 

Epilog - gjennomføring av forslag til tiltak

For dette retrospektivarbeidet fikk jeg ikke mulighet til å følge opp forbedringsarbeidet, men den måten jeg liker å gjøre det på er å legge ut forbedringsforslagene som oppgaver i Jira. Oppgavene tildeles så personer som identifiseres som rett adressat for de forskjellige tiltakene. Referatet fra retrospektivmøtet legges i Confluence og lages slik at Jira-sakene synes i tabellen over tiltak. Status på sakene oppdateres da dynamisk etter hvert som det er progress i sakene.
Etter hvert som det gjennomføres flere retrospektivmøter, kan man samle alle sakene derfra på en Confluence-side koblet mot Jira.
Lista følges deretter opp i et dertil egnet forum som har ansvaret for kontinuerlig forbedring i teamet/prosjektet/organisasjonen.
 
Som alle vet så er det det å få gjennomført tiltakene som er den vanskelige delen. Derfor er det viktig at oppgavene delegeres og følges opp. Og at de som har vært med på å identifisere problemene og tiltakene både involveres og får informasjon om progresjonen i forbedringsarbeidet.

 

Karriere

Brenner du for fagområdet test? Verdsetter du fleksibilitet, faglig fellesskap og utvikling? Promis Qualify er på jakt etter flere dyktige senior testledere.

 

Les mer om jobb i Promis Qualify