> 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-nl/cerrix-functionaliteiten/module-overview/controls/control-advanced-effectiveness-testing/test-plan-statuses-scores-and-reporting.md).

# Testplanstatussen, scores en rapportage

## Testplanstatussen, scores en rapportage

Deze pagina legt uit hoe de status van een geavanceerd testplan voor effectiviteitstoetsing zich ontwikkelt (en na een afwijzing teruggaat), waar de resulterende testscores op de Beheersmaatregel verschijnen, en hoe je de testvoortgang over al je Beheersmaatregelen kunt bekijken en rapporteren. Zie voor de stapsgewijze instructies per Workflow-stap [Beheersmaatregel Advanced Effectiviteitstoetsing](/cerrix-documentation-nl/cerrix-functionaliteiten/module-overview/controls/control-advanced-effectiveness-testing.md).

### Testplanstatusverloop

Elk testplan in het Testplanoverzicht van een Beheersmaatregel toont een status die aangeeft in welke Workflow-stap het plan zich bevindt en dus wie er als volgende moet handelen. Een testplan doorloopt de volgende fasen:

| Status                                         | Wat het betekent                                                                                                    | Wat het plan vooruitbrengt                                                                          |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Brondocumenten uploaden om Workflow te starten | Het testplan is aangemaakt, maar er zijn nog geen brondocumenten geüpload.                                          | De uploader van brondocumenten uploadt de brondocumenten; daarna kunnen samples worden gegenereerd. |
| Wachten op bewijs                              | Samples zijn gegenereerd en het plan wacht erop dat per sample bewijs wordt geüpload.                               | De uploader van bewijs uploadt het gevraagde bewijs voor de samples.                                |
| Controletoetsing                               | Het bewijs is aanwezig en de tester kan de teststappen uitvoeren en de samples scoren.                              | De tester voltooit en slaat alle teststappen en scores op.                                          |
| Klaar voor Assessment                          | De tester heeft het testen afgerond en het resultaat wacht op de finale Assessment van de Reviewer.                 | De Reviewer accepteert de uiteindelijke conclusie-score.                                            |
| Voltooid                                       | De Reviewer heeft de uiteindelijke conclusie geaccepteerd. Het testplan is gesloten en het resultaat is definitief. | —                                                                                                   |

<figure><img src="https://2540748892-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-8919d77840a0e4abe73c0e1a485492adb500959e%2Fcontrols-test-plan-statuses.png?alt=media" alt="A control&#x27;s Test plans tab with statuses, samples, source documents and scores per period"><figcaption></figcaption></figure>

{% hint style="info" %}
Een testplan wordt alleen gemarkeerd **Voltooid** wanneer de Reviewer de uiteindelijke conclusie-score accepteert. Zolang de beoordelingsstap niet is geaccepteerd, is het plan niet voltooid en blijven Beheersmaatregel-velden die afhankelijk zijn van een voltooid testplan (zoals **Testdatum (effectiviteit)** en **Effectiviteitsscore**) leeg.
{% endhint %}

#### Beheersmaatregel heeft niet plaatsgevonden

Een testresultaat kan weergeven **Beheersmaatregel heeft niet plaatsgevonden**. Dit verschijnt wanneer de test wordt overgeslagen: in plaats van de teststappen uit te voeren, wordt de optie *Beheersmaatregel heeft niet plaatsgevonden* werd rechtstreeks aangeklikt voor die test. Gebruik deze optie alleen wanneer de Beheersmaatregel in de geteste Periode echt niet heeft plaatsgevonden.

<figure><img src="https://2540748892-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-8335d942ef2e802c62265a4d5407ae1ba8b478c5%2Ffinal-conclusion-as-tester.png?alt=media" alt="The tester selects the final conclusion of the test plan"><figcaption></figcaption></figure>

### Wanneer een Reviewer een conclusie afwijst

Als de Reviewer de uiteindelijke conclusie-score afwijst, is het testplan **niet** voltooid. Het keert terug naar de tester, en de status blijft in de fase testen/Assessment in plaats van naar Voltooid te gaan.

Daarna is de tester aan zet: het afgewezen resultaat moet worden herzien en opnieuw worden ingediend. Nadat de tester het herziene resultaat opslaat, gaat het plan opnieuw door naar de Reviewer.

### Een test terugsturen voor meer bewijs

Als een testplan zich in de **Controletoetsing** stap bevindt maar het geüploade bewijs uiteindelijk onvoldoende blijkt te zijn, kun je het plan terugzetten naar de stap voor het uploaden van bewijs. Zowel de beheerder als de tester kan dit doen met de **Ontbrekend bewijs afwijzen** knop. Het plan keert vervolgens terug naar **Wachten op bewijs**de bewijsuploader handelt vervolgens.

