De fleste kjenner Tomras pantemaskiner, som er godt utbredt i store deler av verden.

Transkript

1 Risikoanalyse i ukjent terreng om farene ved innovasjon og test Av Audun Urke, Sogeti Norge AS Innlegget tar for seg risiko og test i prosjekter preget av innovasjon. Innovasjon er som regel ikke farlig, men der er farer som kan gjøre at vi ikke når opp til forventningene til produktkvaliteten vi er med på å utvikle. Hvordan kan vi håndtere en slik risiko som testere? Oppfinnelsen av hjulet var en av de viktige innovasjonene vi har hatt hittil i historien, og i dette innlegget skal vi bruke den for å illustrere risiko ved innovasjon generelt. Flere tips er dessuten baserte på erfaringer fra test i et utviklingsprosjekt på Tomra. T-9: siste generasjon pantemaskin De fleste kjenner Tomras pantemaskiner, som er godt utbredt i store deler av verden. Tomra har laget en ny generasjon panteautomat som fornyer og forbedrer teknologien sin. På innsiden av automatene til Tomra finner vi blant annet sensorbasert høyteknologi og kompliserte embedded systemer. Målet for prosjektet som utviklet T9 var en maskin som er raskere, renere og som har mulighet for å håndtere andre emballasjetyper som ikke kun er sirkulære. Den store innovasjonen var verdens første 360 gjenkjenningssystem.

2 En flaske skal raskt analyseres uavhengig hvordan den legges inn i maskinen, og det betyr bearbeiding av et stort antall former, strekkoder, pantehastigheter, sikkerhetsmerker for å nevne noe. I tillegg kom mye nytt innen hardware, operativsystem, måten softwarene i maskinen samarbeider og kommuniserer på, og mye mer. Testteamet for T9 prosjektet besto av en testleder og en fast tester, hvor det ble hentet inn flere spesialiserte testressurser ved behov. Vi skal utover se litt mer på hvordan testingen tok hensyn til risiko. Men først er det greit å ta for seg hva vi mener med embedded testing. Embedded testing Hva er et embedded system? Det er lettere å peke på de enn å fortelle hvilke trekk som forener dem. Det er alt fra mobiltelefoner til biler. Det de har til felles er at de interagerer med den relle fysiske verden, for eksempel gjennom sensorer, og kontrollerer en spesifikk hardware. Siden det er veldig forskjellig fra å teste en mobiltelefon fra bilbremser, kan vi ikke peke på en mal eller en enkelt best practice som kan gjelde for samtlige typer embedded testing. Men uansett hvilken testtilnærmelse vi velger vil vi måtte ta hensyn til risiko. Innovasjon av forretningshensyn Hva er innovasjon? Det er vel en eller annen form for fornyelse? De fleste må fornye seg i dag av forretningshensyn: Vi vil kjappere ut til kunden med produktet og redusere Time2Market. Vi vil

