1. Kontinuerlig forbedring av testprosessen
Erfaringer fra prosjekt Perform
Steria fagdag 2012
Kjetil Røe, PMP
Anders Vindvad, PMP
13/06/2012

2. Hvem er vi?
Kjetil Røe Anders Vindvad
Sterias Prosjektleder ScrumMaster i SPK-team
i Perform i Perform
Siv.ing Cand.scient
PMP, ScrumMaster PMP, ScrumMaster
13.06.2012 2

3. Agenda
Dette skal du få høre om
 Prosjekt Perform
 Test i prosjekt Perform
 Problemløsning
 Forbedringer
 Erfaringer
 Oppsummering
13/06/2012 3

4.  www.steria.com
Prosjekt Perform
Statens Pensjonskasse 2008 - 2011
 780.000 prosjekttimer
 180 personer, ca 80 fra SPK
 3 leveranser årlig
 3 ukers iterasjoner
 2 hovedleverandører fra 2009, SPK var både kunde og leverandør
13/06/2012

5. Hvorfor ble prosjekt Perform etablert?
4 kritiske forretningsmessige drivere
1. Arbeidsavklaringspenger
Ikrafttredelse 01.03.2010
 Samordne midlertidige ytelser fra NAV
2. Pensjonsreform
Ikrafttredelse 01.01.2011
 Nye regler for offentlig tjenestepensjon
3. Utdatert teknisk plattform
 SPKs pensjonssystem kjører på en teknisk 2011
plattform som er utdatert Effektivisering og
2010 optimalisering av nytt
Nytt regelverk saksbehandlersystem
Videre på nytt
4. NAV Pensjonsprogram 2009 saksbehandlersystem
 NAV utvikler nye IKT-system NAV integrasjon
– SPK må samordne seg med NAV Forberedelse nytt
saksbehandlersystem
2008
NAV integrasjon
Forberede full prosjektoppbygging

6. Hvorfor smidig gjennomføring?
SPK skulle i årene 2008 - 2011
 Bytte ut kjernesystemet bit for bit
 Bytte til et ukjent regelverk i fart innen fristen
 Produsere pensjoner i linja på gammelt og nytt
regelverk med riktig kvalitet
SPK valgte en smidig gjennomføringsmodell med Scrum og
PS2000 for å kunne
 Spesifisere, bygge og kvalitetssikre løsningen litt og litt
 Justere seg inn mot et bevegelig mål under vegs
 Kunne verifisere riktig kvalitet under vegs i prosjektet
13.06.2012 6

7. Ekstern risikovurdering
Fra Metier mars 2010
13/06/2012 7

8. Risikoanalyse fra Perform
I tidlig fase var dette en risikosport
 Øyeblikksbilde fra
tidlig fase av Perform
 Høy sannsynlighet
 Høy konsekvens
 Takk til adm. dir.
Finn Melbø i SPK
13/06/2012 8

9. Perform organisering
En måte å se prosjektet på
Prosjektdirektør
Prosjektleder
Innføring
Bestiller Leverandør
Delprosjekt Delprosjekt Utvikling
forretning PL :SPK Innføring
PL :SPK
Linje
Delprosjekt
arkitektur
LBF Team Arkitektur Miljø
Team Team
Delprosjekt test Akseptansekr Funksjonell Godkjennings-
iterier test prøve
PL: SPK
Innføring
Produkt-
Drift
eiere
PL:Steria Produksjons
setting
Regelverk PL :Accenture

10. Gjennomføringsplan
Release
3 releaser pr år
• 3 releaser årlig i 3(4) år -> Over til forvaltning
• Er i en konstruksjonsiterasjon året rundt
• Jobber med 2 til 3 releaser i parallell -> Hektiske perioder

11.  www.steria.com
Test i Perform
 Hvem tester hva
 Testprosessen
 Testing i iterasjoner
 Testing og ansvar
 Kontrollpunkter
13/06/2012

12. Hvem tester hva i Perform
 Enhetstest
 Integrasjonstest –
