Arne Semb: Hvordan smidig testing gir økt kvalitet
•Download as PPTX, PDF•
1 like•910 views
Holdt på frokostseminar hos Bouvet, mars 2015
Recommended
More Related Content
More from Bouvet ASA
More from Bouvet ASA (14)
Arne Semb: Hvordan smidig testing gir økt kvalitet
- 1. Hvordan smidig testing gir økt kvalitet Praktiske erfaringer fra utvikling av en kritisk løsning med høye kvalitetskrav
- 2. 2 Om Statnett • Statnett er systemansvarlig i det norske kraftsystemet • Ca 11000 km med høyspentlinjer • 150 stasjoner over hele landet • Driften overvåkes av en landsentral og tre regionsentraler
- 3. 3 Kraftsystemet er en balansekunst • Produksjon og forbruk svinger mer enn før • Kreves fleksibilitet, kapasitet og velfungerende kraftmarkeder
- 4. • Holde balansen • Forbruk = Produksjon • Transport og markeder 4 Hvordan fungerer kraftmarkedet?
- 5. • I Norge produseres mest vannkraft • I utlandet produseres kraft også fra andre kilder, som kullkraft og kjernekraft • Strømforbruket fordeles mellom industri og private husholdninger • Strøm er en ekstrem ferskvare • Kraftbalansen må holdes 5 Produksjon og forbruk
- 6. • Strømnettet transporterer strøm til der den brukes • Ikke hensiktsmessig å bygge flere kraftledninger 6 Transport
- 7. • Nordisk kraftbørs Nord Pool • Kraftleverandører kjøper • Kraftprodusentene selger • Prisen fastsettes mellom tilbud og etterspørsel • Fri konkurranse i kraftmarkedet 7 Handel
- 8. • Er Norsk Sluttstrøm løsningen? – Video 8 Hva hvis det blir for mye strøm?
- 9. • Gammel IT løsning • Hva med fremtiden? • Nye EU-krav, nye markeder • Ny løsning påstartet 2009 • Fremtidsrettet arkitektur • LARM prosjektet leverer nytt MMS 9 Statnetts systemansvar
- 10. 10 LARM LARMSystem B System C System A System D LARM kommuniserer med mange systemer. Stor meldingsflyt. Relativt store mengder sanntidsdata.
- 11. 11 Smidig testing – normal situasjon • Testing skjer under sprintene • Kontrollpunkt etter hver sprint • Leveranser i hver sprint
- 12. 12 Smidig prosjekt Sprint 1 Sprint 1 Sprint 1 Sprint 2 Sprint 2 Sprint 2 Sprint 3 Sprint 3 Sprint 3 KP 1 KP 2 Normal smidig testing. Kontrollpunkt hver 3. uke • Gradvis testing i hvert KP • Tilpasset kontrakt • Hvordan oppnå kvalitet?
- 13. • Manglet plan på test • Stykkvise leveranser • Kritisk funksjonalitet ble levert sent • Dårlig koordinasjon mot tilgrensende systemer • Tidvis ustabile testmiljøer • Planer uten “slakk” • Tilgjengelighet på kritiske ressurser 13 Smidig prosjekt, smidig testing – fortsatt utfordringer for test og kvalitet
- 14. 14 Hvordan ble det gjort? Fortsetter… • Hyppige minidemoer under konstruksjon – Raskere å oppdage misforståelser og svakheter – Raskere å komme frem til endelig løsning – Tidlig testing av løsningen • Tettere samarbeid med leverandør på test – Høy kvalitet på test fra leverandør
- 15. 15 Hvordan ble det gjort? Fortsetter… • Kontinuerlig testing gjennom kontrollpunktene – 2 testmiljøer som oppdateres annenhver uke – Ukentlige testrapporter fra leverandør – Formelt kontrollpunkt hver tredje uke • Leverandør må være forutsigbar på leveransene – Felles plan med leverandør – Forutsigbare leveranser – 3 ukers detaljert plan
- 16. 16 Hvordan ble det gjort? Fortsetter… • Tilgrensende systemer – Synkronisering av leveranser – Koordinert testing – Risiko redusering • Stabile testmiljøer – Styrte oppgraderinger – Miljøvakt – Prioritert tilgang på instanser – Detaljert installasjonsplan
- 17. 17 Hvordan ble det gjort? • Deltagelse i fremdriftsplaner – Innspill i fremdriftsplan – Risiko redusering • Tilgang på kritiske ressurser – Bestilling av testere – Ferie- og fraværslister – Nedprioritere fravær – Minimere linjeoppgaver
- 18. • Kontinuerlig testing • Gode ukentlige testrapporter • Test ideer for utforskende testing • God kontroll test caser 18 Hvordan tilpasset vi smidig testing for å få økt kvalitet? Sprint 1 Sprint 1 Sprint 1 Sprint 2 Sprint 2 Sprint 2 Sprint 3 Sprint 3 Sprint 3 KP 1 KPtestKPtest KPtest KPtest KPtest KP 2 KPtest Kontinuerlig smidig testing. 2 testmiljøer. Kontrollpunkt hver 3. uke
- 19. • Felles plan for test • Minidemoer flere ganger • Leveransene i logisk rekkefølge • Kontinuerlig testing • Forutsigbare planer • Stabile testmiljøer • Planer med “slakk” • Kritiske ressurser tilgjengelig 19 Smidig prosjekt, smidig testing – hvilken effekt gav dette?
- 20. 20 Hvor mye bedre ble kvaliteten? • Kvaliteten i produksjon har hele tiden vært bra • Kvaliteten ble målt på følgende måte: – Antall vekter i leveransen (1 vekt = x antall timer) – Antall avvik funnet under akseptansetest Avvik funnet totalt Avvik funnet akseptansetest Vekt Avvik/vekt DL4 469 176 150 1,17 DL5 420 164 180 0,91 DL6 921 121 310 0,39
Editor's Notes
- Statnett er systemansvarlig i det norske kraftsystemet, såkalt TSO (Transmission System Operator). Dette innebærer å drifte om lag 11000km med høyspentlinjer og 150 stasjoner over hele landet. Driften overvåkes av en landsentral og tre regionsentraler. Statnett har også ansvaret for forbindelser til Sverige, Finland, Russland, Danmark og Nederland. Statnett er et statsforetak opprettet i henhold til Statsforetaksloven og eid av staten ved Olje- og energidepartementet.
- Samfunnet trenger et stabilt kraftsystem og systemet settes stadig på prøve. Både produksjon og forbruk svinger mer enn før og utfordrer kraftbalansen. For å opprettholde driftssikkerhet kreves fleksibilitet, kapasitet og velfungerende kraftmarkeder. Kraftsystemet er en balansekunst.
- Kraftmarkedet handler om å holde balansen. For at systemet skal fungere må det være balanse mellom hvor mye vi bruker og hvor mye strøm vi produserer - hvert år - året rundt. Mellom produksjon og forbruk går det to veier: Handelsveien og Transportveien.
- Kraft lages fra mange ulike kilder. I Norge produserer vi mest vannkraft, men det satses også på andre former, som vindkraft, bioenergi og gasskraft. I utlandet produseres kraft også fra andre kilder, som kullkraft og kjernekraft. Strømforbruket i Norge er fordelt mellom industri, næringsliv, offentlig virksomhet og private husholdninger. Strøm er en ekstrem ferskvare: Den må brukes i samme sekund som den lages. Hver gang du setter mobilen din til lading, må akkurat den mengden strøm som laderen krever produseres samtidig ved et kraftverk, slik at det hele tiden er balanse mellom hvor mye vi putter inn og henter ut av strømnettet. Kraftbalansen må holdes.
- Strømmen som lages føres via strømnettet til der den brukes. Strømnettet kan sammenlignes med veinettet: Statnett styrer sentralnettet, som er motorveiene i systemet, og derfra går det over i fylkes- og kommuneveier som tar strømmen helt frem til der du bor. Siden det ikke er hensiktsmessig å bygge flere kraftledninger ved siden av hverandre, er strømnettet et såkalt naturlig monopol. Hvert sted har bare ett nettselskap, og som forbruker kan du følgelig ikke velge fritt mellom nettselskapene. Som monopolvirksomhet er nettselskapene regulert av myndighetene. Strømnettet er et spleiselag, og alle som lager og bruker kraft betaler en nettleie.
- Hver dag fastsettes strømprisen på den nordiske kraftbørsen Nord Pool som ligger utenfor Oslo. Det skjer gjennom budrunder: Kraftleverandørene (de som kjøper inn kraft på strømkundenes vegne og selger den videre til deg og meg) melder inn hvor mye de er villige til å gi for den kraftmengden som trengs det kommende døgnet. Kraftprodusentene melder på sin side hvor mye de er villig til å selge strømmen sin for. Så går budrunden sin gang inntil prisene møtes. Jo større forbruk, dess dyrere produksjonsformer må man fase inn, og dess høyere blir kraftprisen. Prisen fastsettes dermed av samspillet mellom tilbud og etterspørsel. Det er fri konkurranse i kraftmarkedet, og du som forbruker kan fritt velge hvilken kraftleverandør du vil kjøpe strøm fra.
- Den gamle løsningen ble lagd i 1993. Den var basert på gammel arkitektur, som ikke kunne tilfredsstille nye krav og utfordringer. Derfor måtte den byttes ut. Statnett vurderte «hyllevare» eller å lage ett MMS selv, og valgte det siste. Oppstart i 2009. LARM ble gradvis faset inn over 7 delleveranser, ca 2 i året. Hele den gamle løsningen var erstattet på høsten 2014, og det gamle systemet ble skrudd helt av og fjernet. MMS er Market Management System for moderne elektrisitets markeder. MMS inneholder avanserte funksjoner som støtter alle marked relaterte funksjoner som utføres av markedsaktører, ISO (Independent System Operators), RTO (Regional Transmission Operators) og TSO (Transmission System Operators).
- LARM mottar meldinger fra flere omkringliggende systemer, både interne og eksterne. Siden strøm er ferskvare, både sendes og mottas det mange meldinger. Alt foregår i sanntid for at det skal være mulig å holde kraftbalansen på 50Hz.
- Det var tett samarbeid med leverandør på krav, design og løsning. På området test og kvalitet, var det fortsatt litt "de" og "vi" holdning. Testmiljøene er ganske ulike produksjon, derfor er det ikke alt som kan verifiseres gjennom kontrollpunkter.
- PS2000 kontraktsmal ble brukt. Den ble tilpasset Statnetts ønske om fokus på risikokontroll og god kvalitet. Det ble derfor tatt med en godkjenningsprøve på slutten i prosjektet, for å sikre god testing i en komplisert løsning. Svært vanskelig å verifisere løsningen gjennom kontrollpunktene, delvis grunnet testmiljøene og delvis at funksjonaliteten ble levert stykkvis.
- En felles plan med leverandør på test og kvalitet manglet fullstendig. Leverandør hadde sitt testopplegg og kunden sitt. Lite samarbeid. Prioritering i sprintene ble utelukkende gjort av leverandør, uten hensyn til testbarhet og helhetstenking. Ofte ble kritisk funksjonalitet levert i de siste sprintene. Dette gjorde testingen svært vanskelig og førte til at kritisk funksjonalitet ble levert dårligst testet videre. Flere tilgrensende systemer måtte endre på sine grensesnitt, da LARM skulle erstatte den gamle løsningen. For dårlig synkronisering førte til testing i utakt. Testmiljøene var ustabile. Mye skyldes at intern IT oppgraderte servere osv. midt under kritisk testing, som førte til nedetid. Databaser gikk fulle, full stans i meldinger. Fremdriftsplanene var lagt uten slakk mellom de forskjellige fasene. Det fikk store konsekvenser ved forsinkelser. Kritiske ressuser fra linjen var ofte på kurs eller tjenestereiser under kritiske testfaser. De var ikke der da vi trengte dem.
- «Opplæring» av leverandør i lavnivå testing, som førte til oppdagelse av feil i tidligere testfaser. Mer utfyllende avviksrapporter. Testleder med tidlig i kravspesifisering. De første minidemoene var bare en presentasjon av skjermbilder. Der fikk man en ide om hvordan leverandør så for seg løsningen. Allerede her kunne kunden se om det svarte til forventninger, om standarder ble gjenbrukt og om alle retningslinjer ble fulgt. Etter hvert ble det kjørbare skjermbilder, ofte også vist ved bruk av simulator. Da fikk kunden se dataflyt og presentasjon av data i skjermbilder. De gav verdifull informasjon og mulige korreksjoner kunne gjøres tidlig.
- Samarbeid med leverandør ble iverksatt. Statnett kom med innspill på hvilken rekkefølge som var ønsket, i forhold til testbarhet og avhengigheter. Leverandør satt så opp sin plan der dette ble tatt hensyn til i størst mulig grad. På den måten ble det forutsigbare planer, som ble oppdatert hver 3.uke. Lettere for Statnett å lage planer og sette inn testressurser der det kom mye eller kritisk funksjonalitet. Ved å ha to parallelle testmiljøer med de samme muligheter i, kunne Statnett teste mer kontinuerlig på stadig ny funksjonalitet. Dettet fordrer gode ukentlige testrapporter, som gav oversikt over hva som kunne testes og hva som hadde begrensinger og kjente feil. På den måten ble funksjonalitet testet tidligere enn tidligere, og det ble funnet mye mer feil. Det ble levert bedre kvalitet til senere testnivåer.
- Gjennom tidligere leveranser erfarte ansvarlige for tilgrensende systemer at våre fremdriftsplaner var å stole på. Vi leverte alltid på tid med det innholdet vi sa. På den måten bygde vi tillit og forutsigbarhet. Det gjorde over tid at tilpasninger i tilgrensende systemer ble gjort i takt med vår fremdriftsplan, slik at man kunne få til synkroniserte leveranser og koordinert testing. Dette førte igjen til redusert risiko. Ved gode planer og tidlige meldinger om når vi skulle teste, klarte vi å styre det slik at testmiljøene ble oppgradert utenom kritiske testperioder. All installasjon og oppgradering ble utført før kritiske tester. Vi innførte miljøvakt på testserverne, slik at man unngikk stans ved feil. Kunne være utfall av tjeneste på en server som da måtte restartes, disker som gikk fulle, osv. Av noen tilgrensende systemer finnes det kun en instans. Ved å melde fra tidlig, klarte vi å få prioritet på disse, slik at vi kunne benytte dem under våre kritiske tester. Detaljert installasjonsplan sørget for at all installasjon av både programvare og maskinvare før kritisk test ble gjort før testing startet. Førte til at funksjonell testing kunne starte fra dag 1.
- Ved å la testleder komme med innspill i fremdriftsplanen, ble det lagt mer slakk i planene. Dette gav rom for uforutsette hendelser (som alltid kan skje), slik at risiko for produksjonssetting ble redusert. Bedre styring på risiko, ved at risiko plan ble oppdatert og evt. tiltak utført fortløpende. Ved å ha gode forutsigbare planer med høy tiltro, klarte vi å få lagt planlagte kurs og annet fravær for kritiske ressurser utenom kritiske testperioder. Detaljert fraværsplan i god tid, gav oss påvirkningsmulighet til når det ble planlagt ferier og annet fravær. Totalt gav det oss bedre tilgang på kritiske ressurser gjennom hele testperioden.
- Det ble testet kontinuerlig også tidligere, men da på samme versjon over 3 uker. Fordelen vi fikk nå, var at versjonen ble oppdatert hver uke, slik at vi kunne teste ny funksjonalitet tidligere. Smartere måte å teste på. Gode ukentlige testrapporter med oversikt over hva som er klart for test, hva som kan testes delvis med kjente feil, og evt hva som ikke kan testes. Opplæring av leverandør til å styre utforskende test på en bedre måte ved bruk av testideer. F.eks. bare bruke tastatur, kun sjekke datovelgere i Larm, sjekke at alle tabeller oppfører seg likt, osv. Test caser ble oppdatert og skrevet om, slik at de også tok mer hensyn til negativ testing – og ikke bare "happy case". Beregninger ble kjørt gjennom FitNesse og utført av Jenkins ved bygging.
- Vi testet ikke flere timer, men vi testet smartere. Mye tettere samarbeid med leverandør på test, der Statnett testet sammen med leverandør i deres tester under deres systemtest. Mer utfyllende avviksrapporter, riktigere testing tidlig under utvikling. Involverte testleder på minidemoer. Gode avklaringer om løsningen på et tidlig tidspunkt, minidemo fungerte som tidlig test. Tettere samarbeid med leverandør på sprintplanlegging, slik at funksjonalitet leveres i "logisk" rekkefølge i forhold til testing. 3 ukers plan med "hva leveres" og "hva kommer kanskje". Testing ble spredd gjennom hele leveransen, feil ble oppdaget tidlig, raskt å fikse. Formelt kontrollpunkt hver 3.uke, men ukentlige testrapporter fra leverandør. Da fremdriftsplanen ble lagt, ble den fulgt. Ingen forsinkelser, leveranse i produksjon med høy kvalitet. Bygde tillit hos andre, det vi sa ble utført. Synkronisering av planer og leveranser. Stabile testmiljøer sørget for god testing hele veien. Unngå oppdatering av servere og annen software i testperioder. Sørge for prioritert tilgang til instanser, miljøvakt under testperioder og detaljert installasjonsplan. Slakk i planene sørget for å fange opp uforutsette forsinkelser. God risikokontroll. Troverdig plan sikret bestilling av kritiske ressurser i god tid, slik at nødvendige ressurser var tilstede når vi trengte de.
- Kvaliteten var alltid god i produksjon. Men for å kunne måle kvaliteten på godkjenningsprøven, ble det gjort ved at vi tok antall avvik funnet i godkjenningsprøven og delte på antall vekter i delleveransen. Forholdstallet gikk kraftig ned, noe som tyder på bedre kvalitet. Det ble også funnet flere feil gjennom hele delleveransen, men det kan nok også skyldes at det ble registrert flere feil i DL6 også enn tidligere.