Skal skrive lærebok i livsviktig nerding

I eit samfunn som er så gjennomdigitalisert som det norske, skulle ein kanskje tru at vi veit alt om utvikling og testing av programvare. Vellukka digitalisering er jo heilt avhengig av at programvaren er nyttig og fungerer slik han skal.

Likevel finst det ikkje ei einaste norskspråkleg lærebok i testing av programvare for programutviklarar. Den boka er det årets vinnarar av Universitetsforlagets pris for beste lærebokidé, Harald H. Soleng og Eva Hadler Vihovde, som skal skrive.

Første bok på norsk

– Den gongen eg arbeidde ved Norsk Regnesentral, vidareutvikla eg mykje gammal programvare som var full av feil. Då fekk eg ein idé om at det trongst ei bok om testing, fortel Soleng.

Han er utdanna fysikar og har arbeidd med programvareutvikling i mange år, i dag som prosjektingeniør ved Kongsberg Defence & Aerospace. Bokideen har han altså brygga på lenge.

Soleng forsto at det kunne vere lurt å finne ein medforfattar med undervisingserfaring, slik at boka kunne tilpassast lærebokmarknaden.

– Og der kom eg inn, seier Vihovde.

Ho har undervist studentar i programmering i mange år, og dei seinaste åra i programvaretesting. Det har ho gjort ved hjelp av engelske lærebøker.

– Men dei bøkene er meir mynta på personar som ikkje utviklar programvaren sjølv, men berre testar han. Uavhengig testing er sjølvsagt viktig, men med min bakgrunn som programmerar, seg eg jo at mange feil kunne ha vore unngått i utviklingsfasen, seier ho.

Når eit komma blir fatalt

Feil i programvare kan vere alt frå irriterande til livstrugande. Soleng har samla ei rekkje døme på kritiske programvarefeil frå sitt eige felt gjennom åra, og boka opnar med nokre av dei. Til dømes unngjekk ein berre såvidt eit raketthavari tidleg i det amerikanske romprogrammet, då nokon oppdaga at det som skulle ha vore eit komma i ei linje med programkode, i staden var eit punktum.

Feilen var nesten usynleg, men ville ha ført til ei fatal feillesing av programkoden dersom den ikkje var blitt oppdaga og retta.

– Eit anna døme er den gongen målposisjonen for eit missilsystem var innretta slik at dersom du ikkje sette inn ein verdi, vart målet automatisk sett til origo, nullpunktet i eit koordinatsystem. Men posisjonen til den som skulle skyte, var også sett til origo. Så dersom du gløymde å sette inn rett målposisjon, ville du ende med å skyte deg sjølv. Heldigvis vart feilen oppdaga før programvaren kom i bruk, seier Soleng.

Litt av problemet er, som han seier, at det er så mange fleire måtar å gjere noko feil på, enn å gjere det rett.

– Ofte dukkar feila opp fordi ein ikkje heilt har oversikt over kva problem ein eigentleg prøver å løyse, seier han.

Tenk igjennom problemet

Det kan gjerne starte med at oppdragsgjevaren ikkje gjev ei god nok skildring av kva som skal gjerast, og så forplantar det seg vidare til programvareutviklarane.

– Mykje kan gå gale på den vegen. Men dersom ein først har ei god problemforståing, så finst det teoriar for korleis ein kan utvikle sjølve programvaren og teste han systematisk, seier Vihovde.

Difor løner det seg oftast å leggje litt ekstra tid og innsats ned i den tidlege planlegginga. Men det skjer ikkje alltid. Mykje programvare er utvikla av nokon som berre trengte å løyse eit problem der og då, utan at dei nødvendigvis tenkte på kva for heilskap programmet skulle inngå i.

– Ofte er det mange ulike personar involvert, med ulike fagbakgrunnar og vokabular. Difor er det viktig å dokumentere koden slik at dei som kjem etter deg, forstår kva du har meint, seier Soleng.

Starta hos næringslivet

Medan programmering allereie har lange akademiske tradisjonar, så er testing framleis eit ganske nytt fag, fortel dei to.

– Vi som underviser og forskar i programmering, er jo ikkje med når ting går gale. Det er næringslivet som tek støyten når det skjer, så difor er det krefter frå næringslivet som har tvunge fram testingsfaget, seier Vihovde.

Det finst ein internasjonal organisasjon som utdannar og sertifiserer uavhengige programvaretestarar. Men Soleng og Vihovde vil at læreboka skal fange opp det som skjer i programutviklingsfasen, der dei verkeleg store blemmene kan forhindrast. Kor enkelt det er å teste eit program, heng mellom anna i hop med korleis koden er skriven.

– Det eksisterer mange konvensjonar innan programmering, som ikkje er der for at maskina skal forstå programmet, men for at andre menneske skal forstå det. Og det finst dataprogram som kan kvalitetssjekke koden du skriv og passe på at desse konvensjonane er følgt, seier Vihovde.

Som undervisar opplever ho ofte at studentar kjem langt ut i ei programmeringsoppgåve før dei oppdagar at det dei har gjort, ikkje heng saman og dei må starte heilt på nytt.

Betre føre var

– Og dette gjeld jo alle store prosjekt, at dei må gjerast grundig frå starten. Det finst mange døme på at ting rundt oss går gale fordi ein ikkje planlegg godt nok, eller fordi prosjektet går ut på dato slik at når det er ferdig utvikla og installert, så er det ikkje behov for det lenger, seier ho.

– Det er også ein del av testinga: Å spørje seg om dette produktet trengst.

Ein viktig grunn til å leggje større vekt på å førebygge feil, minner ho om, er at dess lenger utviklingsprosessen er komen, dess dyrare vil det vere å rette feilen – og dess større er risikoen for å introdusere nye feil i prosessen.

– Sjølv om grundig arbeid i starten kanskje tek litt ekstra tid, er det veldig kostandseffektivt å førebygge, samanlikna med kor dyrt det er å reparere.