3 redusere kostnadene og sikre oss Return On Investment. Vi må utvikle nye produkter og bli mer tilgjengelige på flere plattformer og kanaler. Test av trendene Vår oppgave er å kunne teste disse nye produktene, og det er dette som er hovedfokuset i dette innlegget. Bare det å teste kan jo sies å være med på å redusere risiko. Utfordringene fremover er jo mange: Internet of Things, Skyen, Big Data, Bring Your On Device. Felles for mange av disse er at de setter store krav til sikkerhet og personvern. Innovere oss som testere Og vi må heller ikke glemme å selv innovere oss, vi testerne, for å kunne utnytte ny teknologi og kunnskap for å kunne teste riktig, effektivt, bredere osv. For å eliminere risiko har vi blant annet tatt innover oss smidige utviklingmetoder. Automatiseringsverktøy har gjort det mulig å kjøre flere og bredere tester. Vi har forsøkt å få test inn så tidlig som mulig i prosjektene og ved reviews av kravspesifikasjoner og annen dokumentasjon. Disruption Innovasjonen og fornyelsen kan komme som en plutselig og banebrytende nyhet, som for eksempel dannelsen av Universet. Og innføringen av en ny idè, og dermed en radikal endring, er ofte det man legger i begrepet «disruption». Mange tenker kanskje på IPhonen som et eksempel. Denne typen innovasjon kan gi utfordringer siden vi ikke helt vet hva det er best å sammenlikne med. Sustaining innovation Innovasjonen kan også komme sakte med sikkert, som evolusjonen man tilpasser seg nye krav og muligheter fra en verden som stadig er i endring. «Sustaining innovation» kalles det ofte. Vi kan kanskje da støtte oss på tidligere testmetodikk og resultater, men det må ikke bli noen hvilepute. Produktrisiko: vi når ikke forventningene til kvalitet Der er flere definisjoner på risiko. Det er vanlig å se risiko som noe negativt, som potensiale for at noe uønsket skal inntreffe. La oss her si at produktrisiko er faren for at leveransen og resultatet ikke når opp til kvaliteten vi forventer det skal ha. Hva er sannsynligheten for at en feil kommer til syne, og hva er konsekvensene hvis den preger produktet? Hvordan kan vi finne sannsynligheten for feil når vi mangler informasjon om hvilke risiko som kan oppstå, hvor de kan oppstå og hvordan og hvorfor? Og hvordan kan vi vite konsekvensene av dem når vi egentlig ikke helt vet hva vi skal teste, i hvert fall ikke i tidlige stadier? Her kan feil som slipper gjennom fra arbeidet med produktrisikoen skape forsinkelser og budsjettoverskridelser som igjen kan utgjøre prosjektrisko. Kort sagt, vi har en utfordring med at vi mangler informasjon. Metoder og verktøy for risikostyring

4 For å kunne demme opp mot det å mangle informasjon, må vi kunne metoder og verktøy for risikostyring. Ulike metoder og verktøy har ulike egenskaper og muligheter, og vi og hjelpemidlene må jobbe mot det samme målet. Hvis ikke, som vi ser på illustrasjonen, kan det bli vanskelig. Det er vanlig å se metoder for risikostyring ut fra noen faser eller trinn: identifisere trusler evaluere og vurdere truslene bestemme risikoen, altså sannsynlighet og konsekvens finne måter å redusere risikoene prioritere risikoreduksjonen ut fra en strategi man utvikler Risikostyring og informasjon Det er i de to første fasene at vi i størst grad står overfor utfordringer som skyldes manglende informasjon. Det er jo her vi plukker ut faremomenter vi skal bruke tid på å teste fremover. Vi må identifisere det som kan bli en bekymring, vite hva vi skal teste, hvilke egenskaper vi skal teste for. Vi må også analysere de risikoene vi finner for å si mer om hvor grundig vi skal teste dette. Det vi ikke vet, det har vi ikke godt av. Hvordan identifisere og analysere risiko ved innovasjon? Så hva gjør vi? Vel, vi vet fra teststatistikk generelt at utviklingsfeil pleier å være hyppige der funksjonaliteten er kompleks, helt ny eller at et tidligere produkt er tilpasset på en grunnleggende måte. Det vil også ha sammenheng med tiden vi har til disposisjon og hvilke teknikker og verktøy som benyttes. Var der ofte feil i et sammenliknbart tidligere prosjekt, har disse ofte en tendens til å gjenta seg. Jo flere grensesnitt, jo større mulighet for integrasjonsfeil. Og en del prosjektrisikoer kan også nevnes, som kommunikasjon og teamsammensetting. Kort sagt: endringer kan bety feil. En slik statistisk kunnskap må vedlikeholdes og kvalitetssikres, og vil nok endre seg avhengig av typer produkt, utviklingsmetodikk og tilgjengelig teknologi. Den er et fint grunnlag for å sette opp mulige risiko items tidlig i et prosjekt. Kanskje også som grunnlag for å velge videre teknikk for risikoidentifisering og analyse, og hvor formell denne skal være. Sjekklister for å finne risiko items

