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 drie onderdelen getest worden: inhoud, infrastructuur en een ketentest.

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 of infrastructuur.

1 Voorbereiding

Om te kunnen testen tijdens de realisatie is het noodzakelijk dat de leverancier toegang heeft tot de benodigde tooling en omgevingen. Op de pagina Tooling & omgevingen Kickstart Medicatieoverdracht staat beschreven hoe een account of toegang aangevraagd kan worden.

2 Uitvoering

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

Inhoud
De leverancier test aan de hand van kwalificatiescripts (c.q. testscripts) 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.

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

3 Scenario's

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.
Infrastructurele en ketentestscripts worden op basis van systeemrol en zorgtoepassing gegenereerd, deze kunnen opgevraagd worden bij het Validatieloket via BITS of de casemanager.

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

Eind Q1 2023 wordt bekend welke scenario's er getest worden met de gewenste resultaten.

5 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

6 Acceptatie

Volgt half mei 2023

7 Tetbevindingen

De leverancier logt na inbouwen en testen tegen de simulator van de transactie de testresultaten van 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 testbevindingen:

• Blokkerend: Bij een blokkerende bevinding loopt het proces vast en is er geen work-around mogelijk. Een blokkerende bevinding moet worden opgelost. De leverancier zal zijn product moeten aanpassen en opnieuw moeten testen.

• Niet Blokkerend: Een bevinding die geen directe gevolgen heeft of er is een work-around mogelijk. Indien van toepassing worden in overleg afspraken over het oplossen van deze bevinding gemaakt. Zodra de bevinding is opgelost wordt dit getest en zal het openstaande punt worden gesloten.

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 het BITS project van de leverancier.

8 Pagina historie

Datum	Omschrijving
Voorbeeld	Pagina gepubliceerd