Spor 2 kontinuerlig forbedring av testprosessen

  • 378 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
378
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Kontinuerlig forbedring av testprosessenErfaringer fra prosjekt PerformSteria fagdag 2012Kjetil Røe, PMPAnders 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, ScrumMaster13.06.2012 2
  • 3. AgendaDette skal du få høre om Prosjekt Perform Test i prosjekt Perform Problemløsning Forbedringer Erfaringer Oppsummering 13/06/2012 3
  • 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. 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. 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. Ekstern risikovurderingFra Metier mars 2010 13/06/2012 7
  • 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. 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. 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.comTest 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 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. 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. 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.  www.steria.comProblemløsning13/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»- 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. 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.comForbedringer13/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.comErfaringer 13/06/2012
  • 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. 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. 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.  www.steria.comHvordan gikk det til slutt? 13/06/2012
  • 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