Testplan OEAPI 6.0 model

1. Doel

Vaststellen dat de implementatie:

  • de OEAPI 6.0 resources en relaties correct aanbiedt;
  • queryparameters, filtering, paging en veldselectie correct afhandelt;
  • identifiers, referenties en expand-relaties consistent verwerkt;
  • association- en offering-logica correct ondersteunt;
  • foutafhandeling en autorisatie conform specificatie werken;
  • geen deprecated paden onterecht als actief kernpad gebruikt.

2. Scope

In scope:

  • basisobjecten: programmes, courses, learning components, test components;
  • offering-objecten: programme offerings, course offerings, learning component offerings, test component offerings;
  • association-objecten;
  • ondersteunende objecten: persons, organisations, groups, memberships, academic sessions, buildings, rooms, service metadata, documents, learning outcomes.

Out of scope:

  • performance/load;
  • UI-weergave;
  • brondata-inhoudelijke validiteit buiten API-contract;
  • instelling-specifieke security-implementatie, behalve waar endpoints authenticatie/autorisatie vereisen. De specificatie definieert namelijk geen globale security en laat dit per operatie/documentatie expliciteren.

3. Testaanpak

Voer de tests op drie niveaus uit:

  1. Contracttests: klopt request/response met OpenAPI-schema.
  2. Functionele API-tests: werkt filtering, paging, expand, foutafhandeling.
  3. Integratie-/modeltests: kloppen relaties tussen objecten en referentiële integriteit.

4. Testomgeving

Benodigd:

  • een OEAPI 6.0 implementatie;
  • testdata met minimaal:
    • 2 programmes
    • 3 courses
    • 4 learning components
    • 2 test components
    • meerdere offerings per object
    • minimaal 3 persons
    • associations voor student en docent
    • 2 organisations
    • 2 groups + memberships
    • 1 building met meerdere rooms
    • meerdere academic sessions

5. Entry- en exitcriteria

Entry:

  • API is bereikbaar.
  • OpenAPI-definitie en autorisatiegegevens zijn beschikbaar.
  • Testdata is geladen.

Exit:

  • alle kritieke testcases geslaagd;
  • geen openstaande blocker op resource-opvraag, filtering, identifiers, associations of offering-relaties;
  • foutcodes en autorisatiegedrag reproduceerbaar juist.

Prioritering

Kritiek

  • RES-01 t/m RES-08
  • OFF-01 t/m OFF-10
  • ASS-01 t/m ASS-12
  • QRY-01 t/m QRY-08
  • SEC-02 t/m SEC-05
  • ERR-01 t/m ERR-04

Hoog

  • GEN-02 t/m GEN-04
  • EXP-01 t/m EXP-05
  • DAT-01 t/m DAT-07
  • SUP-01 t/m SUP-07

Middel

  • SUP-08 t/m SUP-10
  • DEP-01 t/m DEP-04
  • ATT-01 t/m ATT-04

Acceptatiecriteria

Een implementatie is acceptabel wanneer:

  • alle kernresources opvraagbaar zijn;
  • offering- en association-relaties inhoudelijk kloppen;
  • paging/filtering/fields/expand correct werken;
  • foutcodes voorspelbaar en consistent zijn;
  • deprecated paden niet als primaire route nodig zijn;
  • metadata over supported operations/expands overeenkomt met feitelijk gedrag.

Mapping testplan → Postman folders

Testplan onderdeelPostman folder
Algemene contracttests01 Service Metadata
Basisresource-tests02 Core Resources
Offering-modeltests03 Offerings
Association-tests04 Associations
Attempt-tests05 Attempts
Query/filter/paging06 Query and Paging
Expand-tests07 Expands
Supporting domains08 Supporting Domains
Security09 Security
Error handling10 Error Handling
Deprecated11 Deprecated

Praktisch advies

Voor deze API wordt aanbevolen in Postman te werken met:

  • collection-level auth
  • folder-level standaard tests
  • environment variables voor id’s
  • één smoke suite
  • één volledige regressiesuite
  • één negative test suite

Dit houdt het onderhoudbaar wanneer OEAPI 6.x minor updates krijgt.