Who Tests the Machines That Build the Machines?

As we begin to form virtual engineering teams — teams of specialized agents that plan, code, review, test and deploy — the very nature of software creation is changing. But when machines collaborate with other machines, who ensures that quality, safety, and intent are preserved?

In this provocative session, we explore how Quality Assurance must evolve to meet the era of AI-engineered applications. Drawing on experiences from IT-HUSET, we’ll demonstrate how AI-driven QA frameworks can act as a wrapper around these virtual agent teams, automatically testing, verifying, and aligning their output with human-defined goals — all with AI as the enabler.

Yet, amid the automation, human testers remain essential. They bring judgment, context, and ethical oversight — the “human-in-the-loop” ensuring that our intelligent systems don’t just work, but work as intended.

Join us to rethink what quality means when your “team” isn’t entirely human. You’ll leave inspired — and perhaps slightly unsettled — about how we build trust in an era where AI engineers alongside us.

Hvordan gjør vi KI til en produktiv kollega i stedet for en snubleblokk? Med nye KI-verktøy får vi muligheten til å produsere mer kode og flere tester enn noen gang. Hvordan unngår vi at vi produserer store mengder søppel? Jeg kommer med konkrete tips for å integrere KI i teamet: vaner og rutiner for bruk av KI som øker kvaliteten på arbeidet og bidrar til bedre samspill mellom utviklere, testere og forretning. Dere får tips om vanlige fallgruver og enkle tiltak dere kan innføre for å sikre kvalitet.

Etter flere års erfaring i IT-bransjen vet vi at ikke alle eventyr ender med “…og de levde lykkelig alle sine dager”. Noen ganger er prinsen blitt ond, dragen har tatt prosjektlederen, og kartet over kravene er tegnet med usynlig blekk.

I dette foredraget deler vi tre ulike deler av test- og utviklingsverdens historier, erfaringer og praktiske råd fra prosjekter der:

samarbeidet ikke eksisterte 

kravene var uklare eller helt fraværende,

ledelsen ikke ledet,

og du kanskje til og med ikke var ønsket med på laget.

Hvordan sikrer man kvalitet i et prosjekt der rammene er alt annet enn ideelle? Hvordan kan man fortsatt bidra, bevare faglig stolthet, ikke gå på veggen og kanskje til og med snu stemningen?

Gjennom ekte erfaringer, litt selvironi og konkrete tips viser vi hvordan du kan håndtere krevende situasjoner, bygge tillit og finne læring i kaoset. For som Yoda ville ha sagt det: The greatest teacher, failure is..

Hvordan kan vi bygge kvalitet inn i hele verdikjeden, fra kode til leveranse? For å besvare dette må vi definere kvalitet og hva det betyr for oss som jobber med test. Spør vi Rovo (Atlassian AI), får vi dette kjedelige svaret: “Kvalitet i testledelse er evnen til å sikre at hele verdikjeden – fra idé til produksjon – leverer verdi, trygghet og brukeropplevelse gjennom gode prosesser, samarbeid, kontinuerlig forbedring og riktig bruk av teknologi.”

Selv om definisjonen sikkert er riktig, er den veldig lite konkret. Datakvalitet nevnes ikke av Rovo. AI definisjonen på verdikjeden er heller ikke feil “Kvalitet må bygges inn i alle steg, ikke bare testes inn til slutt.” Systemene vi tester og innfører består ikke bare av funksjoner og prosesser. Hvorfor er vi ikke mer opptatt av kvaliteten på test-data?

Jeg mener at strategisk og tilstrekkelig fokus på hvordan vi identifiserer, utvikler og forvalter test-data er undervurdert.

Jeg skal dele erfaringer og løsninger rundt det jeg mener blir en stadig viktigere kvalitetskomponent i denne verdikjeden, nemlig ulike typer av data vi har behov for å forstå, og ha et forhold til i testprosessen. Behovet for god nok, og relevant datakvalitet er ikke noe nytt. Det påvirker kvaliteten til test av alle systemer og prosesser. Ofte bruker vi “workarounds” når dårlige eller manglende test-data påvirker systemet vi er med å utvikle og teste. Dette betyr enten at vi får feil testresultater eller manglende testdekning.

For mange IKT systemer vil ikke manglende datakvalitet være et alternativ. Det er binært, enten er data vi bruker i test riktig eller feil.

Så hva er riktig og god nok kvalitet på data vi bruker i test, og hvordan håndterer vi utfordringene med test-data? Jeg har valgt ut noen interessante metoder og teknikker jeg har benyttet for å bygge kvalitet inn i verdikjeden gjennom kvalitet på test-data.

Hos IMDi var kvaliteten på persondata avgjørende for å teste regelendringer for ulike typer innvandrere og flyktninger. Kun små feil i test-data, som i vedtakshistorikk, alder og adresser gjorde testene ubrukelige. Jeg forteller om hvordan vi brukte tverrfaglige team for utvikling av noen få syntetiske person arketyper og hvordan vi brukte disse til å utvikle kraftige datadrevne automatiserte tester og vedlikehold av disse.

Jeg beskriver også en metode for å verifisere at ulike datakilder som brukes i moderne signalsystemer for tog gir riktig forventede resultater. Metoden brukes til å bygge regresjons tester som fanger opp feil som forårsakes av endringer i infrastruktur data og ruteplaner. For å sikre at vi hadde de riktige testene brukte vi visualisering av data for alle fagmiljøer og systemeiere som direkte eller indirekte vil påvirkes av endringer.