Frosker, fjellkjeder og systemkonfigruasjon

Konfigurasjonskode?

Kodekonfigurasjon?

Systemparametre?

Parametersystem?

Kulturuke?

Kuruketul?

 

Vi testere blir ofte konfrontert med problemstillingen: “Dette er ikke en feil, det er jo bare konfigurasjon!”

Eller “Dette trenger vi ikke å teste, det er jo bare konfigurasjonsendringer”

Right! Vi testere har ofte meninger om det… Så hva er egentlig definisjonen på en konfigurasjonsendring og nøyaktig hvor går skillet mellom konfigurasjon og system?

Vår egen Richard Rostad har tanker og meninger om mangt, så også dette temaet!

En vanlig, teknokratisk definisjon er: “Alle endringer som ikke medfører at produktet må kompileres på nytt er en konfigurasjonsendring”

Da ender man fort opp med at et program skrevet i Python, som ikke skal kompileres, faktisk ikke er et program, men bare en lang rekke med konfigurasjonsparametre. Det gir åpenbart ikke noen fornuftig mening, så vi trenger noe annet.

Hva om vi både ser på hva som er systemet, og hva som er en systemendring som fører til en feil? La oss prøve med: “En feil er en endring som gjør at brukeropplevelsen forringes” (eller den litt mildere “… som gjør at brukeren ikke får utført oppgavene”)

Den møter også på en del problemere ganske fort: Særlig innen spillverdenen er det en hel del produkter som undertegnede ikke kan bruke rett å slett på grunn av manglende reaksjonsevne og hånd/øyekoordinasjon; mye på samme måte som jeg neppe noen gang vil kunne balansere mange tallerkener på kosteskaft.

Er det en ‘feil’ eller bør vi bytte bruker? Hva med farger? Er fargevalget i systemet vårt en feil siden det ikke kan brukes av fargeblinde eller skal vi kun ha kvinnelige ansatte fordi kvinner har gjennomgående bedre fargesyn?

Gitt kjønnsfordelingen blant programmerere vekker i hvert fall det siste spørsmålet ofte noen tanker. Det viser seg fort at begrepene ‘feil’, ‘system’, ‘konfigurasjon’ etc. er direkte vanskelige å sette skikkelig fast. Fenomenet vi har kommet borti er kjent som ‘systems boundary problems’ og er grundig behandlet i Jerry Weinbergs bøker om emnet General Systems Thinking. La oss ta et eksempel fra hans “Introduction To General Systems Thinking” (Gerald M. Weinberg, første gang utgitt i 1975)

The Appalachians er en fjellkjede som går langs Amerikas østkyst, fra langt nede i sørstatene og et godt stykke opp i Canada. I denne fjellkjeden lever det frosker. Er det en eller flere arter av frosker? Definisjonen av en art er at individer av samme art kan pare seg og få fruktbart avkom. Alle froskene langs hele kjeden kan gjøre dette med frosker som lever innenfor en avstand som en frosk kan vandre i sin levetid. Fra froskenes synspunkt er det med andre ord åpenbart samme art. På den annen side er klimaet i sørenden av fjellkjeden nærmest subtropisk, mens i nordenden begynner vi å snakke arktisk klima.

En frosk fra en av endene vil ikke engang kunne overleve i den andre, langt mindre produsere fruktbart avkom. Sett ‘utenfra’ er frosker fra hver ende av fjellkjeden åpenbart forskjellige arter. Men hvor går skillet? Det er ikke noe skille mellom froskeartene i Appalachia, men hvis man beveger seg langt nok er det allikevel opptil flere arter.

Det er en nøtt: Froskene er ikke ‘en art’ eller ‘flere arter’ men et system som har diffuse grenser – på samme måte som IT-systemer har diffuse grenser, konfigurasjon / kode har diffuse grenser og til og med systemfeil / brukerfeil har diffuse grenser. Å bli enige om en entydig definisjon av et system med diffuse grenser er ikke mulig fordi definisjonen avhenger av kontekst.

Froskenes kontekst er en ganske annen enn konteksten til forskerne som finner glede i å frakte frosker over mange breddegrader. En brukers opplevelse av ‘systemet’ er ganske annerledes enn en arkitekt som jobber med sammenhengen mellom subsystemer og enda lenger unna en programmerer som jobber med deler av et av subsystemene. Derfor er det ganske meningsløst å snakke om hva som er konfigurasjon og hva som er produkt uten først å definere hvilken kontekst vi snakker om.

Ofte, når vi kommer til spørsmålene som vi testere må forholde oss til er denne konteksten kjent som ‘kontrakten’^*), hvor leverandør ønsker å definere mest mulig som konfigurasjon fordi rettinger da skjer for kundens regning, mens kunden ønsker å definere mest mulig av systemet som ‘kode’ fordi rettinger da faller på leverandør. Nye trender innen bransjen som ‘Infrastructure As Code’, ‘Security As Code’, etc. gjør ikke problemstillingen det grann enklere.

I brukerens kontekst er en ‘systemfeil’ noe som gjør at systemet ikke virker som jeg, som bruker, skulle ønske at det virket og som jeg med min kompetanseprofil ikke kan fikse selv. Hvorvidt feilen ligger i en konfigurasjonsfil, kompilert kode eller et bortgjemt kryss et eller annet sted i brukergrensesnittet er ganske uinteressant.

I maskinens kontekst er alt sammen, inklusive tastaturtrykk, musebevegelser eller taleinnput bare mange instanser av 0 eller 1 uansett.

Når det kommer til hvorvidt noe bør testes eller ikke så er vel et mer relevant spørsmål: “Kan en endring her føre til endret funksjonalitet eller forringet brukeropplevelse?” Hvis svaret er ja bør det testes uavhengig av om det er kode, konfigurasjon, dokumentasjon eller noe annet. Hvis det dukker opp et problem som fører til uønsket funksjonalitet eller forringet brukeropplevelse er jeg som tester mindre interessert i om det er en feil eller ikke og ganske mye mer interessert i om det blir fikset eller ikke.

Så får noen andre bekymre seg om hva som står i kontrakt og budsjett.

^*) Dette motsetningsforholdet er grunnen til at undertegnede mener statens standardavtaler for IT anskaffelser er den største katastrofen som har truffet norsk IT miljø; gode systemer kommer ikke som følge av jurister som krangler om kontraktselementer, men fra godt samarbeid mellom alle parter. Hele konseptet ‘leverandør’ og ‘kunde’ står til hinder for gode brukeropplevelser.