Spor 2   kontinuerlig forbedring av testprosessen
Upcoming SlideShare
Loading in...5
×
 

Spor 2 kontinuerlig forbedring av testprosessen

on

  • 579 views

 

Statistics

Views

Total Views
579
Views on SlideShare
579
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Spor 2   kontinuerlig forbedring av testprosessen Spor 2 kontinuerlig forbedring av testprosessen Presentation Transcript

  • Kontinuerlig forbedring av testprosessenErfaringer fra prosjekt PerformSteria fagdag 2012Kjetil Røe, PMPAnders Vindvad, PMP 13/06/2012
  • 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
  • AgendaDette skal du få høre om Prosjekt Perform Test i prosjekt Perform Problemløsning Forbedringer Erfaringer Oppsummering 13/06/2012 3
  •  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
  • 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
  • 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
  • Ekstern risikovurderingFra Metier mars 2010 13/06/2012 7
  • 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
  • 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
  • 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
  •  www.steria.comTest i Perform Hvem tester hva Testprosessen Testing i iterasjoner Testing og ansvar Kontrollpunkter 13/06/2012
  • 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
  • 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
  • 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
  • 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
  • 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»
  •  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. 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
  • 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
  • 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
  •  www.steria.comForbedringer13/06/2012
  • 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
  • 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
  • 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
  •  www.steria.comErfaringer 13/06/2012
  • 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
  • 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
  • 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
  •  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  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