Kontinuerlig integrasjon
 Funksjonell systemtest
Leverandør
 Funksjonell Integrasjonstest
 Kontrollpunkt
DP Test
 Godkjenningsprøve
 Akseptansetest
Linje (funksjonell/IT)
 Produksjonstest

13. Testprosessen i utviklingsteamene
Iterasjon n - 1 Iterasjon n Iterasjon n + 1
Lag og kjør Lag og kjør
enhets- og funksjonelle
integrasjonstester systemtester
Definer og
forfin
Akseptansekriterier funksjonelle Kjør System
pr brukerhistorie testbetingelser Integrasjonstester

14. Testing i iterasjoner
Scrum team
 JUnit-tester
 Utviklers test, enhetstest av java-klasser
 Kan også være integrasjonstester
 Compile-time ved hver bygg av modulen på byggserver
 FlexUnit-tester
 Testing av brukergrensesnittet
 Compile-time
 Fitnesse-tester
 Funksjonelle tester
 Kan være integrasonstester
 Samarbeid mellom utvikler og funksjonell/tester
 Kjøres automatisk en gang i døgnet og gir rapport via mail
 Manuell-testing
 Manuelle kjørebeskrivelser lagret i Quality Center
 Lages og testes av tester på teamet
13/06/2012

15. Testing og ansvar
Iterasjon 1 Iterasjon 2 Iterasjon N - Godkjenning Akseptansetest
Krav Krav Krav Krav
A&D A&D A&D A&D
Kode Kode Kode Kode
Test Test Test Test
Utrulling Utrulling Utrulling Utrulling
Regresjonstestmiljø Regresjonstestmiljø Godkjenningsmiljø Akseptansetestmiljø
Teamansvar Teamansvar Teamansvar
DP-Test ansvar
PERFORM Linjen
 Hvert team tester sin funksjonalitet i hver iterasjon
 Det er et kontrollpunkt etter hver iterasjon
 DP-Test tester leveransen som en helhet
 Linjen mottar prosjektet som et ”vanlig”prosjekt
13/06/2012

16. Kontrollpunkt pr iterasjon
Hver 3. uke godkjennes nye brukerhistorier
 Demo – vise frem hva som er gjort!
 Teamet demonstrerer alt som er nytt
 Delprosjekt forretning tester levert funksjonalitet i
iterasjonen
 Testkvalitet
 Har leverandøren kjørt og passert testene?
 Er test gjennomført i henhold til retningslinjene?
 Kodekvalitet - inspeksjon av koden
 Arkitekturretningslinjer – forholder man seg til
disse?
 Dokumentasjon
 Er systemdokumentasjon ok
 Er driftsdokumentasjon etablert
 Er brukerdokumentasjon laget
 Er leveransedokumentasjon laget
Ikke godkjente brukerhistorier går tilbake til teamet til «ompuss»

17.  www.steria.com
Problemløsning
13/06/2012

18. «Bitene henger ikke sammen»
Avhengigheter
 Team og leverandører hadde testet og fått godkjent sine komponenter
under vegs.
 I Godkjenningsprøven desember 2009 ble det tydelig at «bitene» ikke hang
godt nok sammen.
Flere tiltak ble iverksatt
 «Avhengighetsmøte» hver iterasjon for at alle team
skulle bli bevisst avhengigheter og se hverandre i hvitøyet
 Påbud om å kjøre Demo i felles miljø
 Påbud om å kjøre Integrasjonstester i felles miljø
 Ende til ende tester i løpet av konstruksjonsfasen
 Kunden avskaffet dagbotsanksjoner
13/06/2012

19. Greit nok, men ikke helt sånn vi hadde tenkt…
Avhengigheter
 Funksjonalitet fra en iterasjon pleide
å virke, men ofte ikke 100%
slik kunden hadde tenkt
 Vi slet med å få spesifisert
kravene tydelig nok
 «Jeg vet det når jeg ser det»-
