mp:Draft Testen Kickstart Ontwikkelfase: verschil tussen versies
(→Bevindingen) |
(→Acceptatie) |
||
| Regel 49: | Regel 49: | ||
'''Acceptatiecriteria:''' | '''Acceptatiecriteria:''' | ||
| − | # 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. | + | # De leverancier toont middels een testrapport aan dat de in Kwalificatiesimulator/Touchstone vastgelegde testscripts voor de [[mp:Draft_Testen_Kickstart#Relevante_transacties|relevante transacties]] <FONT COLOR="#ff0000"><strike>(gedefinieerd in het verzamelbestand)</strike></FONT COLOR> 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 aanwezige bevindingen zijn niet blokkerend. | # De aanwezige bevindingen zijn niet blokkerend. | ||
Versie van 8 dec 2023 om 17:25
|
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.
Inhoud
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.
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
Werkwijze: De leverancier toont d.m.v. de testresultaten aan dat de testen succesvol zijn doorlopen. De leverancier logt de resultaten in de deliverables in zijn project. Afhankelijk van de test kan dit door middel van screenshots of testresultaten. Waar nodig zullen we samen met de leverancier testen en de informatie loggen.
Acceptatiecriteria:
- 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. - De leverancier toont middels een testrapport aan dat de randvoorwaardelijke generieke voorzieningen succesvol zijn geïmplementeerd.
- 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.
7 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):
- 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.
8 PAGINAHISTORIE
| Datum | Omschrijving |
|---|---|
| 1 december 2023 |
|
| 6 juni 2023 |
|
| 4 mei 2023 |
|