mp:Draft Testen Kickstart Ontwikkelfase

Aan deze pagina wordt momenteel gewerkt.

Tijdens de realisatie test de leverancier haar ontwikkelde product.

Om ervoor te zorgen dat het product gereed is voor de volgende fase en de validatie gaat er op twee onderdelen getest worden: inhoud en infrastructuur. Tevens faciliteert het programma gezamenlijke ketentests.

Voor het testen door de leveranciers tijdens de testfase zal de leverancier gebruik maken 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 realisatie is het noodzakelijk dat is voldaan aan onderstaande randvoorwaarden.

1.1 Randvoorwaarden

• 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 (PTO) (Aanvragen testaansluiting)

2 Uitvoering

De leverancier test de software primair op twee onderdelen: Voor alle testen stelt het Validatieloket omgevingen beschikbaar.

Inhoud
De leverancier test aan de hand van testscripts in de Kwalficatiesimulator/Touchstone of de informatiestandaard op een correcte wijze is geïmplementeerd.

Infrastructuur
Tijdens de realisatie heeft de leverancier de beschikking over de acceptatieomgeving (PTO-1). In deze acceptatieomgeving kan 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 dat leveranciers onderling met elkaar ketentesten, ter voorbereiding op de PoC:

Ketentest
De leverancier kan tijdens de realisatie verschillende ketentests uitvoeren. Door middel van de ketentest wordt getest of het bericht goed wordt verwerkt binnen de keten en op de juiste manier bij de andere partij aankomt. Van de verschillende types ketentesten is er minimaal 1 verplicht:

• Testen met de simulator: verplicht om minstens 1 test uit te voeren.
• Goedgekeurde berichten van leveranciers: indien mogelijk
• Testen met andere leveranciers: indien mogelijk

2.1 Scenario's

Inhoud
Met behulp van de simulatoren worden, voor de relevante transacties, de volgende testscripts uitgevoerd: Testscripts Medicatieproces 9
Voor elke test zijn er testscripts beschikbaar. Sommige scripts zijn openbaar gepubliceerd, andere kunnen opgevraagd worden per zorgtoepassing en systeemrol. Op de landingspagina documentatie leveranciers (Handboek) staat een verwijzing naar de inhoudelijke testscripts: Test en validatiemateriaal.
Infrastructuur
Infrastructurele en ketentestscripts worden op basis van systeemrol en zorgtoepassing gegenereerd, deze kunnen opgevraagd worden bij het Validatieloket via BITS of de casemanager.
Testscripts algemene eisen MP9 & Generieke voorzieningen (zip bestand)

=Resultaat= De leverancier geeft bij het Validatieloket aan dat de (stap) testen succesvol is doorlopen en ze klaar zijn om naar de volgende fase te gaan. De leverancier verzamelt zijn testresultaten en overlegt deze aan het Validatieloket. Welke resultaten er aangeleverd moeten worden is afhankelijk van het te testen scenario.

3 Randvoorwaarden

• De benodigde accounts zijn aangevraagd door de leverancier
• De leverancier heeft toegang tot de testomgeving
• De testberichten en testscripts zijn door het programma beschikbaar gesteld

Inhoud

• Voor het testen van HL7v3 berichten tegen de simulator wordt gebruik gemaakt van de kwalificatiesimulator
• Voor het testen van HL7 FHIR berichten tegen de simulator wordt gebruik gemaakt van Touchstone

Infrastructuur & Ketentesten

• De leverancier maakt gebruik van de acceptatieomgeving (PTO) om te testen

4 Acceptatie

4.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 acceptatiecriteria en dat de leverancier klaar is om naar de volgende fase te gaan.

4.2 Acceptatiecriteria

1. De leverancier toont middels een testrapport aan dat de in Kwalificatiesimulator/Touchstone​ vastgelegde testscripts voor de relevante transacties (gedefinieerd in het verzamelbestand) 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.

4.3 Bevindingen

De leverancier logt na inbouwen en testen tegen de simulator van de transactie de testresultaten in de deliverable in zijn project. Afhankelijk van de test kan dit door middel van screenshots of het testresultaat. Deze testresultaten worden beoordeeld door een inhoud deskundige van het programma. Hieruit kunnen testbevindingen voortkomen, deze zijn te classificeren in twee types.

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.

5 PAGINAHISTORIE

Datum	Omschrijving
1 december 2023	Acceptatiecriteria aangepast
6 juni 2023	Hoofdstuk 6 Acceptatie: gevuld Hoofdstuk 7 Testbevindingen: gevuld
4 mei 2023	Pagina gepubliceerd