Dette er andre kapittel i en serie hvor vi skal snu og vende på etablerte sannheter i testverdenen.

Er domenekunnskap virkelig bare en sovepute?

Beklager – men testledelse skjer ikke i et vakuum.

I forrige artikkel stilte vi spørsmål ved hvorfor kunder så ofte krever domenekunnskap når de skal hente inn en testleder.

Argumentet var omtrent dette:

En dyktig testleder kan testfaget, forstår komplekse systemer, leder mennesker, leser kontrakter, håndterer risiko og ser helheten. Alt dette er kompetanse som kan tas med fra én bransje til en annen.

---

---

Så hvorfor skal det være så viktig om kandidaten har jobbet med retail, bank, kraft eller offentlig sektor før?

Det høres fornuftig ut.

Men det er én liten hake:

Du tester ikke et system. Du tester en virksomhet som tilfeldigvis bruker et system.

Og det er kanskje nettopp derfor domenekunnskap fortsatt står så høyt på kravlisten.

En feil er ikke bare en feil

For testlederen handler testing selvfølgelig om systemer, integrasjoner, dataflyt, testmiljøer, regresjon og kvalitet.

Men test handler først og fremst om risiko. Og for å forstå risiko må du forstå virksomheten.

En feil som ser alvorlig ut teknisk, kan være nærmest ubetydelig for brukerne. En annen feil kan se helt uskyldig ut i et testsystem, men få store konsekvenser i produksjon.

Hvordan skal testlederen vite forskjellen?

Det er her domenekunnskap begynner å bli mer enn bare «kjekt å ha».

Tenk deg at du leder test i et kraftselskap. Du kan være verdensmester på testmetodikk, men hvis du ikke forstår hvordan avregning, måleverdier, markedsprosesser og tidskritiske avhengigheter henger sammen, vet du heller ikke nødvendigvis hvor de største risikoene befinner seg.

Det samme gjelder innen bank, helse, forsikring, offentlig forvaltning eller logistikk.

Systemforståelse forteller deg hvordan løsningen henger sammen. Domeneforståelse forteller deg hva som faktisk betyr noe når den ikke gjør det.

«Men fagpersonene kan jo domenet»

Et naturlig motargument er at testlederen ikke trenger å være domeneeksperten. Det finnes jo fagpersoner i prosjektet.

Og det er riktig. Testlederen skal ikke erstatte forretningen.

Men det er stor forskjell på å hente informasjon fra domenet – og å forstå domenet godt nok til å utfordre det.

En testleder uten domenekunnskap kan spørre: «Hvilke scenarier bør vi teste?»

En testleder med domenekunnskap kan spørre: «Hva skjer hvis denne transaksjonen kommer etter fristen, samtidig som kunden bytter avtale og måleverdien korrigeres tilbake i tid?»

Det siste spørsmålet oppstår ikke nødvendigvis fordi noen har skrevet det i en kravspesifikasjon. Det oppstår fordi du har sett lignende situasjoner før.

Og det er ofte akkurat disse scenarioene som skiller en ordinær testprosess fra en virkelig god en.

Det som ikke står i kravene

I teorien skal kravene beskrive hva løsningen skal gjøre. I praksis vet alle som har jobbet i store IT-prosjekter at de aldri beskriver hele virkeligheten.

Det finnes unntak. Historikk. Manuelle rutiner. Gamle integrasjoner ingen helt vet hvorfor eksisterer. Regulatoriske hensyn. Prosesser som «bare fungerer sånn». Og ikke minst virksomhetskritisk kunnskap som sitter i hodet på noen få personer.

En erfaren testleder kjenner igjen denne typen utfordringer uansett bransje.

Men en erfaren testleder med relevant domenekunnskap kan ofte identifisere dem mye tidligere.

Det betyr kortere vei til de riktige spørsmålene. Og i et prosjekt hvor tid nesten alltid er mangelvare, har det verdi.

Oppstartstid er ikke bare onboarding

Det blir gjerne sagt at en god testleder raskt kan lære seg et nytt domene. Det stemmer.

Men «raskt» betyr ikke «umiddelbart».

Og spørsmålet er heller ikke bare hvor fort man lærer faguttrykkene. Det handler om hvor lang tid det tar før man forstår hvilke deler av virksomheten som er virkelig kritiske. Hvem man bør snakke med. Hvilke unntak som alltid dukker opp. Hvor det historisk har gått galt. Hvilke konsekvenser en tilsynelatende liten endring kan få. Og hva brukerne aldri kommer til å tilgi at man ødelegger.

Den kunnskapen får man ikke nødvendigvis etter et par workshops og noen timer med dokumentasjon.

Noen ganger er det nettopp erfaring fra domenet som gjør at testlederen kan være effektiv fra første uke.

