> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/module-overview/controls/control-advanced-effectiveness-testing.md).
# Kontroll Avansert Effektivitetstesting
{% hint style="info" %}
**Videoopplæring**
Foretrekker du å se i stedet for å lese? Ta en titt på vår [Videoveiledninger](/cerrix-documentation-no/beste-praksiser-og-guider/video-tutorials.md#control-advanced-effectiveness-testing) Videoveiledninger
{% endhint %}
Kontroll Effektivitetstesting sikrer at kontroller fungerer som tiltenkt for å redusere risikoer. Denne prosessen omfatter flere trinn for å validere design og operasjonell effektivitet.
Når du genererer utvalg i denne Workflowen, bruker CERRIX [Randomizer](/cerrix-documentation-no/cerrix-funksjoner/module-overview/controls/control-advanced-effectiveness-testing/randomizer.md) til å avgjøre hvilke elementer som velges fra den definerte populasjonen.
Dette støtter en konsekvent og reviderbar måte å velge utvalg på under effektivitetstesting av kontroller.
### Opprette en Testplan
Før test-Workflowen nedenfor kan starte, må en testperiode og en testplan opprettes på kontrollen. Åpne kontrollen fra **Kontroller Workspace** og gå til fanen **Effektivitetstesting** , der du finner en oversikt over alle testplaner og testperioder for denne kontrollen.
#### Sette opp testperioder
Klikk **Administrer testperioder** for å definere tidsrammen for testing:
1. Angi perioden (f.eks. Q1 2026 eller FY 2026)
2. Angi antall utvalg som skal testes
3. Klikk **lagre**
Det finnes ikke noe fastsatt format for testperioder. Om du definerer et helt år, halve år eller kvartaler, avhenger av organisasjonens egne testpraksiser — særlig hvor ofte du tester kontrollene dine. Velg en navnekonvensjon som samsvarer med testfrekvensen din, og bruk den konsekvent.
#### Legge til en Testplan
Klikk **Legg til testplan** og fullfør følgende:
* **Rolletildeling** — testeren (utfører utvalget og evalueringen), bevisopplasteren (leverer støttedokumentasjon) og Reviewer (validerer testkonklusjoner). Merk at **opplaster av kildedokument** kan bare tildeles etter at bevisopplasteren og testeren er fylt inn — hvis feltet for opplaster av kildedokument ikke godtar et navn, fyll ut disse to feltene først.
* **Definisjon av omfang** — hvilke kontrollutførelser som skal testes, hvilken dokumentasjon som kreves, og hva som utgjør effektiv drift.
* **Instruksjoner** — tydelig veiledning om hva som skal testes, forventede dokumentasjonstyper og evalueringskriterier.
Klikk **lagre** for å fullføre testplanen. Workflow-oppgaver genereres automatisk og plasseres i kalenderne til alle involverte parter, slik at alle kjenner sine ansvarsområder og frister.
#### Kopiere en Testplan til en ny Periode
Når du bruker **Kopier fra eksisterende testplan**, gjenbrukes alt fra kildeplanen, inkludert de tildelte brukerne (tester, bevisopplaster, Reviewer). Bare forfallsdatoene overføres ikke — disse angir du for den nye perioden.
Dette gjør kopiering til den anbefalte måten å overføre testplanene dine til et nytt år på:
1. Oppdater først de gjeldende (ennå ikke utførte) testplanene — for eksempel ved å legge til en ekstra bevisopplaster.
2. Bruk **Kopier fra eksisterende testplan** for å opprette planene for den nye perioden. De oppdaterte rolletildelingene overføres automatisk.
3. Angi de nye forfallsdatoene.
{% hint style="info" %}
Hvis du må opprette eller endre et stort antall testplaner samtidig — for eksempel endre tildelte roller på tvers av et helt år med planer — kan import av testplaner være mer effektivt. Se siden [Importmaler](/cerrix-documentation-no/beste-praksiser-og-guider/import-templates.md) eller kontakt CERRIX-støtte via servicedesk.
{% endhint %}
### Trinn for Effektivitetstesting
#### Trinn 1: Opplaster av kildedokument
1. Naviger til testplanen i **Kontroll** -modulen.
2. Klikk **Last opp kildedokument**.
3. Dra og slipp filer, eller bla gjennom for å laste opp relevante dokumenter.
4. Du kan eventuelt legge til en beskrivelse for den opplastede filen.
#### Trinn 2: Generere utvalg
* Velg en utvalgsmetode:
* **Etter antall**: Generer utvalg basert på et forhåndsdefinert antall.
* **Etter dato**: Bruk et datointervall for å generere utvalg.
* **Etter regneark**: Last opp et regneark og konfigurer generering av utvalg fra unike ID-er i filen.
I alle tre tilfeller bruker CERRIX den samme randomizer-logikken for å velge utvalg. Valgte elementer velges ikke to ganger innenfor det samme utvalgssettet. Se [Randomizer](/cerrix-documentation-no/cerrix-funksjoner/module-overview/controls/control-advanced-effectiveness-testing/randomizer.md) for tekniske detaljer.
#### Trinn 3: Laste opp dokumentasjon
* Last opp dokumentasjon for hvert utvalg.
* Marker utvalg uten dokumentasjon, og oppgi en årsak i kommentarene.
#### Trinn 4: Testing
* Vurder hvert utvalg og dokumenter funn.
* Oppgi poengsummer og kommentarer for hvert testtrinn.
#### Trinn 5: Reviewer-trinn
* Reviewer vurderer resultatene, gir tilbakemelding og bekrefter det endelige utfallet.
> **Beste praksis**: Sørg for at alle nødvendige dokumenter er lastet opp før du går videre til neste trinn.
### Redigere en Testplan
En testplan kan redigeres etter at den er opprettet via blyantikonet i oversikten over testplaner, med noen begrensninger som beskytter utførte tester:
* Mens en testplan har statusen **Last opp kildedokumenter for å starte Workflow**, kan alt i testplanen fortsatt endres.
* Når en testplan har startet, kan brukerne som er tildelt testplanen fortsatt endres, så lenge den brukerens trinn ennå ikke er fullført og brukeren ennå ikke har deltatt ved å laste opp dokumenter eller legge til data.
* Oppretteren av testplanen kan også endre **forfallsdato** for hver fase som ennå ikke er fullført: forfallsdatoen for Last opp dokumentasjon mens dokumentasjon lastes opp, forfallsdatoen for Testing under testing og forfallsdatoen for Reviewer under gjennomgangen. Forfallsdatoer kan også justeres etter et avslag. Den vanlige valideringen gjelder fortsatt, for eksempel kan forfallsdatoen for Reviewer ikke settes før forfallsdatoen for testeren.
* Alle andre egenskaper kan ikke lenger endres når testplanen har startet, slik at testplaner som utføres, ikke kan endres.
### Øyeblikksbilde av Kontrollbeskrivelse
Når en testplan lukkes, oppretter CERRIX automatisk et øyeblikksbilde av kontrollbeskrivelsen slik den var på det tidspunktet.
Dette øyeblikksbildet sikrer at den historiske konteksten til kontrollen bevares, selv om kontrollbeskrivelsen oppdateres senere. Når du åpner en avansert effektivitetstestplan for en Kontroll etter at den er lukket, vises dette øyeblikksbildet i stedet for den gjeldende kontrollbeskrivelsen.
Datoen som vises ved siden av kontrollbeskrivelsen, angir når øyeblikksbildet ble tatt.
### E-postvarsler og påminnelser
CERRIX holder alle involverte i effektivitetstesting informert via e-post gjennom hele Workflowen, slik at bevisopplastere, testere og Reviewere alltid vet når det er deres tur.
#### Innebygde varsler
Følgende varsler er en del av standard Workflow for testing:
* Den **bevisopplaster** mottar en e-post når en testplan opprettes, og igjen når testeren konkluderer med at dokumentasjon mangler.
* Den **bevisopplaster, tester og Reviewer** mottar hver sin oppgavetildeling og påminnelses-e-poster knyttet til forfallsdatoen for sin egen fase (Last opp dokumentasjon, Testing, Gjennomgang). Testere mottar for eksempel en påminnelse én dag før forfallsdatoen.
Oppretteren av testplanen kan redigere forfallsdatoene for hver fase så lenge fasen ennå ikke er fullført.
#### Egendefinerte varsler
Administratorer kan legge til sine egne varsler i tillegg til de innebygde — for eksempel en e-post til bevisopplasteren på selve forfallsdatoen. For hvert egendefinerte varsel konfigurerer du:
* Den **e-posttekst**
* Den **tidspunkt** (for eksempel én dag før, eller på, forfallsdatoen)
* Den **organisasjon** varselet gjelder for
* Eventuelt, **spesifikke mottakere**
{% hint style="info" %}
La mottakerfeltet stå tomt for å la CERRIX automatisk sende e-post til alle angitte bevisopplastere. Hvis du velger spesifikke brukere, sendes varselet bare til disse brukerne.
{% endhint %}
#### Planleggingstips
For å få mest mulig ut av varsler om forfallsdatoer:
* **Opprett testplaner før varslingsvinduet åpnes.** Varsler ser fremover fra tidspunktet planen eksisterer og brukes ikke med tilbakevirkende kraft — en plan som opprettes innenfor varslingsvinduet (for eksempel mindre enn én uke før forfallsdatoen ved bruk av en påminnelse én uke i forveien), vil ikke utløse den påminnelsen. Å legge til et ekstra varsel én dag før eller på forfallsdatoen bidrar til å dekke planer som opprettes nær fristen.
* **Varsler sendes under en kontroll tidlig om morgenen**, slik at en plan som opprettes senere samme dag, fanges opp fra neste morgen.
* **Påminnelser gjelder den gjeldende fasen.** Når en testplan har gått videre til et senere trinn (for eksempel Klar for Vurdering), sendes ikke lenger påminnelser for den tidligere fasen.
## Roller, rettigheter og tillatelser for Kontroll Effektivitetstesting
Du finner en oversikt over de ulike rollene, rettighetene og tillatelsene for kontroller i denne praktiske oversikten:
[Roller, rettigheter og tillatelser](/cerrix-documentation-no/cerrix-funksjoner/roles-rights-and-permissions.md#controls-permission-matrix)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/module-overview/controls/control-advanced-effectiveness-testing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
