Testen Kickstart: Ontwikkelfase

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 op twee onderdelen getest: inhoud en infrastructuur. 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 Voorbereiding

Om te kunnen testen tijdens de ontwikkelfase is het noodzakelijk dat is voldaan aan onderstaande entry criteria en voorbereidende acties.

1.1 Entry Criteria

• De benodigde accounts zijn aangevraagd/aangemaakt door de leverancier:
  • 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).
• De testscripts en testberichten zijn door het programma beschikbaar gesteld.
• De leverancier heeft toegang tot de acceptatieomgeving (XTO1) én de testomgeving (POC) (Aanvragen testaansluiting).

1.2 Acties ter voorbereiding

Leverancier

• Download het bestand ConformiteitsCheck MO en vul deze in, zoals beschreven in de instructie.
• Stuur deze naar het Validatieloket ten behoeve communicatie met betrekking tot de voortgang en Afronding van deze fase.

2 Uitvoering

De leverancier test de software primair op twee onderdelen:

Inhoud
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.

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.

Consolidatie

Hybride

Bovensectorale gebruikerseisen

2.1 Scenario's

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

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.

Consolidatie

Hybride

Bovensectorale gebruikerseisen

2.2 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
NTB

3 Afronding

3.1 Werkwijze

De leverancier geeft bij het Validatieloket aan dat de testen succesvol zijn uitgevoerd en legt dit vast in de Conformiteitscheck.
De leverancier verzamelt hiervoor zijn testresultaten (waar nodig aangevuld met screenshots en/of logging) en overlegt deze aan het Validatieloket.
Hiermee wordt aangetoond dat is voldaan aan de exit criteria en dat de leverancier klaar is om naar de volgende fase te gaan.

3.2 Exit Criteria

1. De leverancier toont middels een testrapport 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.
2. De leverancier toont middels een testrapport aan dat de randvoorwaardelijke generieke voorzieningen succesvol zijn geïmplementeerd.
3. 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.

3.3 Bevindingen

De testresultaten worden beoordeeld door een inhoud deskundige van het programma tijdens een checkup 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):

1. Blokkerend: Een blokkerende bevinding moet worden opgelost om de validatie te behalen.
2. 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).
3. 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).
4. Toelichting vereist: Toelichting vereist betekend dat de bevinding nader toegelicht moet worden, waarbij deze na de toelichting alsnog blokkerend zou kunnen worden.
5. 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.

4 PAGINAHISTORIE

Datum	Omschrijving
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	Structuur van pagina aangepast Resultaat opgenomen in Werkwijze Randvoorwaarden opgenomen in Voorbereiding Scenario's: Inhoud; directe verwijzing naar Testscripts MP9
1 december 2023	Acceptatiecriteria aangepast
6 juni 2023	Hoofdstuk 6 Acceptatie: gevuld Hoofdstuk 7 Testbevindingen: gevuld
4 mei 2023	Pagina gepubliceerd