5 Vi kan bruke den statistiske kunnskapen som over, eller vi kan ta utgangspunkt i funksjonelle og ikkefunksjonelle egenskaper. Utfordringen er å forestille seg enhver situasjon som kan innebære en risiko. Hva kan gå galt hvis produktet ikke går over i riktig ny tilstand? Er det en sjanse for at data går tapt eller korrumperes? Vi har kanskje vært inne på flere av disse hensynene tidligere i prosjektfasen, for eksempel under kravspesifiseringen, under designen og andre forberedende faser. Men vi sitter kanskje likevel igjen med frykten for at vi har glemt noe, oversett noe: hva er det vi ikke har tenkt på? Uansett kan vi gå videre med sjekklistene, de krav satt fra prosjektledelse og interessenter, og det testgrunnlaget vi har å basere oss på. Men der er også teknikker som kan hjelpe oss. Teknikker Det finnes mange teknikker for risikoidentifisering og analyse. De går fra å være uformelle sjekklister, som vi nettopp har sett eksempel på og workshops med interessenter - til mer formelle metoder som Hazard Analysis og Failure Mode and Effect Analysis. Teknikkene brukes ofte basert på de krav, den design og den implementasjon som er ferdig på tidspunktet for risikoanalysen. Og på den måten vil teknikker og bruken av dem gjenspeile test basisen, altså den informasjonen som definerer den systematferden vi krever. Det kan være lurt å tenke gjennom hvor mye test basis legger føringer for risikostyringen. For prosjekter med mye innovasjon, kan det være utfordringer ved å bruke disse teknikkene hvis vi mangler nok eller riktige data. Product Risk Analysis Hvilken teknikk vi velger avhenger av hvor mye vi ønsker å kontrollere risikoen og hvor mye ressurser vi ønsker å bruke på dem. I Sogeti bruker vi Product Risk Analysis, som er en egenutviklet metode for

6 risikoanalyse som hjelper oss frem til slike vurderinger. Ønsket er å kunne prioritere det som har størst risiko. Etter å ha identifisert risiko items ut fra test goals og evaluert dem, er det et eget steg som vektlegger å begrunne risikoklassen som vi kommer frem til. Her er det viktig med en konsensus i prosjektet og med interessenter å komme frem til en liste. Denne listen blir i neste omgang utgangspunktet for å kunne prioritere i testprosessen. Vi forsøker å kontrollere for at vi mangler informasjon om innovasjonen med å inkludere flest mulige interessenter i vurderingen av risikoklasse og prioriteringen. Risikoanalysens betydning: testplan og omfang I risikobasert testing vil naturligvis risikoanalysen få en stor rolle for hele testprosessen. Risikoanalysen blir ofte utgangspunktet for master test plan, og dermed også for hvordan de enkelte testnivåene, innrettes. Den vil legge føringer også for testomfang og testteknikker. Hvordan vi ser risikoen vil altså påvirke hele arbeidsprosessen videre. Vi kan gi et eksempel på hvordan risiko kan påvirke testnivåer. På Tomra er testobjektene er komplekse, med mange mindre subsystemer som skal integreres. I tillegg til de mer vanlige testnivåene som unit testing og systemtesting, må man også ta høyde for HW/SW/FW integrasjonstesting: for eksempel - avlesninger av flaskeinformasjon brukes til både sortering og dataadministrasjon. Markedstester gir verdifull informasjon om produktet i ulike kontekster hvor der er flere og mer spesifikke krav til hvordan maskinen skal se ut, yte og opptre. Det er gjennom risikoanalysen vi finner testomfanget og testdekningen som vi ønsker, det er den som gir oss risikoklasser i teststrategien vår. Vi har da nok allerede en ide om hvilke egenskaper av produktkvaliteten vi kommer til å vektlegge i testingen. I embedded testing finner vi ofte ikkefunksjonelle egenskaper som må vektlegges like mye som de funksjonelle. Pantemaskinene og noen av sorteringsløsningene utviklet av Tomra testes i klimarom for å se om temperaturer og fuktighet påvirker funksjonaliteten. Siden maskinen fysisk vil stå på steder som utsetter den for lys, temperatur og muligens støt må man sjekke at hardware og software tåler slike påkjenninger. Stadig utvikling Ideelt bør risikoanalysen gjøres så tidlig som mulig, og bør jo være med i master test plan eller for eksempel i 0-sprinten hvis man bruker SCRUM. Ved innovasjon kan det dukke opp risiko underveis, av grunner som vi allerede har nevnt, som må håndteres. Vi må med andre ord holde risikoanalysen vår oppdatert. Det er viktig å huske at denne risikoanalysen må tilpasses funn, endringer og nye krav som kommer underveis i prosjektet.

