{"id":42,"date":"2026-10-05T02:21:40","date_gmt":"2026-10-05T00:21:40","guid":{"rendered":"https:\/\/larsjnordberg.no\/wordpress\/tekniske-funn-fra-pastand-til-verifikasjon\/"},"modified":"2026-10-05T02:41:59","modified_gmt":"2026-10-05T00:41:59","slug":"tekniske-funn-fra-pastand-til-verifikasjon","status":"publish","type":"post","link":"https:\/\/www.ai-desk.for.document.plugin-demo.av.larsjnordberg.no\/tekniske-funn-fra-pastand-til-verifikasjon\/","title":{"rendered":"Slik dokumenterer dere et teknisk funn"},"content":{"rendered":"

En god feilrapport gj\u00f8r problemet mulig \u00e5 gjenskape og rettingen mulig \u00e5 kontrollere. Oppgi filversjon, teststeg, konsekvens og hva som skal v\u00e6re oppfylt n\u00e5r funnet lukkes.<\/strong><\/p>\n

N\u00e5r en integrasjon stopper, trenger utvikleren et presist utgangspunkt. Hvilken bruker var innlogget? Hvilken side ble \u00e5pnet? Hva forventet testeren \u00e5 se? Svarene gj\u00f8r det mulig \u00e5 f\u00f8lge hendelsen gjennom systemene og finne hvor den avviker fra forventet oppf\u00f8rsel.<\/p>\n

Identifiser filen som er testet<\/h2>\n

Oppgi pluginens navn, versjon og filnavn. Ta med SHA-256 n\u00e5r gjennomgangen gjelder en ZIP-fil. Dette fingeravtrykket gj\u00f8r det mulig \u00e5 kontrollere at testeren og utvikleren arbeider med identisk filinnhold. Det er s\u00e6rlig nyttig dersom en pakke er endret underveis i gjennomgangen.<\/p>\n

I dette oppsettet er innloggingsbroen AI Desk Bridge 1.0.6. Opplysningene under identifiserer ZIP-filen som ble brukt i demoen. Vurderingen av kodens sikkerhet krever en egen gjennomgang av denne filen.<\/p>\n

Beskriv stegene frem til feilen<\/h2>\n

En brukbar rapport kan begynne slik: Logg inn i WordPress. Velg AI Desk i menyen. Vent p\u00e5 arbeidslisten. Noter deretter at skjermen blir st\u00e5ende p\u00e5 \u00abAvklarer tilgang\u00bb, og oppgi tidspunktet for fors\u00f8ket. N\u00e5 finnes det en konkret hendelse som kan sammenholdes med nettleserens nettverkssvar og relevante logger.<\/p>\n

Ta med forventet resultat og faktisk resultat i rapporten. Beskriv ogs\u00e5 konsekvensen for brukeren, for eksempel at artikkellisten er utilgjengelig. Da blir b\u00e5de funksjonen og betydningen av feilen tydelig.<\/p>\n

F\u00f8lg tilgangen gjennom systemene<\/h2>\n

I denne demoen lyktes innloggingen. Et senere kvoteoppslag ble avvist fordi demobrukeren manglet organisasjonsmedlemskap i AI Desk. Nettlesertesten gjorde det mulig \u00e5 avgrense feilen til dette oppslaget. Brukeren ble knyttet til en egen demoorganisasjon, og arbeidslisten kunne deretter \u00e5pnes.<\/p>\n

Hendelsen viser verdien av \u00e5 unders\u00f8ke hvert steg i rekkef\u00f8lge. Ved en ny tilgangsfeil m\u00e5 \u00e5rsaken fastsl\u00e5s ut fra svarene i det aktuelle fors\u00f8ket. Samme ventetekst kan kreve en annen retting.<\/p>\n

Avtal hvordan rettingen skal godkjennes<\/h2>\n

Et lukkekriterium beskriver resultatet testeren skal kunne se etter endringen. I dette tilfellet var kriteriet at nettleseren kom forbi tilgangssjekken og viste Direct med artikkellisten. Kontroll av hele dette forl\u00f8pet ga relevant dokumentasjon p\u00e5 rettingen.<\/p>\n

En etterpr\u00f8vbar rapport f\u00f8lger dermed en enkel kjede: gjenskap problemet, finn \u00e5rsaken, gjennomf\u00f8r rettingen og kontroller resultatet. Lagre utfallet sammen med versjonen som ble testet. Det gir begge parter et felles grunnlag for \u00e5 lukke funnet.<\/p>\n