Men SAP er vel SAP?

Et argument som ofte dukker opp, er at systemene i stor grad fungerer likt på tvers av bransjer.

En SAP-implementering er fortsatt en SAP-implementering. En integrasjon er fortsatt en integrasjon. Data flytter seg fortsatt fra system A til system B.

Det er selvfølgelig sant.

Men det er litt som å si at kirurgi er kirurgi fordi alle operasjoner foregår på et sykehus.

Teknologien kan være den samme. Metoden kan være den samme. Men konteksten avgjør hva som er farlig.

I én virksomhet kan en feil i masterdata føre til feil vare på et lager. I en annen kan tilsvarende datakvalitetsfeil påvirke fakturering, myndighetsrapportering eller tjenester tusenvis av mennesker er avhengige av.

Den tekniske mekanismen kan ligne. Risikoen gjør det ikke.

Domenekunnskap handler også om språk

Det finnes enda en side ved dette som ofte undervurderes. Prosjekter består av mennesker.

En testleder skal samarbeide med utviklere, arkitekter, produkteiere, leverandører, sluttbrukere og fagpersoner. Og fagmiljøer har sitt eget språk.

Når testlederen forstår begrepene, prosessene og problemstillingene fra før, skjer noe viktig: Samtalene går raskere. Misforståelser blir færre. Og tilliten kommer ofte tidligere.

Det betyr ikke at en testleder uten domenekunnskap ikke kan bygge den tilliten. Selvfølgelig kan de det.

Men erfaring gjør terskelen lavere. Og i krevende prosjekter kan det være viktig.

Erfaring kan ikke alltid erstattes av nysgjerrighet

Det er lett å si at den beste testlederen er den som stiller de riktige spørsmålene – uansett bransje.

Og nysgjerrighet er helt avgjørende. Men gode spørsmål oppstår ikke bare av metode. De oppstår også av erfaring.

Den som har jobbet lenge i et domene vet ofte hvor de skjulte avhengighetene ligger, hvilke antakelser som bør utfordres og hvilke «umulige» hendelser som faktisk har skjedd før.

Det betyr ikke at ti år i samme bransje automatisk gjør noen til en god testleder. Lang domenefartstid kan aldri kompensere for svak testfaglig kompetanse.

Men motsatsen er også sann: Testmetodikk alene kan ikke alltid kompensere for manglende forståelse av virksomheten.

Så bør domenekunnskap være et absolutt krav?

Ikke nødvendigvis.

Det finnes selvsagt prosjekter der en svært sterk testleder uten bransjeerfaring er et langt bedre valg enn en svakere kandidat som tilfeldigvis kjenner domenet.

Og kravspesifikasjoner som krever «ti års erfaring fra akkurat vår nisje» kan gjøre kandidatmarkedet unødvendig lite.

Men det betyr ikke at selve ønsket om domenekunnskap er feil. Kanskje problemet heller er at vi er for dårlige til å beskrive hvilken domenekunnskap vi faktisk trenger.

Trenger kandidaten å kjenne hele bransjen? Et bestemt regelverk? Kritiske forretningsprosesser? En bestemt plattform? Eller holder det med erfaring fra tilsvarende komplekse og regulerte miljøer?

Det er en mer interessant diskusjon enn «domene eller ikke domene».

Kanskje kunden har et poeng likevel

Fra konsulentsiden kan et domenekrav oppleves frustrerende. Vi ser en sterk kandidat som vi vet kan gjøre jobben, mens kunden ser en CV uten det riktige bransjeordet.

Men kunden bærer også risikoen dersom leveransen går galt.

Da er det ikke så merkelig at de verdsetter en testleder som allerede forstår virksomheten, språket og konsekvensene av feil.

Spørsmålet er kanskje ikke om domenekunnskap er en sovepute.

Spørsmålet er om vi har blitt gode nok til å skille mellom relevant domenekompetanse og unødvendig smale CV-krav.

Så – hvem har egentlig rett?

I den første artikkelen argumenterte vi for at testfaglig tyngde, systemforståelse og lederegenskaper bør veie tyngre enn bransje-DNA.

Her har vi argumentert for det motsatte: At testledelse ikke skjer i et vakuum, og at forståelsen av virksomheten kan være avgjørende for å identifisere den reelle risikoen.

Sannsynligvis finnes det ingen fasit som gjelder alle prosjekter.

Men vi er nysgjerrige på hvor dere trekker grensen.

Hva ville du valgt: En svært erfaren testleder uten domenebakgrunn – eller en testleder med solid domenekunnskap, men kortere erfaring fra selve testlederrollen?

Og i hvilke prosjekter mener du domenekunnskap faktisk bør være et absolutt krav?