<figure><img src="https://2540748892-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-9019d04bb5fc35b443938ea24589bafa86ed7aef%2Fmissing-evidence-reason-of-rejection.png?alt=media" alt="Reason of rejection when evidence is missing"><figcaption></figcaption></figure>

### Testscores op de Beheersmaatregel

De resultaten van het testen worden op de Beheersmaatregel samengevat in het **Testscores** paneel, dat de Ontwerpscore, Implementatiescore, Effectiviteitsscore en Conclusiescore toont, samen met de bijbehorende testdatums. Deze velden worden ingevuld door de test-Workflows:

* **Testdatum (effectiviteit)** en **Effectiviteitsscore** worden pas ingevuld zodra een eerste testplan voor de Beheersmaatregel is **voltooid**. Zodra het eerste testplan is voltooid, worden deze velden ingevuld.
* **Volgende testdatum (effectiviteit)** wordt overgenomen uit de **vervaldatum van de Reviewer** van het momenteel openstaande testplan — of uit de **vervaldatum van de tester** als het testplan geen beoordelingsstap heeft. Als er geen open testplan is, wordt dit veld niet ingevuld.
* **Volgende testdatum (D\&I)** wordt afgeleid van de **Initiële testdatum** en **Testfrequentie** velden in de Design & Implementation-schermen van de Beheersmaatregel. Als er geen initiële testdatum was gepland, blijft dit veld leeg.

<figure><img src="https://2540748892-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-308caafbff78fdaa0155387a19d0f2bd25bae858%2Fcontrols-test-scores.png?alt=media" alt="The Test scores panel: Design, Implementation, Effectiveness and Conclusion scores with test dates"><figcaption></figcaption></figure>

Om de volledige details achter deze scores voor een specifieke Beheersmaatregel te zien, open je de Beheersmaatregel vanuit de Controls Workspace (klik op de Identifier) en ga je naar het **Effectiviteitstoetsing** tabblad. Daar vind je een overzicht van alle testplannen voor de Beheersmaatregel — status, Periode, aantal samples, bijgevoegde bewijsdocumenten en conclusie-scores — plus de volledige geschiedenis van eerdere testresultaten, die je kunt doorbladeren via de navigatie aan de linkerkant van het scherm.

### Rapporteren over teststatussen over Beheersmaatregelen

Om te zien in welke testfase al je Beheersmaatregelen zich bevinden, heb je twee opties:

1. Open de **Geavanceerde effectiviteitstoetsing van Beheersmaatregel** Workspace en voeg de relevante testkolommen (zoals status- en scorevelden) toe aan je weergave. Filter de dataset indien nodig en gebruik de Workspace-toolknop om deze naar Excel te exporteren.
2. Open de **Beheersmaatregelen** Workspace, filter de dataset en gebruik de Workspace-toolknop om de **testplan**. Deze export bevat ook de teststappen.

Zie voor het configureren van kolommen, filteren en het opslaan van je weergave als voorinstelling [Workspace, filters en voorinstellingen](/cerrix-documentation-nl/cerrix-functionaliteiten/workspaces-filters-and-presets.md).

{% hint style="warning" %}
Testkolommen worden alleen ingevuld voor **gemonitorde** Beheersmaatregelen. Als een Beheersmaatregel niet langer is gemarkeerd als *Gemonitord*, blijven de testgerelateerde kolommen (zoals testdatums en statussen) leeg in Workspace en voorinstellingen.
{% endhint %}

Houd er rekening mee dat voorinstelfilters per kolom één afzonderlijke lijst verfijnen. Het combineren van twee groepen die in één voorinstelling door verschillende voorwaarden zijn gedefinieerd — bijvoorbeeld Beheersmaatregelen die als effectief zijn getest *plus* ineffectieve Beheersmaatregelen waaraan een Verbetermaatregel is gekoppeld — is over het algemeen niet haalbaar binnen één voorinstelling. Voor rapportagedoeleinden is de betrouwbaarste aanpak om elke groep afzonderlijk te filteren en de resultaten te exporteren. Als je niet zeker weet of een specifieke combinatie in één voorinstelling kan worden uitgedrukt, neem dan contact op met CERRIX-support.


---

# 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-nl/cerrix-functionaliteiten/module-overview/controls/control-advanced-effectiveness-testing/test-plan-statuses-scores-and-reporting.md?ask=<question>&goal=<user_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.
