mp:Draft Testen Kickstart Ontwikkelfase: verschil tussen versies
(→Acties ter voorbereiding) |
(→Fasering) |
||
| (47 tussenliggende versies door 2 gebruikers niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
__NUMBEREDHEADINGS__ | __NUMBEREDHEADINGS__ | ||
| − | {{DISPLAYTITLE: | + | {{DISPLAYTITLE: Testplan Kickstart: Ontwikkelfase}} |
{{IssueBox|'''<big>Aan deze pagina wordt momenteel gewerkt. </big>'''}} | {{IssueBox|'''<big>Aan deze pagina wordt momenteel gewerkt. </big>'''}} | ||
Tijdens de ontwikkelfase test de leverancier haar ontwikkelde product. | Tijdens de ontwikkelfase test de leverancier haar ontwikkelde product. | ||
| − | Om ervoor te zorgen dat het product gereed is voor de volgende fase wordt er op | + | Om ervoor te zorgen dat het product gereed is voor de volgende fase wordt er getest op inhoud, infrastructuur en consolidatie. Tevens faciliteert het programma gezamenlijke ketentests. |
Voor het testen door de leveranciers tijdens de testfase maakt de leverancier gebruik van een set aan testmateriaal. | Voor het testen door de leveranciers tijdens de testfase maakt de leverancier gebruik van een set aan testmateriaal. | ||
Daarnaast zijn omgevingen beschikbaar waarmee de leverancier kan testen op inhoud en/of infrastructuur. | Daarnaast zijn omgevingen beschikbaar waarmee de leverancier kan testen op inhoud en/of infrastructuur. | ||
| + | |||
| + | =Testdoel= | ||
| + | Tijdens deze fase wordt aangetoond dat: | ||
| + | * De informatiestandaard inhoudelijk correct is geïmplementeerd. | ||
| + | * Wordt voldaan aan de eisen voor het LSP. | ||
| + | # De consolidatie afleidingsregels correct worden toegepast en een correct, volledig en actueel medicatieoverzicht en toedienlijst getoond kan worden op basis van uitgebreide historie uit meerdere bronnen. | ||
=Voorbereiding= | =Voorbereiding= | ||
| Regel 13: | Regel 19: | ||
==Entry Criteria== | ==Entry Criteria== | ||
| − | * De benodigde accounts zijn aangevraagd/aangemaakt | + | |
| + | '''Leverancier''' | ||
| + | * De benodigde accounts zijn aangevraagd/aangemaakt: | ||
** Voor het testen van HL7v3 berichten tegen de simulator wordt gebruik gemaakt van de kwalificatiesimulator ([[mp:Draft_Testtooling#Account_aanvragen|Account aanvragen]]). | ** Voor het testen van HL7v3 berichten tegen de simulator wordt gebruik gemaakt van de kwalificatiesimulator ([[mp:Draft_Testtooling#Account_aanvragen|Account aanvragen]]). | ||
** Voor het testen van HL7 FHIR berichten tegen de simulator wordt gebruik gemaakt van Touchstone ([[mp:Draft_Testtooling#Account_aanmaken|Account aanmaken]]). | ** Voor het testen van HL7 FHIR berichten tegen de simulator wordt gebruik gemaakt van Touchstone ([[mp:Draft_Testtooling#Account_aanmaken|Account aanmaken]]). | ||
| − | * | + | ** Voor vastlegging van gezamenlijke ketentests en consolidatietests wordt gebruik gemaakt van Interoplab (Toelichting [https://informatiestandaarden.nictiz.nl/wiki/mp:Draft_Testtooling#Interoplab Interoplab]) |
| − | * | + | * Heeft toegang tot de acceptatieomgeving (XTO1) én de testomgeving (POC) ([[mp:Draft_Testtooling#Aanvragen_testaansluiting|Aanvragen testaansluiting]]). |
| + | |||
| + | '''Programma Medicatieoverdracht''' | ||
| + | * De testscripts en testberichten zijn beschikbaar gesteld. | ||
==Acties ter voorbereiding== | ==Acties ter voorbereiding== | ||
'''Leverancier''' | '''Leverancier''' | ||
| − | * Download het bestand [https://informatiestandaarden.nictiz.nl/wiki/Bestand:ConformiteitsCheck_-_MO.zip ConformiteitsCheck MO] en vul deze in, zoals beschreven in de instructie. | + | * Download het bestand [https://informatiestandaarden.nictiz.nl/wiki/Bestand:ConformiteitsCheck_-_MO.zip ConformiteitsCheck MO (zip bestand)] en vul deze in, zoals beschreven in de instructie. |
| − | * | + | * Plaats de laatste versie als bijlage in de BITS registratie (Conformiteitscheck - MO) met betrekking tot de voortgang en de [https://informatiestandaarden.nictiz.nl/wiki/mp:Testen_Kickstart_Ontwikkelfase#Afronding Afronding] van deze fase. |
=Uitvoering= | =Uitvoering= | ||
| − | De leverancier test de software primair op | + | De leverancier test de software primair op onderstaande onderdelen: |
| − | + | ==Primaire onderdelen== | |
| + | |||
| + | ===Inhoud=== | ||
De leverancier test aan de hand van testscripts in de Kwalificatiesimulator/Touchstone of de informatiestandaard op een correcte wijze is geïmplementeerd. | De leverancier test aan de hand van testscripts in de Kwalificatiesimulator/Touchstone of de informatiestandaard op een correcte wijze is geïmplementeerd. | ||
| − | + | ===Infrastructuur=== | |
Tijdens de ontwikkelfase beschikt de leverancier over de testomgeving (POC). In deze testomgeving test de leverancier haar applicatie testen tegen een simulator. Deze omgeving is bedoeld voor leveranciers om alleen, of met elkaar, tijdens de ontwikkeling te testen. Hiermee wordt het berichtenverkeer tijdens de implementatie van de software getest om te kijken of er voldaan wordt aan de eisen voor het LSP. | Tijdens de ontwikkelfase beschikt de leverancier over de testomgeving (POC). In deze testomgeving test de leverancier haar applicatie testen tegen een simulator. Deze omgeving is bedoeld voor leveranciers om alleen, of met elkaar, tijdens de ontwikkeling te testen. Hiermee wordt het berichtenverkeer tijdens de implementatie van de software getest om te kijken of er voldaan wordt aan de eisen voor het LSP. | ||
| + | ===Consolidatie=== | ||
| + | De leverancier voert de consolidatie tests uit, zoals beschreven in [https://informatiestandaarden.nictiz.nl/wiki/mp:Draft_Testen_Kickstart_Consolidatie#Aanpak Ontwikkel aanpak] van het testplan Consolidatie. | ||
| + | ==Aanvullend== | ||
Aanvullend stimuleert en faciliteert het programma in het kader van testondersteuning onderstaande tests: | Aanvullend stimuleert en faciliteert het programma in het kader van testondersteuning onderstaande tests: | ||
| − | + | ===Ketentest=== | |
Door middel van ketentesten wordt door leveranciers onderling met elkaar getest of het bericht goed wordt verwerkt binnen de keten en op de juiste manier via de infrastructuur bij de andere partij aankomt, ter voorbereiding op de PoC. | Door middel van ketentesten wordt door leveranciers onderling met elkaar getest of het bericht goed wordt verwerkt binnen de keten en op de juiste manier via de infrastructuur bij de andere partij aankomt, ter voorbereiding op de PoC. | ||
| + | Voor de vastlegging van de testresulaten wordt gebruik gemaakt van onderstaande generieke Interoplab testscripts: | ||
| + | * [https://my.interoplab.eu/uc-mo-vzvz/gazelle/test.seam?id=146 Voorschrijven] | ||
| + | * [https://my.interoplab.eu/uc-mo-vzvz/gazelle/test.seam?id=147 Raadplegen / Beschikbaar stellen] | ||
| + | <br> | ||
<FONT COLOR="#ff0000"> | <FONT COLOR="#ff0000"> | ||
| − | |||
| − | |||
'''Hybride''' | '''Hybride''' | ||
| Regel 50: | Regel 68: | ||
==Scenario's== | ==Scenario's== | ||
| − | + | ===Inhoud=== | |
Met behulp van de simulatoren worden, voor de relevante transacties, de volgende testscripts uitgevoerd: [[mp:Vcurrent_Kwalificatie#Medicatieproces_9_versie_3.0.0_testmateriaal_en_kwalificatiescripts_voor_Kickstart|Testscripts Medicatieproces 9]]. <br> | Met behulp van de simulatoren worden, voor de relevante transacties, de volgende testscripts uitgevoerd: [[mp:Vcurrent_Kwalificatie#Medicatieproces_9_versie_3.0.0_testmateriaal_en_kwalificatiescripts_voor_Kickstart|Testscripts Medicatieproces 9]]. <br> | ||
Hiervoor zijn de Kwalificatiesimulator/Touchstone beschikbaar om berichtinhoud te controleren door een vergelijking te maken met vooropgestelde testberichten, welke beschikbaar zijn gesteld op GitHub: | Hiervoor zijn de Kwalificatiesimulator/Touchstone beschikbaar om berichtinhoud te controleren door een vergelijking te maken met vooropgestelde testberichten, welke beschikbaar zijn gesteld op GitHub: | ||
| Regel 56: | Regel 74: | ||
* FHIR: https://github.com/Nictiz/HL7-mappings/tree/master/ada_2_fhir-r4/mp/9.3.0 | * FHIR: https://github.com/Nictiz/HL7-mappings/tree/master/ada_2_fhir-r4/mp/9.3.0 | ||
| − | + | ====Fasering==== | |
| + | <FONT color=RED>Voor stap 5 en 6 wordt een gefaseerde aanpak toegepast, waarbij wordt gewerkt van eenvoudig naar steeds complexer.</FONT> | ||
| + | |||
| + | ===Infrastructuur=== | ||
De Infrastructurele scripts zijn gepubliceerd op de wiki: [https://informatiestandaarden.nictiz.nl/images/5/5e/Testscripts_algemene_eisen_MP9_%26_Generieke_voorzieningen.zip Testscripts algemene eisen MP9 & Generieke voorzieningen (zip bestand)]. Deze scripts zijn gebaseerd op de Pakketten van Eisen vanuit VZVZ. | De Infrastructurele scripts zijn gepubliceerd op de wiki: [https://informatiestandaarden.nictiz.nl/images/5/5e/Testscripts_algemene_eisen_MP9_%26_Generieke_voorzieningen.zip Testscripts algemene eisen MP9 & Generieke voorzieningen (zip bestand)]. Deze scripts zijn gebaseerd op de Pakketten van Eisen vanuit VZVZ. | ||
| + | |||
| + | ===Consolidatie=== | ||
| + | De leverancier voert de consolidatie testscripts uit, zoals beschreven in [https://informatiestandaarden.nictiz.nl/wiki/mp:Draft_Testen_Kickstart_Consolidatie#Scenario.27s Ontwikkel scenario's] van het testplan Consolidatie. | ||
| + | |||
| + | ===Ketentest=== | ||
| + | Voor vastlegging van gezamenlijke ketentests wordt gebruik gemaakt van generieke Interoplab scripts. | ||
<FONT COLOR="#ff0000"> | <FONT COLOR="#ff0000"> | ||
| − | + | ||
'''Hybride''' | '''Hybride''' | ||
| Regel 81: | Regel 108: | ||
De PoC- testomgeving kan zonder authenticatie benaderd worden. Dit is met name handig wanneer dit nog ontwikkeld moet worden voor de applicatie. | De PoC- testomgeving kan zonder authenticatie benaderd worden. Dit is met name handig wanneer dit nog ontwikkeld moet worden voor de applicatie. | ||
| − | '''PGO''' | + | '''PGO & DVA''' <br> |
| − | <br> | + | PGO's en DVA's testen tijdens deze fase hun product in de Medmij Zandbak testen. Meer informatie over hoe hier toegang toe te krijgen is vinden bij [https://informatiestandaarden.nictiz.nl/wiki/mp:Draft_Testtooling#Medmij_Zandbak Tooling & omgevingen]. |
=Afronding= | =Afronding= | ||
==Werkwijze== | ==Werkwijze== | ||
De leverancier geeft bij het Validatieloket aan dat de testen succesvol zijn uitgevoerd en legt dit vast in de Conformiteitscheck.<br> | De leverancier geeft bij het Validatieloket aan dat de testen succesvol zijn uitgevoerd en legt dit vast in de Conformiteitscheck.<br> | ||
| − | De | + | De versturende kant (versturen / beschikbaar stellen) wordt getoetst aan de hand van de simulatoren, voor de ontvangende kant (ontvangen / raadplegen) en om te bepalen of er naar de volgende fase gegaan kan worden wordt een check-up moment gepland.<br> |
| − | |||
==Exit Criteria== | ==Exit Criteria== | ||
| − | # De leverancier toont middels | + | # De leverancier toont middels de conformiteitscheck aan dat de in Kwalificatiesimulator/Touchstone vastgelegde testscripts voor de [[mp:Draft_Testen_Kickstart#Relevante_transacties|relevante transacties]] succesvol zijn uitgevoerd en toont daarmee aan dat deze transacties inhoudelijk correct zijn. |
# De leverancier toont middels een testrapport aan dat de randvoorwaardelijke generieke voorzieningen succesvol zijn geïmplementeerd. | # De leverancier toont middels een testrapport aan dat de randvoorwaardelijke generieke voorzieningen succesvol zijn geïmplementeerd. | ||
| + | # De leverancier voert de in Interoplab vastgelegde Consolidatie testscripts succesvol uit en toont daarmee aan dat: | ||
| + | # De consolidatie afleidingsregels worden correct toegepast en een correct, volledig en actueel medicatieoverzicht en toedienlijst kan getoond worden op basis van uitgebreide historie uit meerdere bronnen. | ||
# De aanwezige bevindingen zijn niet blokkerend. | # De aanwezige bevindingen zijn niet blokkerend. | ||
| Regel 98: | Regel 126: | ||
==Bevindingen== | ==Bevindingen== | ||
| − | De testresultaten worden beoordeeld door een inhoud deskundige van het programma tijdens een | + | De testresultaten worden beoordeeld door een inhoud deskundige van het programma op basis van de aangeleverde informatie en tijdens een check-up moment. Hieruit kunnen testbevindingen voortkomen, deze zijn te classificeren in: |
{{#lst:mp:Draft_Testen_Kickstart|testenKickstartBevindingen}} | {{#lst:mp:Draft_Testen_Kickstart|testenKickstartBevindingen}} | ||
| Regel 110: | Regel 138: | ||
|- | |- | ||
! Datum !! Omschrijving | ! Datum !! Omschrijving | ||
| + | |- | ||
| + | | 10 juni 2024 || | ||
| + | * Titel aangepast naar Testplan Kickstart: Ontwikkelfase | ||
| + | * Entry criterium Interoplab: ook van toepassing voor Consolidatie | ||
| + | * Exit criterium Consolidatie uitgebreid met toedienlijst en consolidatie afleidingsregels. | ||
| + | |- | ||
| + | | 7 juni 2024 || | ||
| + | * Testdoel, Uitvoering, Scenario's en Exit Criteria uitgebreid met consolidatie | ||
| + | * Verwijzingen naar testplan Consolidatie toegevoegd | ||
| + | * Uitvoering gesplitst naar Primair en Aanvullend | ||
| + | ** Consolidatie opgenomen in Primair | ||
| + | |- | ||
| + | | 5 februari 2024 || Verwijzing naar generieke Interoplab testscripts toegevoegd | ||
| + | |- | ||
| + | | 5 januari 2024 || ConformiteitsCheck toegevoegd | ||
|- | |- | ||
| 4 januari 2024 || Testomgevingen VZVZ toegevoegd | | 4 januari 2024 || Testomgevingen VZVZ toegevoegd | ||
Huidige versie van 25 sep 2024 om 15:30
|
|
Aan deze pagina wordt momenteel gewerkt. |
Tijdens de ontwikkelfase test de leverancier haar ontwikkelde product.
Om ervoor te zorgen dat het product gereed is voor de volgende fase wordt er getest op inhoud, infrastructuur en consolidatie. Tevens faciliteert het programma gezamenlijke ketentests.
Voor het testen door de leveranciers tijdens de testfase maakt de leverancier gebruik van een set aan testmateriaal. Daarnaast zijn omgevingen beschikbaar waarmee de leverancier kan testen op inhoud en/of infrastructuur.
1 Testdoel
Tijdens deze fase wordt aangetoond dat:
- De informatiestandaard inhoudelijk correct is geïmplementeerd.
- Wordt voldaan aan de eisen voor het LSP.
- De consolidatie afleidingsregels correct worden toegepast en een correct, volledig en actueel medicatieoverzicht en toedienlijst getoond kan worden op basis van uitgebreide historie uit meerdere bronnen.
2 Voorbereiding
Om te kunnen testen tijdens de ontwikkelfase is het noodzakelijk dat is voldaan aan onderstaande entry criteria en voorbereidende acties.
2.1 Entry Criteria
Leverancier
- De benodigde accounts zijn aangevraagd/aangemaakt:
- Voor het testen van HL7v3 berichten tegen de simulator wordt gebruik gemaakt van de kwalificatiesimulator (Account aanvragen).
- Voor het testen van HL7 FHIR berichten tegen de simulator wordt gebruik gemaakt van Touchstone (Account aanmaken).
- Voor vastlegging van gezamenlijke ketentests en consolidatietests wordt gebruik gemaakt van Interoplab (Toelichting Interoplab)
- Heeft toegang tot de acceptatieomgeving (XTO1) én de testomgeving (POC) (Aanvragen testaansluiting).
Programma Medicatieoverdracht
- De testscripts en testberichten zijn beschikbaar gesteld.
2.2 Acties ter voorbereiding
Leverancier
- Download het bestand ConformiteitsCheck MO (zip bestand) en vul deze in, zoals beschreven in de instructie.
- Plaats de laatste versie als bijlage in de BITS registratie (Conformiteitscheck - MO) met betrekking tot de voortgang en de Afronding van deze fase.
3 Uitvoering
De leverancier test de software primair op onderstaande onderdelen:
3.1 Primaire onderdelen
3.1.1 Inhoud
De leverancier test aan de hand van testscripts in de Kwalificatiesimulator/Touchstone of de informatiestandaard op een correcte wijze is geïmplementeerd.
3.1.2 Infrastructuur
Tijdens de ontwikkelfase beschikt de leverancier over de testomgeving (POC). In deze testomgeving test de leverancier haar applicatie testen tegen een simulator. Deze omgeving is bedoeld voor leveranciers om alleen, of met elkaar, tijdens de ontwikkeling te testen. Hiermee wordt het berichtenverkeer tijdens de implementatie van de software getest om te kijken of er voldaan wordt aan de eisen voor het LSP.
3.1.3 Consolidatie
De leverancier voert de consolidatie tests uit, zoals beschreven in Ontwikkel aanpak van het testplan Consolidatie.
3.2 Aanvullend
Aanvullend stimuleert en faciliteert het programma in het kader van testondersteuning onderstaande tests:
3.2.1 Ketentest
Door middel van ketentesten wordt door leveranciers onderling met elkaar getest of het bericht goed wordt verwerkt binnen de keten en op de juiste manier via de infrastructuur bij de andere partij aankomt, ter voorbereiding op de PoC.
Voor de vastlegging van de testresulaten wordt gebruik gemaakt van onderstaande generieke Interoplab testscripts:
Hybride
Bovensectorale gebruikerseisen
3.3 Scenario's
3.3.1 Inhoud
Met behulp van de simulatoren worden, voor de relevante transacties, de volgende testscripts uitgevoerd: Testscripts Medicatieproces 9.
Hiervoor zijn de Kwalificatiesimulator/Touchstone beschikbaar om berichtinhoud te controleren door een vergelijking te maken met vooropgestelde testberichten, welke beschikbaar zijn gesteld op GitHub:
- HL7v3: https://github.com/Nictiz/HL7-mappings/tree/master/ada_2_hl7/mp/9.3.0
- FHIR: https://github.com/Nictiz/HL7-mappings/tree/master/ada_2_fhir-r4/mp/9.3.0
3.3.1.1 Fasering
Voor stap 5 en 6 wordt een gefaseerde aanpak toegepast, waarbij wordt gewerkt van eenvoudig naar steeds complexer.
3.3.2 Infrastructuur
De Infrastructurele scripts zijn gepubliceerd op de wiki: Testscripts algemene eisen MP9 & Generieke voorzieningen (zip bestand). Deze scripts zijn gebaseerd op de Pakketten van Eisen vanuit VZVZ.
3.3.3 Consolidatie
De leverancier voert de consolidatie testscripts uit, zoals beschreven in Ontwikkel scenario's van het testplan Consolidatie.
3.3.4 Ketentest
Voor vastlegging van gezamenlijke ketentests wordt gebruik gemaakt van generieke Interoplab scripts.
Hybride
Bovensectorale gebruikerseisen
3.4 Testomgevingen
VZVZ
Voor de ontwikkelfase zijn onderstaande omgevingen beschikbaar.
Informatie m.b.t. IP-adressen is te vinden bij Tooling & omgevingen.
- PoC+
De PoC+ omgeving kan enkel benaderd worden met authenticatie. Zodra er met authenticatie gewerkt wordt kan dat met UZI-testmiddelen. Dit is bedoeld om programma’s te ondersteunen bij het ontwikkelen van nieuwe functionaliteit en/of Zorgtoepassingen, ter voorbereiding op een nieuwe standaard.
- PoC-
De PoC- testomgeving kan zonder authenticatie benaderd worden. Dit is met name handig wanneer dit nog ontwikkeld moet worden voor de applicatie.
PGO & DVA
PGO's en DVA's testen tijdens deze fase hun product in de Medmij Zandbak testen. Meer informatie over hoe hier toegang toe te krijgen is vinden bij Tooling & omgevingen.
4 Afronding
4.1 Werkwijze
De leverancier geeft bij het Validatieloket aan dat de testen succesvol zijn uitgevoerd en legt dit vast in de Conformiteitscheck.
De versturende kant (versturen / beschikbaar stellen) wordt getoetst aan de hand van de simulatoren, voor de ontvangende kant (ontvangen / raadplegen) en om te bepalen of er naar de volgende fase gegaan kan worden wordt een check-up moment gepland.
4.2 Exit Criteria
- De leverancier toont middels de conformiteitscheck aan dat de in Kwalificatiesimulator/Touchstone vastgelegde testscripts voor de relevante transacties succesvol zijn uitgevoerd en toont daarmee aan dat deze transacties inhoudelijk correct zijn.
- De leverancier toont middels een testrapport aan dat de randvoorwaardelijke generieke voorzieningen succesvol zijn geïmplementeerd.
- De leverancier voert de in Interoplab vastgelegde Consolidatie testscripts succesvol uit en toont daarmee aan dat:
- De consolidatie afleidingsregels worden correct toegepast en een correct, volledig en actueel medicatieoverzicht en toedienlijst kan getoond worden op basis van uitgebreide historie uit meerdere bronnen.
- De aanwezige bevindingen zijn niet blokkerend.
Indien hieraan is voldaan resulteert dit in een Go vanuit het validatieloket om door te gaan naar de Proof of Concept test.
4.3 Bevindingen
De testresultaten worden beoordeeld door een inhoud deskundige van het programma op basis van de aangeleverde informatie en tijdens een check-up moment. Hieruit kunnen testbevindingen voortkomen, deze zijn te classificeren in:
Type bevindingen
Bij de bevinding wordt altijd aangegeven wat het oordeel is. Er zijn vijf mogelijkheden (zoals ook vastgesteld in paragraaf 3.2 van de gebruikershandleiding BITS):
- Blokkerend: Een blokkerende bevinding moet worden opgelost om de validatie te behalen.
- Niet Blokkerend met aantekening: De niet blokkerende bevinding met aantekening moeten in de toekomst opgelost worden (waarbij bij afgifte van de validatie afgestemd wordt op welke termijn dat exact is).
- Niet Blokkerend: Niet blokkerend betekend dat de bevinding niet van toepassing is op de validatie (doordat bijvoorbeeld een element ook niet binnen komt en daardoor niet getoond kan worden).
- Toelichting vereist: Toelichting vereist betekend dat de bevinding nader toegelicht moet worden, waarbij deze na de toelichting alsnog blokkerend zou kunnen worden.
- Advies: Advies betekend dat er een advies gegeven wordt op de gekozen oplossing vanuit het validatieloket.
Resulteert de bevinding in een wijziging dan wordt deze opgenomen in het reguliere wijzigingsproces van het programma.
Wanneer er vragen zijn gedurende het testen kunnen deze als reguliere tickets worden ingediend in het BITS project van de leverancier.
5 PAGINAHISTORIE
| Datum | Omschrijving |
|---|---|
| 10 juni 2024 |
|
| 7 juni 2024 |
|
| 5 februari 2024 | Verwijzing naar generieke Interoplab testscripts toegevoegd |
| 5 januari 2024 | ConformiteitsCheck toegevoegd |
| 4 januari 2024 | Testomgevingen VZVZ toegevoegd |
| 3 januari 2024 | Randvoorwaarden en Acceptatiecriteria hernoemd naar Entry en Exit criteria |
| 21 december 2023 | Paragraaf Testomgevingen toegevoegd |
| 12 december 2023 |
|
| 1 december 2023 | Acceptatiecriteria aangepast |
| 6 juni 2023 |
|
| 4 mei 2023 | Pagina gepubliceerd |