7 Dette har som kjent ikke bare betydning for produktkvalitet, men også store konsekvenser for estimering og prosjektstyring altså prosjektrisiko. I prosjektet på Tomra ble prioriteringen av testingen gjort fortløpende ut fra en vurdering av ny funksjonalitet, viktigheten av eksisterende feil og behovet for regresjonstesting. Ved et par anledninger på Tomra ble det umulig å kjøre tester som tidligere var prioriterte ut fra risiko, blant annet fordi hardware ikke var klar til å testes på. Kjenn ditt testobjekt Testobjektet og testmiljøet må få en stor rolle siden det er stadig i endring. Det er her historikken til innovasjonen og produktet ligger og hjelper oss til å forstå hvilken tilstand testobjektet er i til enhver tid. Vi må vite hvilken tilstand testobjektet er i og hva det vil bety å teste på det. Dette handler mye om forventninger. Testeren må tørre å tenke nytt og være fleksibel for å ta innover seg endringene. Lag en logg over utviklingen. Alt dette er viktig skal vi gjenskape et testresultat, og ikke minst til at vi kan stole på at testresultatet er riktig.

8 Bruk av historikk for å finne nye risiki La oss se mer på oppfinnelsen av hjulet. Vi kan late som om vi har tilgang til informasjonen som prosjektet som utviklet hjulet hadde tilgang på. Historikk kan bli en viktig kilde. Selv om innovasjonen kommer som lyn fra klar himmel, kan det hende at noen vet mye om dette lynet allerede om enn fra en indirekte vinkel. Akkurat som man før det runde hjulet hadde firkantede hjul. En kilde til risikoidentifisering og analyse kan være å se på hvor feilene var i tidligere produkter og kanskje er det skrevet noe om andres utfordringer i utviklingen av sine? Bruk tilgjengelig historikk. I mange bransjer må man også huske at man fortsatt selger firkantede hjul, slik at man må vite hvilke virkninger det nye systemet kan få for det gamle. Kan sykkelrammene tåle både firkantede og runde hjul? Vi kan gi noen eksempler på hvordan det nye produktet må tilpasse seg, og kanskje krever tilpasninger på andre systemer. På Tomra skulle den nye T9-maskinen kunne benytte seg av etablert software og design for brukerkommunikasjon. Den skulle kunne integreres med tidligere sorterings- og oppbevaringsløsninger, såkalte bakrom, som opprinnelig var utviklet ut fra andre tidligere modeller. Likeså skulle T9 også støtte en rekke SW applikasjoner og backofficesystemer, blant annet for dataadministrasjon, som allerede var etablerte ute hos kundene. Test av den nye løsningen

9 Underveis har vi testet mye på tilgjengelig funksjonalitet og en del ikke-funksjonelle egenskaper, og dermed testet mye av innovasjonen. Vi har da løpende prioritert testingen ut fra krav som dukket opp underveis i tillegg til de satt i system test planen. Så vi har testet deler av det nye gjennom nye tester. Men kan vi være sikre på at vi har testet alt som vi skulle? For å svare på det, kan vi kanskje se tilbake. Kan vi teste dette nye vi har laget med de tidligere testene? Regresjonstestingen fra tidligere prosjekter kan gi nyttig informasjon men dekker den alt? Vi hadde en test for å sykle opp en trapp med firkantede hjul, vil denne testen være aktuell for en sykkel med runde hjul? Både for tester utviklet ut fra tidligere tester eller helt nye tester, er det viktig med fleksibilitet og omstillingsemne i testteamet, og god kommunikasjon i prosjektet. Så kort sagt, hvordan skal vi testere håndtere risiko ved innovasjon? Endringer kan bety at det er kommet inn en feil Kjenn testobjektet: Lag en logg Bruk all tilgjengelig historikk Test både nye og gamle egenskaper Test må inn tidlig. Vi skal ta de bugsene tidlig. Eller for å omskrive et kjent engelsk ordtak: the early worm is caught by the bird.