Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Elk soort product heeft een eigen testmethode, bij een auto een crashtest, bij een duikboot een druktest, etc. In de digitale wereld zijn ook testen essentieel.

Het W-model is een bekend model voor softwareontwikkeling. Het toont de verschillende opeenvolgende stadia van ontwikkeling met direct ernaast de bijbehorende testactiviteit. Hierbij worden op basis van een risico-inschatting bepaald welke producten getest moeten worden en welke technieken daarvoor het meest geschikt zijn. We houden hierbij ook rekening met de testen die al uitgevoerd worden zodat we geen dingen dubbel doen.

image-20240207-105337.png

bron: Managing Projects with Intelligence, Paul Gerrard, 2004 .

In een testtraject van software worden teststrategie, testplannen en testprotocollen gebruikt om aan te tonen dat een systeem voldoet aan de vereisten die eerder zijn vastgelegd in specificatie-, ontwerp- en configuratiedocumenten.

In een testdocument worden de testvereisten en -strategie uiteengezet. Het moet het algemene proces voor het uitvoeren van de tests omvatten, het documenteren van bewijs van tests en het proces voor het omgaan met fouten die bij het testen gevonden zijn. Het testplan kan ook de soorten testen bevatten, beschrijvingen van de omgevingen waar testen zullen worden uitgevoerd, wie verantwoordelijk is voor het testen, apparatuur of testen die bij het testen zullen worden gebruikt, of andere organisatorische vereisten voor testen.

Testprotocollen beschrijven het specifieke testen. Testprotocollen zijn verzamelingen testgevallen (testcases) die een specifiek element van het systeem controleren. Elk testgeval moet het doel van de test bevatten, eventuele vereisten die vóór het testen moeten worden vervuld en de acceptatiecriteria voor de test.

Elke testcase bestaat uit een reeks teststappen. Elke stap moet een instructie, een verwacht resultaat en het daadwerkelijke resultaat bevatten. De instructies moeten voldoende details bevatten, zodat een tester de vereiste testactiviteit consistent kan uitvoeren. Er moet ook een plek zijn waar de tester kan beoordelen of elke stap slaagt of mislukt.

Het proces van het volgen van de instructies en het vastleggen van de resultaten wordt het “uitvoeren” van het protocol genoemd. Bij het uitvoeren van testprotocollen moet de tester de gevestigde goede documentatiepraktijken volgen. Dit omvat het gebruik van een compatibel computersysteem om de testresultaten vast te leggen of de resultaten met pen en papier te documenteren. Elke discrepantie tussen het verwachte resultaat en het werkelijke resultaat moet als een afwijking worden bijgehouden. Afwijkingen moeten worden opgelost voordat de validatie is voltooid.

Unit test

Dit zijn testen die worden uitgevoerd op bepaalde functionele delen van broncode om te kunnen bepalen of dat onderdeel werkt zoals verwacht. Deze vorm van testen gebeurt door developers tijdens het schrijven van de code. Het is de verantwoordelijkheid van de leverancier. Wij schrijven hier geen aanvullende testen voor, omdat we hier de interoperabiliteit testen, en niet de zorgverlener-systemen zelf.

Integratietest

Hierbij worden de interfaces en de interacties tussen de verschillende componenten van een applicatie getest t.o.v. hun ontwerp. Dit kan iteratief of middels een ‘big bang’. Ook deze vorm van testen is de verantwoordelijkheid van de leverancier. Wij schrijven hier geen aanvullende testen voor omdat deze integratietesten binnen de systemen van de zorgverleners zelf gedaan worden en wij hier alleen de interoperabiliteit testen.

Systeem- of netwerktesten

Hierbij wordt het volledig systeem getest. Omdat bij het modulaire testen al is aangetoond dat de processen publiceren, raadplegen en verzamelen correct worden uitgevoerd, is de focus van de systeemtesten het bewijzen dat het netwerk correct werkt. In het testprotocol wordt dit uitgevoerd samen met de gebruikersacceptatiettest. Het is raadzaam dat leveranciers zelf netwerktesten uitvoeren tijdens het ontwikkelwerk, maar wij schrijven hier geen aanvullende testen voor.

Toegankelijkheidstesten

De subsidieregeling geeft aan dat er voldaan moet worden aan “standaarden ten aanzien van de digitale toegankelijkheid, zoals de Web Content Accessibility Guidelines (WCAG).” Dit is alleen van toepassing op de viewer.

Beveiligingstesten

Indien een leverancier van een SaaS-oplossing, NEN7510 of ISO27001 gecertificeerd is, dan zijn aanvullende testen niet nodig. Zorgaanbieders met een XIS on premise moeten een rapport van een onafhankelijke auditor kunnen overleggen.

Gebruikersacceptatietest

Bij veilige digitale gegevensuitwisseling speelt de eindgebruiker een essentiële rol. Door met de eindgebruiker samen te werken aan oplossingen die aansluiten op de praktijk, ontstaat er draagvlak. Input en feedback van de eindgebruikers is daarom van groot belang.

Uitgangspunten

  • De testen worden per regio in de vorm van een connectathon/projectathon uitgevoerd met de regionale projectorganisatie, betrokken leveranciers en regionale eindgebruikers.

  • Deze testen vinden plaats in de productieomgeving.

  • Er wordt zowel een acceptatietest als netwerktest uitgevoerd.

  • Een informatieanalist van Nictiz treedt op als monit

Aanpak

  1. Regionale projectorganisatie, betrokken leveranciers en regionale eindgebruikers zijn samen op locatie.

  2. In alle betrokken bronsystemen worden gegevens van een testzwangere ingevoerd.

  3. De gegevens van de testzwangere worden geraadpleegd in een viewer.

  4. Eindgebruikers geven hun oordeel.

Resultaten

  • Correcte werking van het netwerk is aangetoond.

  • Eindgebruikers zijn tevreden met de geïmplementeerde oplossing.

  • De resultaten van de test zijn inzichtelijk voor de deelnemers, de overige regio’s, het landelijk programmabureau en Nictiz.

  • No labels