Kontinuerlig forbedring av testprosessenErfaringer fra prosjekt PerformSteria fagdag 2012Kjetil Røe, PMPAnders Vindvad, PM...
Hvem er vi?                 Kjetil Røe              Anders Vindvad                 Sterias Prosjektleder   ScrumMaster i S...
AgendaDette skal du få høre om   Prosjekt Perform   Test i prosjekt Perform   Problemløsning   Forbedringer   Erfarin...
 www.steria.comProsjekt PerformStatens Pensjonskasse 2008 - 2011    780.000 prosjekttimer    180 personer, ca 80 fra SP...
Hvorfor ble prosjekt Perform etablert?4 kritiske forretningsmessige drivere1. Arbeidsavklaringspenger   Ikrafttredelse 01....
Hvorfor smidig gjennomføring?SPK skulle i årene 2008 - 2011 Bytte ut kjernesystemet bit for bit Bytte til et ukjent rege...
Ekstern risikovurderingFra Metier mars 2010 13/06/2012   7
Risikoanalyse fra PerformI tidlig fase var dette en risikosport                                          Øyeblikksbilde f...
Perform organiseringEn måte å se prosjektet på                                           Prosjektdirektør                 ...
Gjennomføringsplan                                                                      Release                           ...
 www.steria.comTest i Perform    Hvem tester hva    Testprosessen    Testing i iterasjoner    Testing og ansvar    K...
Hvem tester hva i Perform     Enhetstest     Integrasjonstest –      Kontinuerlig integrasjon     Funksjonell systemtes...
Testprosessen i utviklingsteamene  Iterasjon n - 1                        Iterasjon n              Iterasjon n + 1        ...
Testing i iterasjonerScrum team JUnit-tester             Utviklers test, enhetstest av java-klasser             Kan ogs...
Testing og ansvarIterasjon 1           Iterasjon 2               Iterasjon N - Godkjenning      Akseptansetest  Krav      ...
Kontrollpunkt pr iterasjon  Hver 3. uke godkjennes nye brukerhistorier        Demo – vise frem hva som er gjort!         ...
 www.steria.comProblemløsning13/06/2012
«Bitene henger ikke sammen»Avhengigheter Team og leverandører hadde testet og fått godkjent sine komponenter  under vegs....
Greit nok, men ikke helt sånn vi hadde tenkt…Avhengigheter Funksjonalitet fra en iterasjon pleide  å virke, men ofte ikke...
Hva skal vi egentlig lage nå?Jobbing med produktkøen hele tida Utfordring: For lite gjennomtenkte og bearbeidede tanker f...
 www.steria.comForbedringer13/06/2012
Når feilene flyr rundt i lokalet …Innfør Bug Board Utfordring: Effektiv fordeling av feil i godkjenningsperioden Prinsip...
Vi vil ha god kvalitet…Innfør Kontrollpunkt Utfordring: Sikre god kvalitet på tvers av leverandører og team   Felles kon...
Når skal vi teste…Test tidlig og kontinuerlig Utfordring: Levere gjennomtestet funksjonalitet med lite feil i hver releas...
 www.steria.comErfaringer 13/06/2012
Vær smidig -> Ta læring og fjern hindringerViktig å tilpasse seg virkelighetenSmidige prosjekter har mange læringspunkter...
Jobbe sammenVi er alle i samme båt Samarbeid innad i team må fungere Samarbeid mellom team må fungere Samarbeid mellom ...
Gjensidig avhengighetJobb for samarbeid Gjør personer /team/miljøer gjensidig avhengige av hverandre Fjern sanksjoner og...
 www.steria.comHvordan gikk det til slutt? 13/06/2012
OppsummeringHvordan gikk det med Perform? Prosjektet leverte alle planlagte releaser fra høsten 2008 til februar 2012    ...
Upcoming SlideShare
Loading in...5
×

Spor 2 kontinuerlig forbedring av testprosessen

441

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
441
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Spor 2 kontinuerlig forbedring av testprosessen

  1. 1. Kontinuerlig forbedring av testprosessenErfaringer fra prosjekt PerformSteria fagdag 2012Kjetil Røe, PMPAnders Vindvad, PMP 13/06/2012
  2. 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, ScrumMaster13.06.2012 2
  3. 3. AgendaDette skal du få høre om Prosjekt Perform Test i prosjekt Perform Problemløsning Forbedringer Erfaringer Oppsummering 13/06/2012 3
  4. 4.  www.steria.comProsjekt PerformStatens 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. 5. Hvorfor ble prosjekt Perform etablert?4 kritiske forretningsmessige drivere1. Arbeidsavklaringspenger Ikrafttredelse 01.03.2010  Samordne midlertidige ytelser fra NAV2. Pensjonsreform Ikrafttredelse 01.01.2011  Nye regler for offentlig tjenestepensjon3. 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å nytt4. 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. 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 kvalitetSPK valgte en smidig gjennomføringsmodell med Scrum ogPS2000 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. 7. Ekstern risikovurderingFra Metier mars 2010 13/06/2012 7
  8. 8. Risikoanalyse fra PerformI 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. 9. Perform organiseringEn 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. 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. 11.  www.steria.comTest i Perform Hvem tester hva Testprosessen Testing i iterasjoner Testing og ansvar Kontrollpunkter 13/06/2012
  12. 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. 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. 14. Testing i iterasjonerScrum 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. 15. Testing og ansvarIterasjon 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 TestUtrulling Utrulling Utrulling UtrullingRegresjonstestmiljø Regresjonstestmiljø Godkjenningsmiljø AkseptansetestmiljøTeamansvar Teamansvar Teamansvar DP-Test ansvarPERFORM 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. 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 lagetIkke godkjente brukerhistorier går tilbake til teamet til «ompuss»
  17. 17.  www.steria.comProblemløsning13/06/2012
  18. 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. 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»- syndrometVi 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. 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. 21.  www.steria.comForbedringer13/06/2012
  22. 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. 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. 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. 25.  www.steria.comErfaringer 13/06/2012
  26. 26. Vær smidig -> Ta læring og fjern hindringerViktig å tilpasse seg virkelighetenSmidige 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. 27. Jobbe sammenVi 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. 28. Gjensidig avhengighetJobb 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. 29.  www.steria.comHvordan gikk det til slutt? 13/06/2012
  30. 30. OppsummeringHvordan 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×