syndromet
Vi innførte
 «Minidemo» – En halvformell demo litt etter halvvegs i en iterasjon
 Var det «sånn» dere hadde tenkt? Nesten, bittelitt mer «slik»…
 Forberedende møte før hver iterasjon
 Lage tydelige akseptansekriterier for brukerhistoriene før iterasjonen
 Kunden tester under vegs i iterasjoner – kan rette feil/misforståelser innenfor
iterasjonen i stedet for etterpå
13/06/2012

20. Hva skal vi egentlig lage nå?
Jobbing med produktkøen hele tida
 Utfordring: For lite gjennomtenkte og bearbeidede tanker fra
løsningsbeskrivelse.
 Når tanker om ny funksjonalitet kommer for brått på teamene blir det vanskelig
å levere riktig og effektivt
 Vanskelig å implementere og teste noe som er vagt.
Tiltak
 Løpende løsningsbeskrivelse. Jobbe med produktkø hele tiden for å få med den
ferskeste informasjonen.
 Involvere teamene i løsningsbeskrivelse og estimering. Det hjelper lite om noen
andre vet hva som skal lages.
 Skrive nødvendige og tilstrekkelige akseptansebetingelser for hver
brukerhistorie.
13/06/2012

21.  www.steria.com
Forbedringer
13/06/2012

22. Når feilene flyr rundt i lokalet …
Innfør Bug Board
 Utfordring: Effektiv fordeling av feil i godkjenningsperioden
 Prinsipp: Teamet som har laget feilen retter feilen
 Daglig Bug Board for alle 3 leverandører
 Analyse og feilretting
13/06/2012

23. Vi vil ha god kvalitet…
Innfør Kontrollpunkt
 Utfordring: Sikre god kvalitet på tvers av leverandører og team
 Felles kontrollpunkt for alle leverandører
 Kodekvalitet
 Testkvalitet
 Dokumentasjon
13/06/2012

24. Når skal vi teste…
Test tidlig og kontinuerlig
 Utfordring: Levere gjennomtestet funksjonalitet med lite feil i hver release
 Teste tidlig på gjennomgående funksjonalitet
 Teste kontinuerlig innenfor samme release
 Prioritere å rette feil framfor ny funksjonalitet
 Test grundig nok. Slurv kommer i retur på et tidspunkt som passer dårligere
13/06/2012

25.  www.steria.com
Erfaringer
13/06/2012

26. Vær smidig -> Ta læring og fjern hindringer
Viktig å tilpasse seg virkeligheten
Smidige prosjekter har mange læringspunkter
 Hvis noe ikke virker …
 Gi det en sjanse til
 Hvis det fortsatt ikke virker
 Fjern det eller forandre på det!
13/06/2012

27. Jobbe sammen
Vi er alle i samme båt
 Samarbeid innad i team må fungere
 Samarbeid mellom team må fungere
 Samarbeid mellom leverandører må fungere
 Min leveranse har ingen verdi før den virker korrekt sammen med resten
13/06/2012 27

28. Gjensidig avhengighet
Jobb for samarbeid
 Gjør personer /team/miljøer gjensidig avhengige av hverandre
 Fjern sanksjoner og mekanismer som motvirker samarbeid
 Bruk gulrot og incentiver i stedet for pisk og sanksjoner
13/06/2012

29.  www.steria.com
Hvordan gikk det til slutt?
13/06/2012

30. Oppsummering
Hvordan gikk det med Perform?
 Prosjektet leverte alle planlagte releaser fra høsten 2008 til februar 2012
 En release ble utsatt med en måned
 En release ble redusert i omfang
 Alle andre releaser med riktig tid og scope
 SPK klarte ved hjelp av Perform å saksbehandle Pensjonsreformen fra høsten
2010
 Dette er det klart største prosjektet til SPK og innføringen har gått mye bedre
enn ved forrige innføring av kjernesystem
 SPK har fått en ny plattform og et nytt, framtidsrettet saksbehandlingssystem
 Testprosessen og tilpasningene som ble gjort må ha vært bra 
13/06/2012